これは mailop リストで最初に見たものですが、Reddit にも投稿されていました。以下に抜粋します。
クリーンなヘッダーと良好な評判にもかかわらず Gmail の受信トレイ配置に苦労している場合、ESP が知らず知らずのうちにメッセージを妨害している可能性があります。SendGrid の SMTP リレーは、List-Unsubscribe ヘッダーの値が 77 バイトを超えるとすぐに MIME エンコードするため、RFC 2047 および RFC 2369 に違反します。これにより、Gmail と Outlook での配信停止リンクが壊れます。この問題は内部で確認されていますが、未解決のままです。SendGrid は毎月 1000 億通以上のメールを送信しています。これは、配信可能性とコンプライアンスに現実世界の結果をもたらす、大規模な標準準拠の失敗です。
…
このヘッダーが 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 の両方で配信停止リンクの解析を壊します。その結果、受信者は UI 要素を介して簡単に配信停止できなくなり、苦情率の上昇や受信トレイ配置の低下につながる可能性があります。さらに悪いことに、Gmail の「元の表示」ビューはヘッダーをデコードするため、当初は書き換えに気づかないことがあります。
この動作は以下に違反します。
RFC 2047。List-Unsubscribe のような構造化ヘッダーでのエンコードワードを禁止しています。
RFC 2369。List-Unsubscribe ヘッダーの構文と構造を定義し、プレーン ASCII での解析可能性を想定しています。
Discourse が送信する list-unsubscribe ヘッダーの例は次のとおりです。
List-Unsubscribe: <https://meta.discourse.org/email/unsubscribe/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl>
ユニークなトークンだけで 64 文字あるため、送信する配信停止リンクは 77 文字を超えることが保証されます。
私たちは SendGrid を使用していませんが、多くのセルフホスティングユーザーが使用していることを知っているので、ここにいる全員に知らせることが重要だと思います。
ここに SendGrid ユーザーでこの動作を確認できる人はいますか？
