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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
