Hello,
while I was hunting for issues with policyd-weight via google I cam across
incidents@securityfocus. While reading the thread I have seen that there is
some sort of misunderstanding which I would like to clarify.
Policyd-weight does NOT only lookup the MX record of the sender domain.
Policyd-weight does:
lookup MX sender and parent-domains ->
matches Client IP or its /24 /16 subnets ? great!
score=good-N
Don't look any further for DNS relationships
otherwise
lookup A sender and parent-domains ->
matches Client IP or its /24 /16 subnets ? great!
score=good-N
Don't look any further for DNS relationship
otherwise
lookup MX helo and parent-domains ->
matches Client IP or ist /24 /16 subnets ? great!
score=good-N
Don't look any further for DNS relationship
otherwise
lookup A HELO and parent-domains ->
matches Client IP or its /24 /16 subnets ? great
score=good-N
Don't look any further for DNS relationship
If above tests of A/MX of sender and HELO domains fail it attempts to verify
PTRs. It gets the PTR of client IP and compares it against Sender A/MX and
HELO A/MX. All in all it does some extensive but inexpensive DNS checks just
to make the hell sure we didn't miss at least one indicator that common DNS
records are set (even if set improper).
We CAN expect that at least ONE record matches in a fuzzy manner.
If not then we assign a score of bad-N * DNSBL scores.
In addition we check against RHSBL. Please note that policyd-weight uses
full GOOD scores if a thing is "ok" and mostly DNSBL weighted scores if a
thing is bad.
Why don't we use SPF records:
A) Spammer list dynamic hosts in SPF records - which renders policyd-weight
useless.
B) If we would add negative scores if SPF lookups fail, we would do harm
to forwarders and block them. We cannot differenciate whether it is a
forwarder or fake.
What is the goal of policyd-weight:
To not catch each and every possible spam but the most obvious which would
waste resources if accepted be the first SMTP instance.
To come around too restrictive MTA restrictions:
-> one RBL hit
-> one RHSBL hit
-> rejecting clients without PTR
-> rejecting clients whose PTR do not match HELO or forward (A) record
All of such MTA checks mean that we would reject if the other site has
just some issue. For organisations which follow the rule "be strict in what
you send but tolerant in what you accept" this might be too strict. As such
the existence of policyd-weight which aims to be tolerant but still preventing
from needless resource consumption.
I hope it is now clear that policyd-weight does not only make decisions on
a missing MX or non-matching MX. A matching MX is just a very good indicator
for a correct setup but a _rather bad_ indicator to say
"it's spam or incorrect". If an MX doesn't resolve to the client IP it does
NOT get penalized.
--
Robert Felber (PGP: 896CF30B)
Munich, Germany
------------------------------------------------------------------------------
This List Sponsored by: Black Hat
Attend the Black Hat Briefings & Training USA, July 29-August 3 in Las Vegas.
World renowned security experts reveal tomorrow's threats today. Free of
vendor pitches, the Briefings are designed to be pragmatic regardless of your
security environment. Featuring 36 hands-on training courses and 10 conference
tracks, networking opportunities with over 2,500 delegates from 40+ nations.
http://www.blackhat.com
------------------------------------------------------------------------------
