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
