Hello David,
> Anyone who really knows what they're doing wouldn't be
> trying to set a non-empty MAIL FROM:<> on a sender
> callout. It's a denial of service attack waiting to
> happen.
Could you please elaborate on this point? I don't see why
using e.g. postmaster address should provoke DoS. Any
non-lame spammer can after all look up reverse DNS address
of the IP that does all those "sender verify" callouts and
conclude that's how it rejects their spam, doesn't it?
I'm having exactly this sort of empty "MAIL FROM:<>" problem
with some sort-of-TMDA providers:
1. someone at CursedProvider sends mail to one of my users.
2. my Exim does sender callout with empty "MAIL FROM:<>"
3. the remote MTA says "550 please verify yourself at
http://type.code.from.silly.image.to.prove.you.are.human.com".
4. my Exim concludes that sender cannot be verified and
rejects mail from CursedProvider.
In addition, empty MAIL FROM: makes this URL incorrect:
http://spamblocker.pop.pl?sender=&recipient=info@pop.pl
Obviously "sender=" should be
"sender=postmaster@???" or smth like that, you
get the idea.
Otherwise, incorrect "address verification" page is
displayed.
If I could use postmaster address in MAIL FROM: in sender
verify callout and verify manually my postmaster address, my
sender callout to those hosts would complete without
problem.
> The correct response for the OP is to get the admin of the offending
> broken mail server to fix it. Failing that, exempt it from callouts.
defer_ok in the sender callout seems to work as well, but it
makes the sender verification weaker, doesn't it?
Suppose this scheme becomes widely available and spammers
get drift of this, they would immediately exploit this
loophole.
--
Marcin Krol
