In other words, what Sieve implementations can be configured such that a
reject causes the email to be refused/not accepted during the SMTP
transaction, instead of accepted, and then bounced back to the alleged
sender (often, in the case of spam, a Joe-Job victim). Someone just
told me that Cyrus' implementation can't do this.
Note that Cyrus's implementation is actually LMTP, which presumes an
SMTP server will be sitting right next to it, so even if a 5xx failure was
issued, a bounce would still be generated by the SMTP server.
In any case, RFC3028 specifically says that an MDN is sent back when a
reject action happens.
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. The result is that SMTP level
rejection can never be anything but a special case for user sieves.
Ned