ietf-dkim
[Top] [All Lists]

[ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision

2006-08-24 00:10:39
Hector Santos wrote:

baseline scenario when there is no DKIM signature header:

    From: president(_at_)company(_dot_)com
    Sender: listadmin(_at_)mailinglist(_dot_)com
    To: someone(_at_)phishingtarget(_dot_)com
    Date: Wed, 23 Aug 2006 01:14:57 -0400
    Subject: Important new stuff!
 
How or what will a verifier us to extract policy information
from this message transaction?
 
What domain are we protecting in the above available header
block? company.com? mailinglist.com?

Good example.  The Return-Path is another piece of available
info, but if it matches the PRA listadmin(_at_)mailinglist it does
not offer anything new.

The receiver has a fourth piece of info, his address book (any
white or black list).  In a parallel thread about filters Phil
or John just discussed again that a "DKIM PASS" or similar from
unknown strangers is pointless.  With over 84% probability it's
spam like any other mail with or without signature (based on
95% probability unsolicited mail minus 11% misdirected bounces,
I don't recall where I read this some weeks ago).

So for your scenario, if you don't have listadmin(_at_)mailinglist
in your address book, and you also don't have president(_at_)company
in your address book, then you simply do not care what this is.

Otherwise you know one or both of them, white or black.  And if
it's a white-listed address you're supposed to know their SSP.

If that SSP is "sign everything" the mail is probably spam, and
you should reject it.  Or trash it.  If you intend to bounce it
the details wrt the Return-Path are important.

For an ISP if they happen to know that president(_at_)company should
be signed, always, they should reject it, unless they also know
that listadmin(_at_)mailinglist is a clueless but otherwise harmless
DKIM-munger.  In that case they should be also "sure" that the
sender really is the sender.

In your scenario there was no DKIM signature, therefore "sure"
means SPF PASS or PRA PASS or something in this direction.  If
there is a forwarding scenario behind the "clueless list" it's
a hopeless case, reject it if you expect a DKIM signature for
president(_at_)company(_dot_)

Frank


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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