Какие реализации SMTP обычно делают с почтовыми данными в ответ на RSET после DATA?

Question

Вот что я собрал из RFC 5321:

4.1.1.5. СБРОС (RSET)

Эта команда указывает, что текущая почтовая транзакция будет прервана. Любые сохраненные данные об отправителе, получателях и почте ДОЛЖНЫ быть отброшены, а все буферы и таблицы состояний очищены. Получатель ДОЛЖЕН послать ответ "250 OK" на команду RSET без аргументов. Команда сброса может быть выдана клиентом в любое время. Он фактически эквивалентен NOOP (т. Е. Не имеет никакого эффекта), если выдается сразу после EHLO, до того, как EHLO выдается в сеансе, после того, как индикатор окончания данных был отправлен и подтвержден, или непосредственно перед QUIT.

Акценты мои. Это говорит о том, что если мы получим RSET после индикатора конца данных ".", Но прежде чем мы отправим подтверждение, мы должны отбросить содержание сообщения, которое в данный момент доставляется. Это не кажется практичным. Более того, сервер может легко действовать так, как будто он получил RSET после того, как он отправил подтверждение - клиент не сможет узнать об этом. Пытаясь узнать, что обычно делается, я нашел это обсуждение https://www.ietf.org/mail-archive/web/ietf-smtp/current/msg00946.html где говорится:

Under a RFC5321 compliant "No Quit/Mail" cancellation implementation, after
completing the DATA state, the server is waiting for a pending RSET, MAIL
or QUIT command:

    QUIT - complete transaction, if any
    MAIL - complete transaction, if any
          perform a "reset"
    RSET - cancel any pending DATA transaction delivery,
          perform a "reset"
    drop - cancel any pending DATA transaction delivery

We added this support in 2008 as a local policy option (EnableNoQuitCancel)
which will alter your SMTP state flow, your optimization and now you MUST 
follow RSET vs QUIT/MAIL correctly. RSET (after DATA) aborts the
transaction, QUIT/MAIL (after DATA) does not. RSET is not an NOOP at this 
point.

В спецификации сказано, что выбрасывать ОБЯЗАТЕЛЬНО. Однако приведенная выше выдержка предполагает, что на практике это интерпретируется как МАЙ. Я мог бы взглянуть на код известных реализаций SMTP/LMTP, таких как Dovecot, но, возможно, кто-то уже рассмотрел это, и это сэкономило бы мне время.

Answer 1

В тексте говорится "индикатор конца данных был отправлен и подтвержден", что говорит о том, что клиент получил ответ сервера на DATA команда. Поскольку базовый протокол не поддерживает конвейеризацию команд, я не думаю, что отправлять что-либо после DATA но до ответа сервера (после точки, которая завершает DATA но прежде чем получить ответ от сервера) это четко определенное поведение.

Лично я не могу думать о более разумном поведении сервера, чем "притворяться, что этого не произошло".

Answer 2

Ответ здесь: https://tools.ietf.org/html/rfc1047. Они в основном говорят, что вы можете подтвердить, прежде чем начинать обработку, и на самом деле это рекомендуется сделать. Это не нарушает RFC 5321. Конечно, больше информации по этому вопросу было бы полезно, но я доволен rfc1047.