[Top] [All Lists]

Re: Review of draft-ietf-sieve-refuse-reject-02

2006-08-14 03:35:30

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?