Steffen Kaiser:
RFC5321 sec 4.2.4
the same wording about:
o if attempts to deliver the message fail due to permanent conditions, or if repeated attempts to deliver the message fail due to transient conditions, returning appropriate notification to the sender of the original message (using the address in the SMTP MAIL command).
As I see it, no-one in this thread doubts that bounces are spec compliant.
Charles' point - as I understand it and to which I agreed - is the question *who* should generate a bounce. IMO the "receiving" MTA *must not* generate a bounce. The reason for this is not that any part of any RFC I know of does say so, but because of the simple fact that the receiving MTA very likely is *not able* to send a useful bounce since chances are that the sender address (i. e. the address the bounce should be sent to) is faked anyway. Accepting a mail and generating a bounce later will eventually make you a source of backscatter and get you blacklisted. The exception to this rule obviously is the case when you relay mail for your users (which is a different story anyway since you are the "sending" and not the "receiving" MTA).
Which comes down to Timo's original question, in order to remove the notification of Dovecot's deliver in favor of returning the proper exit code to let the MTA handles the stuff, seems to be good.
...if the MTA can find out about deliver's exit status before the SMTP transaction is completed...
Regards mks