[ On Friday, June 24, 2005 at 09:44:27 (+0200), Ian FREISLICH wrote: ]
> Subject: Re: [exim] a large number of domains fronted by Exim are refusing bounces...
>
> 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?
In the worst of those kinds of situations sites which I help manage have
only suffered about 2 million/day bogus bounce attemtps, but it in one
such case it was for a couple of months steady.... However we didn't
have any trouble -- 99.999% of the _bogus_ bounce transactions that got
past all the other standard defenses and made it all the way to RCPT TO:
time were addressed to recipients that didn't exist and so they weren't
accepted either. If the normal basic defense measures had not
sufficient in that case then content based filtering could have been
used (though I would have had to move the service over to a bit more
beefy a machine than the 10-year old server it still runs on now :-)
As others have said earlier in this thread, bounces from the likes of
users that don't exist (and so cannot have ever sent any mail which
could be returned) are "bogus bounces", by definition.
If you think blocking SMTP transactions simply because they arrive with
an empty return path is the solution to any problem then you're using
the wrong protocol from the get go.
> And another thing, what about double bounces? If the envelope
> sender is undeliverable what do you propose to do?
That's more or less unrelated to the issue here, but...
Currently I configure all the mail servers I deal with in such a way
that the only time they ever have delivery problems (and thus any need
to use the envelope sender address) is when something catastrophic
happens (or in tiny windows of time while mailbox status information,
such as quota conditions, propogates to the efficient static databases
we use for these things).
I.e. if you worry about a flood of double-bounces then your mailserv is
not correctly configured.
> 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.
No argument there -- that's exactly what I do with undeliverable sender
addresses in foreign domains: I add them to my dead-mail.senders
database and never accept mail to or from them again until/unless I can
deliver the waiting bounce to them (or if it has expired then I can
deliver a test message). Also if a valid double-bounce ends up on my
plate because some idiot site is blocking valid bounces then I'll send
the evidence to rfc-ignorant.org myself, with no grace period or warning
whatsoever. I'm not a happy camper when I have to intervene in what
should have been a normal error handling and notification process.
(undeliverable sender addresses in one's own domain(s) is an entirely
different matter of course -- those kinds of problems need to be resolved)
> 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.
I'm not sure exactly what you mean by that. If your mailer does not
accept valid bounces then your site may indeed become listed on
dsn.rfc-ignorant.org and perhaps other similar DNSBLs (and/or in one of
the dead-mail.senders files on systems I operate), and your users will
unfortunately suffer (in more ways than one) as a result of your abuses
of Internet e-mail standards.
Like I said, if you think blocking SMTP transactions simply because they
arrive with an empty return path is the solution to any problem then
you're using the wrong protocol from the get go.
On the other how you deal with your own double bounces on your end is
your own business (though if you delete them unconditionally as one
other poster does then your users have my sympathy and I do not approve).
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
