Re: [exim] a large number of domains fronted by Exim are ref…

"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