Используете ли вы SendGrid при хостинге Discourse? Обязательно к прочтению!

Я впервые увидел это в списке рассылки mailop, но это также было опубликовано на Reddit (https://www.reddit.com/r/sysadmin/comments/1oi6jju/sendgrid_silently_breaks_rfcs_by_mimeencoding/). Ниже приведены выдержки:

Если вы испытываете трудности с доставкой писем во входящие в Gmail, несмотря на чистые заголовки и хорошую репутацию, ваш ESP может незаметно для вас саботировать ваши сообщения. SMTP-ретранслятор SendGrid нарушает RFC 2047 и RFC 2369, MIME-кодируя заголовок List-Unsubscribe, как только его значение превышает 77 байт. Это ломает ссылки для отписки в Gmail и Outlook. Проблема была подтверждена внутренне, но остаётся нерешённой. SendGrid отправляет более 100 миллиардов писем в месяц — это масштабное несоответствие стандартам с реальными последствиями для доставляемости и соблюдения требований.

Пока этот заголовок содержит 77 байт или меньше, SendGrid ретранслирует его без изменений. Но когда значение достигает 78 байт, их SMTP-ретранслятор принудительно переписывает его, используя синтаксис MIME-кодированных слов (RFC 2047). Такое кодирование явно запрещено в структурированных заголовках, таких как List-Unsubscribe.

Вот что SendGrid отправляет вместо этого:

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?=

Такое кодирование нарушает парсинг ссылок для отписки как в Gmail, так и в Outlook. В результате получатели не могут легко отписаться через элементы интерфейса, что может привести к увеличению количества жалоб и снижению доставки во входящие. Хуже того, в представлении Gmail «Показать оригинал» заголовок декодируется, поэтому изначально можно не заметить переписывание.

Это поведение нарушает:

RFC 2047, который запрещает использование кодированных слов в структурированных заголовках, таких как List-Unsubscribe.

RFC 2369, который определяет синтаксис и структуру заголовка List-Unsubscribe и предполагает возможность парсинга в обычном ASCII.

Пример заголовка list-unsubscribe, который отправляет Discourse:

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

В уникальном токене содержится 64 символа, поэтому ссылки для отписки, которые мы отправляем, гарантированно будут превышать 77 символов.

Мы не используем SendGrid, но я знаю, что многие из наших пользователей с самостоятельным размещением используют его, поэтому считаю важным предупредить всех об этом.

Есть ли здесь пользователи SendGrid, которые могут подтвердить такое поведение?

8 лайков

I have independent confirmation from @pfaffman (thank you) that he’s seeing this behaviour on mail sent via SendGrid:

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

and that the Unsubscribe easy link is not present (which is bad).

3 лайка

confirming same token length

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

confirming missing unsubscribe image, only link is present

also, gmail consistently accepts discourse/sendgrid sign up emails but either places them in spam or labels as suspect, holds images and places the email in inbox