E-Mails, die in Base64 empfangen werden, werden nicht automatisch decodiert

3503
user108

Viele Agenten in meinem Unternehmen empfangen E-Mails, die immer noch den Barracuda-Header (Spam-Firewall) enthalten (auch in der Nachrichtenansicht, nicht der Quellansicht) und in Base64 codiert sind.

Sie werden größtenteils aus dem Ausland geschickt, ist es daher möglich, dass die Schauplätze miteinander in Konflikt stehen? dh. Wenn ein asiatisches Zeichen gesendet wird, ist die Base64-Kodierung in erster Linie erforderlich.

Unser Mailserver ist SmarterMail Enterprise 14.5 und Intermedia Exchange, Barracuda Firmware v7.1.1.003 (2015-09-28 16:36:19).

Beispiel: Paralleler Vergleich dessen, was der Benutzer sieht und wie die Bildquelle in Barracuda aussieht.

Der meiste Header ist dem Benutzer also immer noch verborgen, E-Mails sollten jedoch immer noch nicht so aussehen.

Was ich vermute, verursacht das Problem:

Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 

Ist dies ein Gebietsschema- / Kodierungsproblem, das unsere Spam-Firewall verwirrt?

1
Dies ist zu breit um zu antworten. Bitte geben Sie weitere Details an, wie zum Beispiel den verwendeten E-Mail-Server und möglicherweise ein Beispiel. Und warum ist der Barracuda-Header überhaupt ein Problem? Arjan vor 7 Jahren 0
Sind Sie in der Lage, die Konfiguration der Firewall zu ändern? Wenn dies nicht der Fall ist, können Sie dieses Problem nicht lösen. Wenn dies der Fall ist, wird dies wahrscheinlich unter Serverfault ausgeführt. Ramhound vor 7 Jahren 0
Barracuda-Header in einer E-Mail zu sehen, ist ärgerlich und sollte nicht passieren, es sei denn, wir betrachten die Nachrichtenquelle. Und ja, ich kann die Spam-Firewall-Einstellungen ändern. user108 vor 7 Jahren 0

1 Antwort auf die Frage

2
grawity

Nein, das ist nicht das Problem. Content-Transfer-Encoding ist absolut gültig und recht häufig.

Das Problem ist, dass eine leere Zeile direkt über der received-spfKopfzeile eingefügt wird . (In Ihrem linken Fenster gibt es aus genau diesem Punkt einen dicken roten Balken.)

Eine leere Zeile zeigt an, dass die Nachrichtenköpfe an diesem Punkt enden und der Hauptteil beginnt. Da sich die äußerste Content-Type-Deklaration (die multipart/relatedeine) unterhalb des falschen Trennzeichens befindet, betrachtet der Mail-Client des Empfängers sie nicht einmal, sondern greift lediglich auf den Nicht-MIME-Modus "Nur-Text" zurück.

Stellen Sie fest, bei welchem ​​Schritt diese leere Zeile eingefügt wird. Vergleichen Sie, was Barracuda erhält, mit dem, was es speichert (möglicherweise müssen Sie TLS vorübergehend deaktivieren). Prüfen Sie, ob es sich genauso verhält, wenn Sie eine einfachere Nachricht senden (dh nicht von MS Exchange). Senden Sie eine Testnachricht direkt an den Spamfilter, z swaks. B. mit .

Wir haben erst kürzlich SPF aktiviert und dies war ungefähr zur gleichen Zeit, als dieses Problem auftrat. Vielen Dank für Ihren Rat, ich werde weiter darauf eingehen. Könnte ein Update unseres Barracuda eine schnelle Lösung sein, um dies zu beheben? user108 vor 7 Jahren 0
* shrug * Ja, es könnte ein Fehler im Barracuda-Code sein, der den `Received-SPF`-Ergebnisheader einfügt - aber ich weiß nicht, ob das in der neuesten Version behoben wurde. Wenden Sie sich stattdessen an ihren technischen Support. grawity vor 7 Jahren 0