Randall Gellens wrote:
(1) The document should make clear in the Abstract that it is updating
the existing "Reject" action.
Done. I've changed the first sentence of the Abstract to read:
This memo updates definition the SIEVE mail filtering language
"reject" extension, originally defined in RFC 3028.
(2) I suggest adding "The message is rejected after end of data" to
the end of the Abstract.
Do you mean after the DATA command? I don't think we should limit reject
to post-DATA case only, several people have expressed desire to use it
at RCPT TO: time.
(6) What is the rational for item 1 on the action list in Section 3.1
(as opposed to rejecting even if the MAIL FROM is null)?
You have a point. If protocol level rejection is available, the
recipient might just reject the message. For DSNs/MDNs, the server just
"MUST NOT generate" them, right?