Чим відрізняється поведінка між зворотним шляхом, відповіді та відходу?


162

У нашій поштовій програмі ми надсилаємо електронні листи із таким заголовком:

FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com

Проблема, з якою ми стикаємося, полягає в тому, що деякі сервери електронної пошти негайно відхилять повідомлення та використовують замість або зворотний шлях (marketing@customer.com) на наш сервер mgmt відмов. Ми хочемо знати, чи модифікуємо в заголовку відповідь відповіді такою ж, як і шлях повернення, якщо нам вдасться впіймати всі відскоки.

Будь-які інші ідеї вітаються?

В якості посилань ми використовуємо такі документи: Повідомлення відмов VERP RFC

Розмір журналу SMTP для отримання відмов

EDIT 1: Ще кілька біт інформації, щоб побачити, чи зможемо ми вирішити це рішення.

Ми хочемо знати, в який момент сервер електронної пошти, що передає повідомлення, вирішить використовувати відповідь на шлях повернення. Ми помітили, що коли перший сервер smtp, що передає повідомлення, відхиляється, він надсилає його у відповідь, але коли це відбувається після одного переходу, він посилає його до шляху повернення.


1
А що із зазначенням полів Sender: та Precedence: Я хотів би дізнатися більше про те, як вони впливають на різні поштові сервери, коли справа стосується відмов та поза автовідповідями офісного типу. Хтось?
PapaFreud

Відповіді:


257

Почнемо з простого прикладу. Скажімо, у вас є список електронних листів, який надсилатиме такий вміст RFC2822 .

From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

Скажімо, ви збираєтесь надіслати його зі списку розсилки, який реалізує VERP (або якийсь інший механізм відстеження відмов, який використовує інший шлях повернення). Скажімо, це матиме зворотний шлях coolstuff-you=yourcompany.com@mymailinglist.com. Сеанс SMTP може виглядати так:

