[Top] [All Lists]

Re: Sieve reject at SMTP time possible with which implementations?

2003-10-23 15:39:14

On 10/23/2003 5:24 AM, Rob Siemborski sent forth electrons to convey:

On Thu, 23 Oct 2003 ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
Which in turn means that handling reject at the SMTP level would be incompliant
with the sieve specification.
Of course nothing prevents an implementation from adding a separate action
other than reject for this. But SMTP level errors don't match up to sieve
actions very well. Why? Because sieve evaluation almost always requires having
the entire message on hand. In SMTP this means the only reponse code that's
left is the last one, where the server accepts or rejects the message on behalf
of all recipients. This becomes a problem when there are multiple recipients
and some reject the message and some do not.
I would like to see such an action (Shall we call it "refuse"?) in the next version of the spec, or in an extension. Anyone else? Something like "refuse MUST reject an email at the SMTP level, instead of sending an MDN, where possible, as this would be an anti-Joe-Job feature" It will otherwise behave like reject, but only permit a single line of response text. Issues of specifying response codes (4xx, 5xx, 4.x.x, etc) would need to be hashed out, 'where possible' would address the problem Ned raised, above. MDNs cause rejected joe-job spam to hit the victim's mailbox; SMTP level refusals usually don't. Revising reject's behaviour instead might be problematic as long/multiline responses that reject currently allows might be imposible to send at SMTP time. (I'm guessing on this one; maybe it isn't a problem to stuff multiline responses as one very long line.)

Thanks for all the comments, everyone!

While difficult/impossible in the SMTP situation, it can be done at the
"SMTP level," provided the last hop is over LMTP instead of SMTP, since
LMTP gives per-recipient status codes.