Re: [Exim] Callout verification

On Thu, 6 May 2004, Andy Fletcher wrote:

> Many mailservers are configured (against the RFC guidelines) to refuse
> mail from "<>". When performing a sender verify callout from exim,
[..]
> It seems to myself it would be preferable (though there may be good
> reasons against this, please educate me) for the verify to only fail
> if the 5xx error code is generated after the "RCPT TO:"

Despite all the related discussion since, I'm still having a problem
with your logic here. Either the address will be verified by the
callout, or it won't. If the peer MTA refuses (in this case, at the
MAIL FROM:<> stage) to verify the address, then I don't see how the
address can be verified (in that particular callout). What *do* you
want the ACL statement to do if this happens?

> Primarily I'd like any discussion to focus around my point in
> paragraph two, regarding the point at which the 5xx error is generated

I thought I did that. The remote MTA is going to do whatever it does.
You don't have any control over that. If they reject bounces, you
aren't going to be able to send them any kind of protocol-correct DSN.
It's up to you to work out whether that's the kind of sender you'd
want to accept mail from.

I don't see what influence you are hoping to have on "the point at
which the 5xx error is generated", nor what you're hoping to do as a
consequence of it.


Just as an idle aside - in my situation, I'm pretty sure (gut feeling
rather than actually counting them) that the majority of
spammer-presented sender addresses which have failed callout because
they responded "501 input error" to MAIL FROM:<> have been Chinese.

There have been lots of domains involved. And they don't all respond
to HELO in the same way, so it doesn't look as if there's a particular
piece of software that they're all using. But I haven't really
studied it in detail.

Here for example is @1635.net (these are just randomly plucked from
our list, no hate campaign intended):

Connected to 218.104.60.85.
Escape character is '^]'.
220 **************************2************************************
HELO our.domain.example
250 HELO
MAIL FROM:<>
501 input error.

That looks like one of those Cisco SMTP gateways from hell, no?

Here for example is @songscorp.com

220-W E L C O M E T O H I C H I N A S M T P S E R V I C E !
220-~
220 mxvip5.hichina.com ESMTP server (quarkmail server - version 1.2.1) ready at
Fri, 7 May 2004 20:30:14 +0800
HELO our.domain.example
250 mxvip5.hichina.com Hello our.domain.example
MAIL FROM:<>
501 where is <...> in that?

OK, let's not drag this out with examples...

Depending on what kind of a day I'm having, when spamming is involved
(irrespective of whether the sender address seemed genuine or faked),
I put such domains either into a list called "unreachable_domains"
(which means they'll get told we can't accept mail from them because
they're either unreachable or not responding correctly to SMTP) - that
then only gets fixed by them complaining to our postmaster, or by one
of my occasional clearouts; or I put them into callout_domains (which
means we try a callout and then they get told we can't accept mail
from them because they repudiated the sender address) - but that would
be self-healing if/when they start responding correctly to callouts.

Of course, if it's a misbehaving domain that we -do- want to hear
from, we simply don't put it into either of those lists.

hope this is useful to somebody.