У меня есть странный сценарий, когда два почтовых сервера обмениваются данными друг с другом, и мне нужна помощь в определении того, какой из них работает правильно.
Это немного сложно объяснить, поэтому я думаю, что SMTP-диалог, вероятно, самый простой способ описать это. В этом случае mailserver1.foo.com пытается передать сообщение на securityappliance.foo.com.
Рабочий процесс SMTP выглядит так:
220 securityappliance.foo.com ESMTP Sendmail 8.14.4/8.14.4; Tue, 6 Mar 2018 14:21:53 -0800
EHLO mailserver1.foo.com
250-securityappliance.foo.com Hello mailserver1.foo.com [1.1.1.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
MAIL FROM:<footestuser@foo.com>
250 2.1.0 <footestuser@foo.com>... Sender ok
RCPT TO:<recipient@foo.com>
250 2.1.5 <recipient@foo.com>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
X-Example-Header-Blah: Blah
From: <footestuser@foo.com>
To: <recipient@foo.com>
Subject: Message #1. I expect this to fail and am not concerned about that.
Extra text/attachments.
.
550 5.3.0 Requested action on message failed; message rejected
MAIL FROM:<completelydifferentsender@completelydifferentmessage.com>
557 5.3.0 Milter Implementation Error: Invalid argument passed
Итак, у нас есть два сообщения, которые были доставлены в одном файле как часть одного и того же SMTP-соединения. Первое сообщение приводит к ошибке 550 (мы знаем, почему это произошло). Затем вышестоящий почтовый сервер немедленно отправляет другой MAIL FROM: команда, и она отклоняется (поскольку устройство безопасности считает, что это часть той же транзакции.
Должен ли вышестоящий сервер выдавать RSET перед отправкой полностью отдельного сообщения? Или принимающее устройство безопасности должно понимать, что электронное письмо совершенно другое, и не рассматривать его как часть сообщения №1?
Я надеюсь это имеет смысл. Буду рад уточнить. Я пытаюсь определить, какая конечная сущность права, чтобы я мог задействовать соответствующий ресурс поддержки.
Прибор сломан.
RFC 5321 предельно ясно показывает, что после команды DATA все состояние сбрасывается, независимо от того, было ли почтовое сообщение принято или отклонено.
Из раздел 4.1.1.4:
Для получения индикации окончания почтовых данных сервер должен обработать сохраненную информацию о почтовой транзакции. Эта обработка потребляет информацию из буфера обратного пути, буфера прямого пути и буфера почтовых данных, и по завершении этой команды эти буферы очищаются. Если обработка прошла успешно, получатель ДОЛЖЕН отправить ответ ОК. Если обработка не удалась, получатель ДОЛЖЕН отправить ответ об ошибке.
(Акцент мой)
Это не новое требование. RFC 2821 сказал тоже самое.
Основываясь на выводе, я мог бы предположить, что в устройстве сломался milter, который мешает обработке почты. Только Sendmail обычно обеспечивает правильное соответствие RFC.