v7: CDO.Message - интересное поведение свойства DSNOptions #606116

отправляю почту через cdoMsg=СоздатьОбъект("CDO.Message"); если свойство cdoMsg.DSNOptions устанавливать в 0, или не устанавливать, письмо уходит нормально. если же пробую выставлять любое другое значение из  , письмо не уходит, при этом никаких сообщений об ошибках не выдаётся. это так задумано, или я чё не понимаю?

А MDNRequested не тоже самое делает ? Вполне возможно, что нотификация сервером не поддерживается, и нужно где-то специально запрашивать возможность её применения.

хмм... пробовал и с яндекса, и с мэйла, эффект одинаковый

"А MDNRequested не тоже самое делает ? "  это св-во говорит о необходимости отчёта о доставке, в DSNOptions же задаётся набор флагов ситуаций, при которых необходимо получить отчёт о доставке.

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

после Send  св-во SentOn устанавливается в текущую дату, т.е. письмо на сервер уходит. значит, CDO не при делах. но эффект всё равно непонятен

Не всегда - после некоторых полей сервер не знает, что вообще делать.

Ну, можно спросить у сервера, что он получает, так как ответ сервера должен в каком-то поле CDO быть. И, если происходит ошибка, то она должна обрабатываться на уровне обмена, так как сам протокол обмена не нарушается.

Там вообще очень интересно - метод Send возвращает ошибку, только в случае ошибки OLE-системы (то есть исключения) во всех остальных случаях ошибок нет.

кстати, а где у CDO лежит ответ сервера?

вот здесь давным-давно описано то же самое:

а теперь самое смешное: тела писем с установкой DSNOptions и без отличаются только полем "thread-index:" в заголовке

судя по всему, CDO криво держит стандарт RFC 822 оказалось проще не пользоваться всякими сомнительными свойствами, а самому задавать в заголовке: подтверждение о прочтении: Disposition-Notification-To X-Confirm-Reading-To подтверждение о получении/доставке: Return-Receipt-To конечно, не нашёл таких тонкостей, как "уведомлять только при отказе" и т.п., но, думаю, хватит и такого расклада.

и, кстати, всё равно подтверждение о получении/доставке поддерживает довольно мало почтовых серверов (из бесплатных)

Платных тоже немного, но они чаще всего сбрасывают сообщение, что письмо на них получено и дальнейшее отслеживание его судьбы невозможно. А MDNRequested ссылается на другой RFC с большим номером, что позволяет надеяться, что оно даже работает. Disposition-Notification-To - информирование о получении, тоже работает на клиентах, причём сказано, что клиенты смело могут игнорировать это поле. Confirm-Reading - это нотификация прочтения, то есть требует от клиента её выслать, когда письмо прочитано, но большинство клиентов только показывают кнопку. Return-Receipt-To - это подтверждение о получении, тоже обрабатывается клиентом, так как получением считается получение письма в клиенте. thread-index - это поле, которое присваивает уникальный номер сообщению, чтобы потом его можно было узнать по этому полю. Стандартом считается, что вместо него нужно использовать MessageId, то есть вполне вероятно, что сервер на это и обиделся.

самое интересное то, что поля MDNRequested  в заголовках писем, сформированных CDO, нет. как и в письмах, сформированных, например, The Bat! отличие в том, что при MDNRequested  = -1  в заголовок добавляется поле Return-Receipt-To, вот и всё. и обрабатывается оно не клиентом, а всё-таки сервером, ибо с некоторых коммерческих серверов в ответ на это поле, таки, приходит отчёт "delivered to the user mailbox" при изменении DSNOptions вообще никаких новых полей не появляется, письма с разными DSNOptions  отличаются друг от друга только значением поля thread-index, т.е., что бы там ни было, оно, видимо, кодируется в этом поле. самое интересное, что я вообще не нашёл RFC, описывающее это поле. по стандарту должно быть MessageId, но мелкомягкие не были бы мелгомягкие, если бы соблюли до конца стандарт, как всегда, выдумали свой велосипед, и это, кстати, не единственное мелкомягкое "понимание" стандартов, в гугле много тем и касательно некоторых других полей заголовка. кстати, пока гуглил, был удивлён, сколько же, оказывается, много разных стандартов RFC регламентируют описание почтовый сообщений. всех их осилить - это подвиг

Интернет начался с почты - поэтому, почтовых стандартов больше всего. Что касается DSNOption, то, скорей всего, они используются при отправке для сохранения копии сообщения в базе системы, чтобы потом получать события, привязанные к этому сообщению. Вообще, у Microsoft было сказано, что Thread-Index - это описание не сообщения, а группы, чтобы можно было сообщения объединить в какую-то группу - далее, нужно копать Exchange, где оно, скорей всего, и работает. Другое дело, что стандартный mail-server этого не понимает. Вот что нашёл, как это работает: То бишь действительно лисапед от Microsoft. И, самое главное, что серверам до этого "чуда" дела нет. Индексы используются для восстановления истории сообщений. P.S. при поиске Thread-Index в google почему-то открываются почтовые сообщения, в которых оно указано.