Chris Lightfoot wrote:
> On Tue, Jul 04, 2006 at 06:27:40PM +0800, W B Hacker wrote:
>
>>Chris Lightfoot wrote:
>>
>>
>>>On 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. Or 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.
> Once 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. Out 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
