Правильне використання заголовка SMTP "Sender"?

Наша веб-програма надсилає електронні повідомлення людям, коли хтось публікує новий вміст. І відправник, і отримувач вирішили отримувати електронні повідомлення від нашої програми. Готуючи таке повідомлення, ми встановлюємо такі заголовки SMTP:

ВІД: автор@example.com
ДО: отримувач@example.com
SENDER: webapp@mycompany.com

Ми вирішили використовувати електронну адресу автора у заголовку FROM, щоб спробувати забезпечити найкращий досвід для одержувача; коли вони бачать повідомлення у своєму поштовому клієнті, автор зрозумів. Щоб уникнути появи підробки, ми додали заголовок SENDER (з електронною адресою власної компанії), щоб зрозуміти, що ми надіслали повідомлення від імені автора. Після прочитання RFC 822 і 2822, здається, це призначене використання заголовка відправника.

Здається, більшість поштових серверів добре справляються з цим; повідомлення електронної пошти доставляється звичайно (якщо припустити, що поштова скринька одержувача існує, не перевищує квоту тощо). Однак, надсилаючи повідомлення ІЗ адреси в домені ДО адреси в тому самому домені, деякі приймаючі домени відкидають повідомлення з відповіддю на зразок:

571 неправильний IP - psmtp (у відповідь на команду RCPT TO)

Я думаю, це означає, що приймаючий сервер бачив лише те, що адреса заголовка FROM знаходиться у власному домені, і що повідомлення походить від сервера, який він не вважав уповноваженим надсилати повідомлення для цього домену. Іншими словами, приймаючий сервер ігнорував заголовок SENDER.

У нас є вирішення: webapp зберігає список таких доменів, які, здається, ігнорують заголовок SENDER, і коли заголовки FROM і TO знаходяться в такому домені, він встановлює замість заголовка FROM на нашу власну адресу електронної пошти. Але цей список потребує обслуговування.

Чи є кращий спосіб досягти бажаного досвіду? Ми хотіли б бути "добрим громадянином" мережі, і всі залучені сторони - відправники та одержувачі - хочуть брати участь та отримувати ці повідомлення. Одна з альтернатив - завжди використовувати електронну адресу нашої компанії у заголовку ВІД і додати ім'я / адресу автора до теми, але це здається трохи незграбним.

Ти дивишся на неправильні речі. Це заголовки повідомлень . Ви повинні дивитись на конверт SMTP . (Як вказано конверт, залежить від того, як саме ваша програма надсилає пошту в поштову систему. У багатьох системах конверт визначається аргументами командного рядка до програми утиліти для надсилання пошти.) Залежно від того, коли саме відбувається транзакція протоколу він приймає рішення про те, що 571 відповідь, SMTP-реле-сервер, можливо, навіть не бачив заголовків повідомлень.

Текст відповіді говорить про те, що адміністратор конкретного SMTP-сервера реле, з яким ви розмовляєте, обмежив те, що ви можете помістити в конверт SMTP. Схоже, скаржиться на частину конверта одержувача. Але це може бути відстрочення перевірки відправника конверта до вказівки першого одержувача, тому він може скаржитися на відправника.

Зауважте, що відправник конверта надсилає повідомлення про стан доставки, і вам не захочеться їх спрямовувати до випадкових людей у ​​всьому світі. (Крім того, що багатьом це не подобається, немає сенсу повідомлення про статус доставки для того, щоб ваша пошта поверталася будь-кому, крім вас.) Вкажіть себе як відправник конверта.

До MXречі, неправильно вимагати записів ресурсів. SMTP-реле-сервер може розташовуватися Aі AAAAзаписувати ресурси за відсутності MXзаписів про ресурси. Див. RFC 5321 § 5.1.

Я можу помилятися, але найбільш вірогідною причиною вищезазначеної помилки, особливо у випадку Постіні, є те, що домени, в яких вас відхиляють, мають сувору політику SPF. Більшість поштових серверів із SPF-перевіркою перевірятимуть лише заголовок From: їх не буде хвилювати заголовок відправника.

Щоб перевірити, чи не так, запустіть "dig + short TXT domain.com", де domain.com - це те, що дає вам повідомлення про помилку. Вам слід повернути щось на кшталт:

"v = spf1 mx -все"

Важлива частина - все. Це означає, що власник домену заявив, що коли-небудь надсилатиме електронну пошту лише з серверів, які виступають їх поштовими серверами, а вся інша пошта буде відхилена.

На щастя, якщо це так, ви можете активно перевірити, перш ніж надсилати електронний лист! Запропонуйте WebApp зробити перевірку SPF, коли користувач вводить свою електронну адресу. Якщо існує чітка політика, додайте домен у свій список. Існує нестача бібліотек для всіх мов, які можуть робити перевірки SPF.