Re: [exim] verify_sender

Russell Robinson wrote:
> Hi,
>
> On Sat, 15 May 2010 11:10:53 pm Lena@??? wrote:
>> "verify=sender" checks domain only. If it allows invalid domains
>> then either an "accept" succeeded before this "require" or
>> blame the NS you use.
>
> OK.
>
>> An attempt to check existence of a mailbox (i.e. to check whole
>> email address, not only domain) requires connection with the MX
>> and giving HELO, MAIL, RCPT commands - that is called "callout" in Exim.
>> Callouts to each sender is considered abuse and can cause you blacklisted.
>
> Really?
>
> Then how do you handle this case?

require verify = reverse_host_lookup

As the spammer trying to forge their identity will not be connecting from the
'real' spamtraps.org MX (a.mx.niet.net on IP 194.109.153.82), the connection
will be rejected.

End of that sort of problem.

Now - if 'the real' spamtraps.org actually IS trying to send to you... different
issue.

They are locally blacklisted here, so it won't come up.

>
> 1. Spammer Sam attempts to send you an email with forged
> address "spamtrap@???".

Checking that the IP connecting from had a PTR RR that was trackable to an A RR
or MX RR for the FQDN they claimed would have spotted it as a forgery right up
front. And/or in HELO phase..

Off-box calls are to the 'closest' nameserver, and are cached at more than one
place - so are both faster and 'cheaper' than contacting the 'alleged' sender's
MTA as well.


> 2. Exim verifies sender and accepts the email because spamtraps.org is a valid
> domain (from what you've said).
> 3. You reply to the email because it looks like a genuine enquiry (or maybe
> you have an automated "out of office" reply or similar).
> 4. You're blacklisted for sending email to a spam trap.
>
> The correct action, as I understand it, is to check
> that "spamtrap@???" is a valid email address (if you try,
> spamtraps.org will report 550 error - not a valid address) not just a valid
> domain at step 2.
>

Unfortunately, the response you might get from trying to make such an
address-specific CALLOUT is very much more Sysadmin/MTA implementation-dependent
than the general case of sender_verify for the domain.tld

The one that is satisfied that at least a functioning MX exists on the FQDN
*claimed*.

An rDNS test, OTOH is more consistent, as it relies on third-party-held
published DNS RR 'credentials', AND no need to hassle the sending server at all.

The rDNS code is in 'hosts.c' of the Exim source.

Yes - it will bail-out right away if there is no PTR RR, as that breaks any
chance of reliably tracking the RR chain needed to complete an smtp delivery to
the IP from whence the connection jumped-off or its listed MX.

Otherwise, it is not a 'dumb' test.

Far from it.

Exim tries several means to find a usable, even if imperfect, 'relationship'
between the IP from whence the submitter is connecting and 'good enough' DNS RR
trail that would permit a response by an end-user or a DSN from the system.

You WILL need to exempt your own user community, as they will ordinarily arrive
over broadband or dial-up w/o a PTR RR or even a fixed-IP.

You will PROBABLY need a whitelist for the (thankfully, diminishing) few who
cannot be bothered to get their DNS records properly set up. Over the past two
or htree years, ours has dropped from a few dozen to a dozen and a half to fewer
than half a dozen.

YMMV with a broader spectrum of correspondents, but progressively tighter
enforcement by 'the majors' has caused most folks to wake up and fix their DNS.

> You then reject the email at connection and you don't receive the spam, and
> you don't reply to it.
>

See above. 'maybe'.

And, of course, a 'commercial' spammer - one who doesn't mind who knows they are
blasting out tons of UCE - WILL have proper DNS credentials.

Those you just have to smack with RBL, LBL, regexp parsing, et al.

Bill