Verwenden Sie SendGrid beim Hosten von Discourse? Muss gelesen werden!

Ich habe das ursprünglich auf der Mailop-Liste gesehen, aber es wurde auch auf Reddit gepostet. Auszüge unten:

Wenn Sie trotz sauberer Header und guter Reputation mit der Zustellung im Gmail-Posteingang zu kämpfen haben, sabotiert Ihr ESP möglicherweise Ihre Nachrichten, ohne dass Sie es wissen. SendGrids SMTP-Relay verstößt gegen RFC 2047 und RFC 2369, indem es den List-Unsubscribe-Header per MIME kodiert, sobald sein Wert 77 Bytes überschreitet. Dies bricht die Abmeldelinks in Gmail und Outlook. Das Problem wurde intern bestätigt, bleibt aber ungelöst. SendGrid versendet über 100 Milliarden E-Mails pro Monat – dies ist ein massives Versäumnis bei der Einhaltung von Standards mit realen Folgen für Zustellbarkeit und Compliance.

Solange dieser Header 77 Bytes oder weniger beträgt, leitet SendGrid ihn unverändert weiter. Aber wenn der Wert 78 Bytes erreicht, schreibt ihr SMTP-Relay ihn zwangsweise mit der MIME-Encoded-Word-Syntax (RFC 2047) neu. Diese Kodierung ist in strukturierten Headern wie List-Unsubscribe ausdrücklich verboten.

Hier ist, was SendGrid stattdessen sendet:

List-Unsubscribe: =?us-ascii?Q?=3Chttps=3A=2F=2Fwww=2Eexample=2Ecom=2Funsubscribe=2F=3E=2C=3Cmailto=3Aunsubscribe=40opt?= =?us-ascii?Q?out=2Eexample=2Ecom=3E?=

Diese Kodierung bricht das Parsen von Abmeldelinks sowohl in Gmail als auch in Outlook. Infolgedessen können sich Empfänger nicht einfach über UI-Elemente abmelden, was zu höheren Beschwerderaten und einer geringeren Zustellung im Posteingang führen kann. Schlimmer noch, die Gmail-Ansicht “Original anzeigen” dekodiert den Header, sodass man sich der Umschreibung zunächst nicht bewusst ist.

Dieses Verhalten verstößt gegen:

RFC 2047, der kodierte Wörter in strukturierten Headern wie List-Unsubscribe verbietet.

RFC 2369, der die Syntax und Struktur des List-Unsubscribe-Headers definiert und die Parsbarkeit in reinem ASCII annimmt.

Ein Beispiel für einen List-Unsubscribe-Header, den Discourse sendet, ist:

List-Unsubscribe: <https://meta.discourse.org/email/unsubscribe/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl>

Allein im eindeutigen Token befinden sich 64 Zeichen, sodass garantiert ist, dass die von uns gesendeten Abmeldelinks über 77 Zeichen lang sein werden.

Wir verwenden SendGrid nicht, aber ich weiß, dass viele unserer Self-Hosters es tun, daher halte ich es für wichtig, alle hier darauf aufmerksam zu machen.

Gibt es hier SendGrid-Benutzer, die dieses Verhalten bestätigen können?

8 „Gefällt mir“

Ich habe eine unabhängige Bestätigung von @pfaffman (danke), dass er dieses Verhalten bei über SendGrid gesendeten E-Mails feststellt:

List-Unsubscribe: 
 =?us-ascii?Q?=3Chttps=3A=2F=2Fforum=2Econtoso=2Ecom=2Femail=2Funsubscribe=2Fb87c085a68d9210e78?
 =?us-ascii?Q?6478e2a54849e5bca9b8002ff0081b0a77466e0?
 =?us-ascii?Q?f71c27=3E?=
List-Unsubscribe-Post: List-Unsubscribe=One-Click

und dass der einfache Link Abmelden nicht vorhanden ist (was schlecht ist).

3 „Gefällt mir“

bestätige gleiche Tokenlänge

  List-Unsubscribe: <https://meta.discourse.org/email/unsubscribe/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl>
List-Unsubscribe: <https://discuss.mydomain.org/email/unsubscribe/7d1687b646074f0efc9abef16daeb42200f1beca5767de095960f4ac6b9b4ea2>

bestätige fehlendes Abmeldebild, nur Link ist vorhanden

außerdem akzeptiert Gmail durchgängig Anmelde-E-Mails von Discourse/SendGrid, platziert sie aber entweder im Spam oder kennzeichnet sie als verdächtig, hält Bilder zurück und platziert die E-Mail im Posteingang