E-Mails manchmal

Question

Leute verschlüsselt bekommen,

Ich habe eine PHP-basierte Website (unter Verwendung des QCubed framework); Als Teil der Website habe ich einen Daemon, der täglich mehrere tausend E-Mails verschickt (nein, ich bin kein Spammer, alles ist angemeldet :)). E-Mails werden über eine benutzerdefinierte Framework-Komponente gesendet. Diese Komponente dient als SMTP-Client. Ich verwende ein kostenpflichtiges SMTP-Gateway von DNSExit.com, um die tatsächlich gelieferten E-Mails zu erhalten.

Diese E-Mails sind einfache HTML-basierte E-Mails; Sie haben wirklich nur einfache Links drin.

Mein Problem ist, dass diese Links manchmal (nicht konsequent!) Während des Übergangs verschlüsselt werden. Tags werden irgendwie durcheinander gebracht, und einige Links sind in der E-Mail nicht funktionsfähig. Das Problem tritt bei einem kleinen Prozentsatz aller gesendeten E-Mails auf. es ist nicht konsistent (d. h. die gleiche exakte Quellennachricht HTML kann das Verwürfeln im Übergang verursachen oder nicht verursachen).

Habt jemand von euch das gesehen? Irgendwelche Gedanken zur Problembehandlung?

Answer 1

Hatte 2 Probleme mit E-Mail-Daten - normalerweise "?" Irgendwie kam ein Symbol in ein paar Wörter, ein anderes war UTF und titelbezogen. Zuerst wurde "repariert", indem man den Hosting-Provider änderte (also war es Mail-Server-bezogen), der zweite wurde behoben, indem die PHPmailer-Bibliothek geändert wurde.

Versuchen Sie anzugeben, wie genau Daten verschlüsselt werden.

Answer 2

Ist es möglich, dass Sie temporäre Dateien verwenden, um die E-Mails zu erstellen (oder zumindest den variablen Inhalt erstellen)? Ich habe einmal etwas vage ähnlich gemacht. Der E-Mail-Text wurde basierend auf der genauen Zeit in Sekunden generiert und in eine temporäre Datei geschrieben. Leider haben wir beim Senden von Tausenden pro Tag die gleiche Sekunde mehr als einmal getroffen (da nur 86k Sekunden verfügbar sind). Das könnte erklären a) die kleine Fehlerrate und b) die scheinbare Zufälligkeit. Zur Fehlerbehebung würde ich nur sehen, ob der Fehler Rate mit der Anzahl der E-Mails steigt und von dort aus geht.

Answer 3

Haben Sie spezielle Attribute in Ihren Links? Kann title-Attribut mit nicht maskierten Anführungszeichen innerhalb sein?

Etwas wie folgt aus: <a href="http://some.site" title="My "correct" link">Link</a>

Answer 4

Ich lief in ein ähnliches Problem auf einem Server mit Sendmail.

Ich erstellte und testete eine HTML-E-Mail, die eines Tages verschickt werden würde (Opt-In, natürlich). Ich hatte selbst eine Vorlage für die E-Mail, die für jeden HTML-Programmierer leicht zu lesen war, aber als solche war es schwer auf den Whitespace, um alles richtig auszurichten. Ich dachte mir, wenn dies massenhaft gemailt wird, nachdem die Vorlage gerendert wurde, denke ich, dass ich den Leerraum in der Datei minimieren werde, um Platz zu sparen! Also habe ich einen genialen regulären Ausdruck erstellt, um unnötige Whitespaces von der gerenderten E-Mail zu entfernen.

Nach dem Senden der E-Mail an mich selbst, öffnete ich die E-Mail und war verblüfft, als ich sah, dass einige der CSS und HTML wurden nicht korrekt angezeigt, wenn meine früheren E-Mails vor meiner Regexp waren. Beim Betrachten der ursprünglichen Nachricht bemerkte ich, dass ab und zu ein Ausrufezeichen (!) Scheinbar zufällig in der gesamten Nachricht auftauchte, wodurch css und html, die auf dem zufälligen Pfad kamen, zerstört wurden.

Stellt sich heraus, dass sendmail es nicht mag, wenn eine Zeile in Ihrer E-Mail ohne Zeilenumbruch zu lang wird. Wenn die Zeile zu lang wird, fügt sendmail ein Ausrufezeichen gefolgt von einem Zeilenumbruch rechts und links ein, nur um Sie zu verwirren und zu verwirren.

Warum hat es nicht einfach einen Leerraum zwischen Wörtern zu Zeilenumbruch gewählt? Warum das Ausrufezeichen einfügen? Fragen, fürchte ich, ohne Antworten.

Meine Lösung?

sudo apt-get remove sendmail 
sudo apt-get install exim4 

