Тема: Не приходят квитанции доставки/прочтения (вер. 3.00 проф.)

Привет всем!
Проблемка у меня есть. В свойствах ящика для нового письма выставлено требование квитанции об доставке и прочтении. Так вот, раньше в версии 2.хх это у меня работало, а после перехода на версию 3.00 проф. квитанций я больше не видел. Если что, то отправляю я через смтп рамблера. И поля "X-Confirm-Reading-To" и "Disposition-Notification-To" в заголовках ушедших писем есть. Может, у рамблера в политике что-то поменялось? Или все же Бат глючит? Потому как перемены подозрительно совпали со сменой версии Бата. Что это может быть?

Ну могу сказать одно:
1. Зависить от сервера получателя? У вас на все сервера не приходит подтверждение о доставке (у меня по крайней мере работает)
2. Зависит от получателя (лично я подтверждение о прочтении складываю в OutBox и отсылаю вручную, если вижу, что это нужно, иначе прочто удаляю их оттуда и отправителю ничего не уходит)!

Странность.... или я не очень понимаю....
как я понял "X-Confirm-Reading-To" (подтверждение прочтения) и "Disposition-Notification-To" (подтверждение доставки).

С выставлением обоих пунктов у меня видно в исходнике оба заголовка, а если только подтверждение доставки, то я ни одного из них не вижу в исходнике. В чем фикус?

Похоже за подтверждение доставки отвечает заголовок Return-Receipt-To, а двойственность заголовка подтверждения прочтения объясняется совместимостью....

Пока что в моих тестах мне подтверждения доставки с двух бесплатных серверов так и не пришли. Я уж не знаю то ли их не отдают, то ли их не пропускают. Но как защита от спама - это достаточно оправдано.
С одного корпоративного дошло подтверждение, а с другого нет.

> 1. Зависить от сервера получателя? У вас на все сервера не приходит
> подтверждение о доставке (у меня по крайней мере работает)

А у меня не работает
Только что отыскал у себя в корзине квитанцию о доставке на рамблер от мая прошлого года такого образца:

>Message delivered to '…@rambler.ru'
>LOCAL module(account …@rambler.ru) reports:
> Delivered to the user mailbox

Ведь было же. А только что снова на такой ящик отправил *- не пришло
Хотя уже и получил с того ящика это письмо.


> 2. Зависит от получателя (лично я подтверждение о прочтении складываю в OutBox
> и отсылаю вручную, если вижу, что это нужно, иначе прочто удаляю их оттуда и отправителю ничего не уходит)!

Согласен. Но это уже менее важный для меня пункт.
Мне главное, чтобы я видел, что письмо пришло куда надо, тоесть пункт первый.
А вот этого я пока не могу понять.

Сообщение от Vadim

Ну могу сказать одно:
1. Зависить от сервера получателя? У вас на все сервера не приходит подтверждение о доставке (у меня по крайней мере работает)
2. Зависит от получателя (лично я подтверждение о прочтении складываю в OutBox и отсылаю вручную, если вижу, что это нужно, иначе прочто удаляю их оттуда и отправителю ничего не уходит)!

Присоединяюсь к изложенному. Зависит от сервера получателя, как я убедился.

Ловите:
================================
Message delivered to '…@vadimka.spb.ru'
LOCAL module(account …@vadimka.spb.ru) reports:
Delivered to the user mailbox
================================

Версия бата 3.61.07. Так что все же это у вас или что-то локальное (например они идут в спам) или возможно режуться на сервере у прова (тож кстати вариант), но бат честно выставляет этот флаг и сервер честно отвечает, что письмо доставлено…
На всякий случай прилагаю письмо к своему ответу!

А как скажете, квитанция о доставке отправляеться только смтп-сервером, к которому идет непосредственное обращение при отправке, или может так же отправиться и следующими узлами в цепочке?
Если у меня вообще не приходят кв. о доставке, то, быть может, проблема в смтп-сервере?
Локальные проблемы исключены. Насчет провайдера пока не могу узнать.
Какие будут соображения?

Первое, общеполтические соображения - DSN приходится считать уходящей реальностью… Слишком многие MTA игнорируют поддержку этого расширения, и среди постмастеров все шире имеет быть мнение "нах не нужно"

Теперь по теме…

С момента появления этого SMTP-extension есть на настоящий момент два формата и два RFC (один устаревший), определяющий его функционирование
Первый RFC основывался только на добавлении строк в заголовок и обработке их принимающей стороной (причем мелкомягкие и тут отличлись и их поделия фтыкали свои строки подтверждения доставки )… отсюда в Мыше и пошло
Disposition-Notification-To:
Return-Receipt-To:

Свежий (актуальный) RFC новорит о том, что DSN требования присутсвуют в SMTP-командах в сессии от клиента к серверу и в междусерверных сессиях при пересылке, но Мыш поддерживает только старый формат… пэтому, чтобы про DSN в процессе не было забыто, понимать старый DSN должен SMTP-сервер отправителя… это умеют опять же не все…

По поводу того, кто и как должен отзываться на DSN

В идеальном случае (все серверы умеют DSN) нотификацию пришлет отправителю или тому, кого цказано уведомлять, последний сервер в цепочке, укладывающий письмо локальному для этого сервера юзеру…
Если все не так хорошо, и серверу поручено DSN и он это умеет, а следующий нет - то уведомление "Я отдал такому-то, а он неграмотный, так что может больше не быть ничего" отсылает именно этот последний сервер умеющий и знающий про DSN в письме

У рамблера стоит постфикс, который DSN ни из коробки, ни принудительно не понимает, оттого и тишина
exim можно попросить понимать DSN
sendmail тоже, причем он помжет понимать и DSN старого формата

про прочих маргиналов я не ильно в курсе… но если ваш SMTP в приветствии не сказал
DSN

то никаких ответов потом не ждите

Очень мощный ответ, спасибо.
Правда, некоторые детали не совсем понятны ввиду его высокой "низкоуровневостью", но такой исчерпывающей полноты я и ожидал
Знаю, куда и как копать.