B. Johannessen wrote:
> Graeme Fowler wrote:
>> An MX record is only useful in that it indicates where you need to send
>> mail for a given domain. It signifies nothing with regard to messages
>> coming from a given domain, so to filter/whitelist on it alone is, well,
>> perhaps not wise.
>
> This is of course correct. Trying to filter (or even score) messages
> because they arrive from (sender domain) non-MX hosts is a really bad
> idea. However; I've had some luck *subtracting* a small part of the
> spam-score for messages that *do* arrive from (sender domain) MX hosts.
Philosophy aside, 'Grocery Store Arithmetic' says you've just done the
same thing as that 'bad idea', but done it the long way 'round.
>
> My current default filter subtracts 3 points for being in the same /24
> as an MX, and an additional 2 points for actually matching an MX.
>
So +5 'demerits' for no match, +2 for full match, +3 for partial match..
and a 'threshold' ('RUDELIMIT' in our case) 5 points higher, and you
have the same net effect.
Save that I've seen scores of adders and half-adders from back in the
days when a 'CPU' was soldered-up from valves or transistors, but never
seen a 'subtractor' circuit.
Historically, extra clock-cycles are needed.
Adding is faster.
> Simplified ACL fragments:
>
> warn condition = ${if match_ip{$sender_host_address}{${lookup dnsdb{>:
> a=${lookup dnsdb{>: mxh=$sender_address_domain}}}}}}
> set acl_m_score = ${eval:$acl_m_score-2}
>
> warn condition = ${if match_ip{$sender_host_address}{${sg{${lookup
> dnsdb{>: a=${lookup dnsdb{>:
> mxh=$sender_address_domain}}}}}{(([0-9]+\.\){3\})[0-9]+}{\$\{1\}0/24}}}}
> set acl_m_score = ${eval:$acl_m_score-3}
>
> So far I haven't noticed any spam slipping through because of this test,
> and I've seen many non-spam messages that would have been rejected
> without it.
>
>
> Bob
>