Ich hatte andere Probleme mit Sendmail, wie es eine volle 60 Sekunden dauern E-Mail senden und Exim4 gerade gearbeitet, und ich habe noch nie wieder darüber nachdenken.

Wenn Ihr Mailserver sendmail verwendet, könnte dies sehr gut das Problem sein, wenn nicht, danke, dass Sie mich meine Geschichte mit Ihnen teilen. Ich musste entlüften.

Answer 5

Wenn Sie eine E-Mail senden, sollten Sie sie so kodieren, dass jede Zeile im Nachrichtentext nicht länger als 76 Zeichen ist. Sie könnten hierfür base64 verwenden, aber die meisten Systeme verwenden die gedruckte Codierung für Text, da sie kleinere Nachrichten generiert. Base64 wird normalerweise nur für Binärdaten verwendet.

Answer 6

Das Problem ist, dass HTML nicht mit E-Mail kompatibel ist. Deshalb habe ich Mail Markup Language erstellt.

HTML wurde erstellt, um mit dem HTTP-Protokoll zu arbeiten, da diese beiden Technologien ungefähr zur selben Zeit von derselben Person erfunden wurden. Der Unterschied besteht darin, dass HTTP eine Einwegübertragung von einem Server zu einem Client ist. Das ändert sich nie, da das HTML-Dokument immer von einem Server stammt, an einen anfordernden Client gesendet wird und nach Abschluss der Übertragung die Verbindung zwischen dem Client und dem Server getrennt wird.

E-Mail verhält sich nicht so. In E-Mails entsteht eine Kommunikation bei einem Kunden, wird an einen oder mehrere E-Mail-Server gesendet und endet dann bei einem entfernten Client. Der größte Unterschied ist jedoch, dass das Dokument nicht mit der Endgültigkeit einer einzelnen Übertragungsinstanz endet, wie es bei einer Dokumentübertragung über HTTP der Fall ist. Ein in SMTP gesendetes Dokument kann an mehrere nicht angeforderte Benutzer beantwortet, weitergeleitet oder kopiert werden. Dieser eine Unterschied ist tiefgreifend, wenn die Berücksichtigung eines E-Mail-Threads berücksichtigt wird.

Das Problem besteht darin, dass SMTP und HTTP unterschiedlich sind, wie in den vorherigen zwei Absätzen gezeigt. Diese Unterschiede bestehen darin, dass SMTP und HTTP radikal unterschiedliche Formatierungsmethoden für die Erstellung von Kopfdaten haben. HTML verfügt über Kopfdaten, die mit den Headern von HTTP-Übertragungen kompatibel sein sollen und SMTP-Übertragungen nicht entsprechen. Die HTML-Header berücksichtigen auch nicht die Komplexität eines E-Mail-Threads.

Das Problem veranschaulicht wird, wenn E-Mail-Software ein HTML-Dokument korrumpiert Formatierung hinzuzufügen Änderungen notwendig, um die konformen Anforderungen dieser Software zu passen und auch Kopfdaten direkt in das Dokument zu schreiben. Diese Veranschaulichung wird extrem ausgeprägt, wenn eine HTML-E-Mail zu einem E-Mail-Thread wird. Da die HTML-Header-Daten keine Methode haben für die Komplexität eines E-Mail-Thread zu berücksichtigen gibt es keine Möglichkeit relevante Präsentation Definitionen aus einer Sheet zu liefern, die die Übertragung des Dokuments zu überleben. Jedes Mal, wenn ein HTML-Dokument oder ein Dokument mit HTML-Formatierung von einer E-Mail-Software zu einer anderen gesendet wird, ist das Dokument beschädigt und jedes E-Mail-Software-Gerät korrumpiert die vorherige Beschädigung. E-Mail-Verarbeitungssoftware kann sich entweder auf einen E-Mail-Client beziehen, der ein Dokument oder einen E-Mail-Server mit Sicherheit beschädigt, was wahrscheinlich nur ein E-Mail-Dokument beschädigt.

Die Lösung des Problems ist eine Auszeichnungssprache Konvention zu erstellen, die direkt auf die Anforderungen der E-Mail-Header-Daten erkennt. Diese Anforderungen sind in RFC 5321 für das SMTP-Protokoll und RFC 5322 für die Client-Verarbeitung definiert. Die einzige Möglichkeit, diese Lösung ordnungsgemäß zu erweitern, um die Komplexität eines E-Mail-Threads zu berücksichtigen, ist die Bereitstellung einer Konvention für ein DOM mit mehreren Agenten.

Absätze gelöscht wegen technischer Ungenauigkeit und Unterschied zwischen dem Begriff Multi-Agent-DOM und die Art eines erfundenen Feature, das hier noch nicht vor der Bearbeitung erwähnt.

EDIT: ein Multi-Agent-DOM verwendet ein gewisses Maß an Hierarchie, die möglicherweise nicht erforderlich ist, um einen E-Mail-Thread darzustellen.