Re: [exim] Denying spam with forged from

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