"Greg A. Woods" wrote: > Error handling in SMTP (i.e. the use of newly generated notifications > messages which are sent to the original sender address, and with a null > sender path) is a core feature and requirement of the SMTP protocol. It > is inherent in its store-and-forward design and it "MUST" (STD's 3 & 10) > not be messed with if e-mail is to enjoy any degree of robustness and > reliability. > > Therefore a robust implementation of SMTP "MUST" make it difficult for > an ignorant postmaster to purposefully screw up e-mail error handling.
And what do you do when you're the victim of a joe-job? Do you accept ever single "valid" bounce message at ~25 million/day for a few days or do you reject the bounce messages directed at that address? Having been on the recieveing end of more than a few attacks of this significance, if this had been difficult to do I would have been more than peeved. Another thing, how do you propose to have the configuration parser detect this kind of 'dangerous cofiguration' given the many disparate ways it can be cobbled together? Maybe you'll be taken seriously when you have more patches and less attitude. And another thing, what about double bounces? If the envelope sender is undeliverable what do you propose to do? I for one take the data presented to me at face value and make no attempt to guess the state of mind of the sender (Oh? Did you mean that I should use the X-furrfu-errors: header for the bounce? My response: Get lost!). If the envelope sender is undeliverable, then it's undeliverable. An undeliverable bounce is just that, undeliverable and worthless except perhaps to update a blacklist with the sender address. We got ourselves listed in several dnsbls because of double bounce processing and broken parsers on the bl's end until I put an end to double bounce processing. Ian -- Ian Freislich -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
