Mailing List Archive: SPF: Discuss

Authentication + Reputation = Accountability

Index | Next | Previous | View Threaded

mengwong at pobox

Jul 12, 2007, 6:53 PM

Post #1 of 3 (1058 views)
Permalink

Authentication + Reputation = Accountability

Cross-posted to the SPF and Karmasphere lists ...

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 have had a huge grin on my face for the last half an hour.

Why?

This afternoon I finally got up to speed with SpamAssassin's meta-rules.

and I just now got this report in my headers:

* -0.0 SPF_PASS SPF: sender matches SPF record
* -0.0 KS_REPUTABLE_DOMAIN_DNS RBL: Envelope sender in mengwong
whitelist feedset
* -123 AUTH_ACCOUNTABLE Envelope sender is both authenticated and
reputable

What does it mean? An SPF pass, on its own, means little; an RHSWL
match, on its own, means little; but together, they mean a lot.

To obtain that score of -123, the message has to pass SPF and the
envelope sender domain has to be whitelisted at the "mengwong.manywl-
v1.dnswl.karmasphere.com" RHSWL.

"mengwong.manywl-v1" is, in turn, a Karmasphere feedset that contains
multiple other whitelists, including the dnswl.org's sources, ISIPP,
Truste, and VeriSign's list of SSL certified domains.

More feeds are being added to that feedset as we discover new sources
of domain whitelists.

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!

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

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

I'm very happy!

(At this time, while Karmasphere is in beta, querying that whitelist
requires IP registration; it will not work if you do not have an
account. After we're out of beta that requirement will be dropped.)

Off to rummage through the fridge in search of champagne...

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

spamassassin at dostech

Jul 13, 2007, 12:21 AM

Post #2 of 3 (987 views)
Permalink

Re: Authentication + Reputation = Accountability [In reply to]

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

julian at mehnle

Jul 13, 2007, 2:39 AM

Post #3 of 3 (979 views)
Permalink

Re: Authentication + Reputation = Accountability [In reply to]

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads