At 9:29 PM +0100 8/21/06, Alexey Melnikov wrote:
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.
Thanks.
(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.
From reading the draft, my impression was that it was for use after
end-of-data. Perhaps instead of saying "The message is rejected
after end of data", say "The intent is to reject messages during the
SMTP transaction based on the message's characteristics, for example,
its recipient(s) or its data."
(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?
I meant, why require that messages with a null MAIL FROM be accepted
and discarded? Why not just fail the transaction?
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Get your facts first, and then you can distort them as much as you please.
--Mark Twain