spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Authentication + Reputation = Accountability

2007-07-13 00:23:36
Meng Weng Wong wrote:

Here's the snippet from my local.cf that does this:

  # karmasphere domain-based whitelist
header KS_REPUTABLE_DOMAIN_DNS eval:check_rbl_envfrom('mengwong.manywl-v1', 'mengwong.manywl-v1.dnswl.karmasphere.com.') describe KS_REPUTABLE_DOMAIN_DNS Envelope sender in mengwong whitelist feedset
  tflags   KS_REPUTABLE_DOMAIN_DNS    net

  score KS_REPUTABLE_DOMAIN_DNS -0.01

Since it's a whitelist query you'll want to add 'nice' to the tflags, not that it'll really make a difference in an end-user config.


meta AUTH_ACCOUNTABLE ((SPF_PASS || DKIM_VERIFIED || DK_VERIFIED) && KS_REPUTABLE_DOMAIN_DNS) describe AUTH_ACCOUNTABLE Envelope sender is both authenticated and reputable
  tflags   AUTH_ACCOUNTABLE   userconf nice noautolearn

  score AUTH_ACCOUNTABLE -123

That rule is exploitable so I wouldn't give it a score of -123. :(

If I set the envelope from to a domain on the whitelist it doesn't matter that it may fail an SPF check as long as I DKIM sign it myself and it verifies.

At a minimum I'd do something like this:

(SPF_PASS || ((DKIM_VERIFIED || DK_VERIFIED) && !(SPF_FAIL || SPF_SOFTFAIL || SPF_NEUTRAL))) && KS_REPUTABLE_DOMAIN_DNS

Although that only works if all the domains on the whitelist use SPF, so you could use the more restrictive:

(SPF_PASS || ((DKIM_VERIFIED || DK_VERIFIED) && !(SPF_FAIL || SPF_SOFTFAIL || SPF_NEUTRAL) && __ENV_AND_HDR_FROM_MATCH)) && KS_REPUTABLE_DOMAIN_DNS

But that's still abusable, absent SSP, if you don't also ensure that the domain who signed it (d=) is identical to the envelope from domain. Better yet, I can't think of a way (without adding code) to check that the signing domain matches the envelope/header from domain. You could use a rule to match both against the 'ALL' pseudo header... it's a big chunk of text to run a rule against, but at least it wouldn't be too nasty a regex (although there's a bit of back tracking). So you could add in something like this rule as a part of the metas above (which may not work, I haven't tried it):

header __DKIM_SINGED_BY_ENV_DOMAIN ALL =~ /\bReturn-Path: [^>]+([^(_at_)])+>.*D(?:KIM|omainKey)-Signature: [^:]*d=(\1);/

...and even that's exploitable if they only sign zero or one header fields and name the header field following the DKIM one something like "d=forgeddomain.com;". Perhaps opening an RFE for SpamAssassin to add code and rules to do this for you would be in order (if you want to make this work reliably before SSP gets going).

Related to this is the (def_)whitelist_from_dkim rules which, by default, will only fire if d= matches (right anchored anyway) the header from. You can check out the rules and the DKIM plugin to see what I'm talking about.

In any case, if I were going to do this (and I actually do), I would have the DNSWL return (set whatever bit) what auth method that the domain is expected to use so that you can only accept SPF for domains known to use SPF and DKIM for domains known to use DKIM, etc.


Regards,

Daryl

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

<Prev in Thread] Current Thread [Next in Thread>