Mailing List Archive

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:
[^>]+([^@])+>.*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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Meng Weng Wong wrote:
> On Jul 12, 2007, at 12:45 PM, Meng Weng Wong wrote:
> > Those of you who have been following the authentication movement
> > will remember that reputation was always part of the plan.
> >
> > It is the job of SPF/DKIM/etc to provide authentication.
> >
> > Karmasphere's job is to provide reputation.
>
> [...]
> I am tremendously pleased. For me, this is the culmination of
> several years of work: SPF offers authentication, and Karmasphere
> offers reputation. Together, they fight spam!

Congrats, Meng! Great job!

Daryl C. W. O'Shea wrote:
> 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.

We really should get SPFv3 started so domains can declare their use of IP-
address-based authorization (AKA SPF Classic) and/or other auth methods
such as DKIM.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGl0hmwL7PKlBZWjsRAucUAKDjnxcKc212VUyJQhGackysMCdGRwCfZKmt
p49UhgkIolZR0l+pBtBkZSY=
=PgBz
-----END PGP SIGNATURE-----

-------------------------------------------
-----------------------------------------------------------------------
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