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

Вот что я узнал из RFC 5321:

4.1.1.5. СБРОС (СБРОС)

Эта команда указывает, что текущая почтовая транзакция будет прервана. Любые сохраненные данные об отправителе, получателе и почте ДОЛЖНЫ быть удалены, а все буферы и таблицы состояний очищены. Получатель ДОЛЖЕН отправить ответ 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, но, возможно, кто-то уже просматривал его, и это сэкономило бы мне время.


smtp specifications lmtp
person Community    schedule 18.03.2017    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

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

person tripleee    schedule 18.03.2017
comment
Вопрос был про сервер: должен ли сервер отбрасывать почтовые данные, которые он получил, начал доставлять, но еще не подтвердил. Да, думая от имени сервера, я планирую сделать вид, что RSET никогда не происходит до подтверждения. Что еще более важно, я намерен подтвердить это до того, как начну обработку, потому что после того, как это уже не в моих руках, я просто передаю данные третьей стороне, которую я не контролирую. - person ; 18.03.2017
comment
Я немного изменил формулировку, чтобы сделать ее нейтральной с точки зрения перспективы. Я даже не осознавал, что было предвзятое отношение к клиенту; Я имел в виду общее слово «ты», так эффективно страдательный залог, но теперь я вижу, что это было не очень ясно. Спасибо за ответ! - person tripleee; 18.03.2017
comment
Что означает после команды DATA? Часто это означает, что после 354 OK возвращается сразу после DATA. В вашем ответе это должно означать после окончания индикатора данных только точку на линии. Я согласен, отправка чего-либо после .\r\n , но до подтверждения, то есть ответа, не должна рассматриваться как четко определенное поведение. Однако я подозреваю, что если это произойдет, то это не выбор клиента. Может быть проблема с передачей и задержка ответа, и клиент не знает, что делать. Итак, он сбрасывается и пытается снова. Если вы можете сделать свой ответ менее двусмысленным, я приму его. - person ; 18.03.2017

arrow_upward
0
arrow_downward

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

person Community    schedule 18.03.2017