Patryk Rzadzinski wrote: > Hello, > > Thanks for all the input. I have removed my domains from spamd's whitelist and > this problem is obviously gone, however this means it is gone after the > content > scan. > > I tried verify = helo and deny spf = fail, however both those checks were too > strict for some popular mail servers used in my country, which I assume > renders > them useless in my situation. > >> W B Hacker wrote: >> Neither 61.706.92.425 nor 212.62.52.156 have PTR RR >> As 212.62.52.156 has no DNS entry, it *cannot* match the HELO of >> 'BMARINKOVIC' >> 'BMARINKOVIC' is not a FQDN in any case. >> deny/drop/defer before enterign acl_smtp_rcpt. > > This is of course true, but is there any other way to drop the mail > beforehand, > if verify helo and spf are not options? > > Thank you in advance, > > -- > Patryk >
I wouldn't waste any time on spf. But there are several other tools. - rDNS fail - dynamic-IP RBL - local BL on IP and/or regexp (HELO) The way to keep so-called 'false' positives down is to; - whitelist those whom you feel you must - preferably by one (or few) IP rather than REGEXP. We even have a 'few' that pass only between specific 'pairs' of correspondents (branch office <=> HQ over pure-crap connectivity ISP / dumbhost that gets nearly *everything* wrong). - assign *weighted* scores for each faux pas, accumulate them, then compare the sum to per-domain if not per-user thresholds. A bit of tweaking of whitelists and score weighting, and most users 'regular' correspondents are not a problem even if trying to run their own MTA over dial-up off a Linux laptop. Yet you can still kill zombies effectively and 'early enough'. You need to wait until acl_smtp_rcpt to have the most info and options at hand, but any time *before* entering DATA phase is nearly as good as at first 'CONNECT' as far as resource load goes. That's 'decision point ONE' After mime, AV, and content scans, but while *still IN DATA* is decision point TWO. What you want to avoid if at all possible is making decisions in router/transports AFTER the correspondent has dropped off the teat. Here there be DNS backscatter risks. No such risk as long as the deny/defer/drop was onpassed DURING the initial session. OR the caller was one of your own AUTH'ed users, as you'll be droppng any DSN locally into their own POP/IMAP box. HTH, Bill -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
