> 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.
It would have to be done as an extension; adding something like this to
the base specification isn't realistic at this point.
I personally would have no objection to this extension.
MDNs cause rejected joe-job spam to hit the victim's mailbox; SMTP level
refusals usually don't.
Currently the best way to deal with this sort of trash is to use discard,
not reject. Reject really isn't intended to be used as an antispam tool.
As such, a refuse action is best compared to discard, not reject.
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.)
Revising reject's behasvior is a nonstarter IMO.
Ned