Chris Lightfoot wrote:
Tue, Jul 04, 2006 at 06:27:40PM +0800, W B Hacker wrote:

>>Chris Lightfoot wrote:
>>
>>
Mon, Jul 03, 2006 at 06:43:43PM +0200, Anthony wrote:
Hello.
In order to prevent spam, I'd like Exim 4 (I run Debian) to reject
incoming mail
if sender's domain doesn't exist.
What should be modified in the configuration files for this ?
you could switch on callout verification of senders, which
will test that the sender's address is deliverable, rather
than just that their domain exists -- add,
require verify = sender/callout
to the MAIL ACL. You could also check just that the
domain-part of the address exists with the dns lookup at
the same point, but I haven't an example to hand.

>>
>>This can result in a rather high 'false positive' rejection if
>>you use a 'hard' test, and for any of several reasons:
>>
many 'major' ISP's utilize 'pools' or clusters of servers,
>>often arranged as 'incoming' and 'outbound'. Your users may have
>>correspondents form many such. not.
-- not sure what this one means (the sender verification
callout will be routed as for a real mail, and so will go
to the advertised MXs for the recipient).
Therein lies the rub. There are a 'very large number' of domains
parked on NetSol, and I include many SME, not just 'vanity'
sites that use their cheap-enough MX nest.
Go and 'dig' that mess, and note copious DNS discrepancies.
The others are
fair points.
At the moment I'm switching on `hard' sender verification
on new installations, but on existing ones using it to
annotate mail with headers which can then be read by a
downstream statistical filter, so as not to break any
existing arrangements. A surprisingly large fraction of
mail lacks a verifiable sender, and it's not really
acceptable to demand that existing users adapt. In new
installations it's probably reasonable, at the moment.
Not 'surprising' to us. May get worse before it gets better, as
the NetSol case illustrates.
Seems the most heavily targeted ISP's see these early-abort
connections as spammer attempts to dictionary-harvest or confirm
validity of user ID's collected by other means.
verify = sender is falling into the 'less useful' category as
ident callouts did some time ago.
The other things to say of course are (a) the extra cost
of the sender verification callouts may not be justified,
especially as on some remote systems the work of routing
such a delivery may be large; and (b) once everyone is
doing it the spammers will presumably figure out that they
need to put verifiable sender addresses into their mail.
This will catch most zombies, but they don't resolve anyway.
It won't (by itself) catch a wrom that has harvested a
WinLuser's address book and used vlaid addreses as forged osurce
- but other acl's will do so quite well.
As to semi-legit spammers that at least briefly have a 'proper'
domain. DNS entries, and fixed-IP, at their end they can
wildcard accept, then silently drop the connection or discard if
the connection is not dropped right way.
And some are doing so already.
that happens we could all turn off verification and
avoid all the wasted bandwidth and disk seeks, but of
course in practice this won't happen and it will become
fossilised into MTA configurations everywhere.
s.a. w.r comparison to ident callouts.
As a rough poll, out of the 3407 spams and viruses I've
received since about one o'clock yesterday, 1576 had
verifiable senders at SMTP time, 1453 definitely bad
senders, and the rest gave temporary failure errors; so
about 50% here. of real mail since Sunday morning,
about 1.5% have bad sender addresses, made up of mail from
a small number of regular correspondents and a couple of
scripts. (But the number of bad senders there will be
overestimated slightly because we assume all addresses in
domains which don't accept mail from <to postmaster are
undeliverable.)
ACK - more risk of false positives than 'raw' verify = sender
(alone) can reliably offset.
Bill