{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<coolstuff-you=yourcompany.com@mymailinglist.com>
{S}250 2.1.0 me@mycompany.com....Sender OK
{C}RCPT TO:<you@yourcompany.com>
{S}250 2.1.5 you@yourcompany.com 
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.
.

{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel

Де {C} і {S} представляють команди Client і Server відповідно.

Пошта одержувача виглядатиме так:

Return-Path: coolstuff-you=yourcompany.com@mymailinglist.com
From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

Тепер опишемо різні "ВІД".

  1. Шлях повернення (іноді його називають зворотним шляхом, відправник конверта або конверт з - всі ці терміни можна використовувати взаємозамінно) - це значення, яке використовується в сеансі SMTP в MAIL FROMкоманді. Як бачите, це не повинно бути тим самим значенням, яке знаходиться в заголовках повідомлень. Лише поштовий сервер одержувача повинен додати заголовок Return-Path у верхній частині електронної пошти. Це записує фактичного відправника Шляху повернення під час сеансу SMTP. Якщо в повідомленні вже існує заголовок Return-Path, то його заголовок видаляється та замінюється поштовим сервером одержувача.

Усі відмови, що виникають під час сеансу SMTP, повинні повертатися на адресу Return-Path. Деякі сервери можуть прийняти всю електронну пошту, а потім поставити її в чергу локально, поки у неї не буде вільної нитки для доставки її до поштової скриньки одержувача. Якщо одержувача не існує, він повинен повернути його до записаного значення Return-Path.

Зауважте, не всі поштові сервери дотримуються цього правила; Деякі поштові сервери повернуть його до адреси FROM.

  1. Адреса FROM - це значення, знайдене в заголовку FROM. Це повинно бути тим, кому повідомлено ВІД. Це те, що ви бачите як "ВІД" у більшості поштових клієнтів. Якщо в електронному листі немає заголовка відповіді-відповіді, усі відповіді людини (поштовий клієнт) повинні повернутися до адреси FROM.

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

Однак, як ви можете сказати, не всі поштові сервери відповідають стандартам або рекомендаціям RFC.

Сподіваємось, це має допомогти прояснити речі. Однак якщо я щось пропустив, дайте мені знати, і я спробую відповісти.


Це дуже корисно. Дякую за ваш час. Одне питання. Чи може статися так, що якісь відскоки збираються на відповідь на замість шляху повернення?
Гео

5
ну, технічно ви можете (але не повинні) додавати заголовок зворотного шляху, однак, якщо існує заголовок зворотного шляху, його слід перезаписати приймаючим сервером smtp. Якщо такої немає, її потрібно додати вгорі заголовків.
Дейв хотів

7
Мені трохи незрозуміло, як return-pathвикористовується. Якщо return-pathмається на увазі повернення адреси, чому поштовий сервер одержувача заповнить це поле замість відправника? Як сервер рецепта навіть знає, що туди помістити? Це не здається назад?
greatwolf

6
Поштовий сервер одержувача вставляє в повідомлення заголовок Return-Path, копіюючи значення, подане поштовим сервером відправника, в команду SMTP "MAIL FROM". Уявіть собі діловода в поштовій кімнаті, що відкриває пошту - вони дивляться на зворотну адресу на конверті і пишуть це вгорі листа (і викидають конверт геть).
Джон Хаскалл

5
І як Sender:заголовок укладається у все це?
Саймон Іст

150

Ще один спосіб подумати над Return-Pathvs Reply-To- порівняти його з поштою з равликом.

Коли ви надсилаєте конверт поштою, ви вказуєте зворотну адресу . Якщо одержувач не існує або відмовляється від вашої пошти, поштовий майстер повертає конверт на зворотну адресу. Для електронної пошти зворотна адреса - це Return-Path.

Всередині конверта може бути лист, а всередині листа він може направити одержувача на "Надіслати кореспонденцію на прикладну адресу ". Для електронної пошти, наприклад, адреса - це Reply-To.

По суті, адреса повернення пошти порівнянна із Return-Pathзаголовком SMTP, а Reply-Toзаголовок SMTP аналогічний інструкціям відповіді, що містяться в листі.


14
Це приємна аналогія.
Лукаш Коржибський

2
@Jesse Hobart +1 за приємне пояснення, я більше розгубився спасибі за те, що полегшило мене зрозуміти.
Абхішек

26
Я зазначу, що основна концепція, не зафіксована в цій аналогії, полягає в тому, що Return-Pathзаголовок додається сервером, що отримує пошту, а не відправником . Тож це більше так: ви можете записувати в конверт будь-яку адресу, яку хочете, але, щоб доставити його, вам доведеться віднести його до поштового відділення і показати їм свої водійські посвідчення (або інший посвідчення особи), і вони поставлять цю адресу на конверті. перед відправкою. Іншими словами, Return-Pathзаголовок настільки ж достовірний, як і перевірки, що виконуються приймаючим SMTP-сервером, де інші легко піддаються підробці.
cdhowie

5

для тих, хто потрапив сюди, оскільки назва питання:

Я використовую Reply-To:адресу з веб-формами. коли хтось заповнює форму, веб-сторінка надсилає власнику сторінки автоматичне повідомлення електронною поштою. From:є адресою автоматичного поштового відправника, так що власник знає , що це з інтернету - форми. але Reply-To:адреса - адреса, заповнена користувачем, тому власник може просто натиснути відповідь, щоб зв’язатися з ними.


1

Мені довелося додати заголовок Return-Path в електронні листи, надіслані екземпляром Redmine. Я погоджуюся з greatwolf, лише відправник може визначити правильний (не за замовчуванням) Return-Path. Справа така: електронні листи надсилаються за електронною адресою за замовчуванням: admin@yourcompany.com Але ми хочемо, щоб справжній користувач, який ініціював дію, отримував електронні листи відмов, оскільки саме він буде знати, як виправити неправильні електронні листи одержувачів. (а не адміністратори додатків, які мають інших котів :-)). Ми використовуємо це, і це прекрасно працює з exim на сервері додатків і zimbra як кінцевим поштовим сервером компанії.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.