ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Collection of use cases for SSP requirements

2006-11-17 14:26:35
On Fri, 17 Nov 2006 14:58:26 -0000, Wietse Venema <wietse(_at_)porcupine(_dot_)org> wrote:

My understanding is that SSP provides statements by the rfc822.from
domain, about domains that they know, and that sign their mail.

And if there are two addresses in the From header? And if there is a Sender as well (as there must be when there are two or more in the From)?

And then the various signatures on offer may be for domains that intersect in all sorts of interesting ways with the domains of the From(s), Sender, Resent- versions thereof, the List-* headers, etc. All taken in conjunction with which of those various headers were included in the hash. And also the order in which they appeared (assuming intermediate sites have respected the instruction to preserve the order of the Trace headers).

Specifically, SSP does not answer the following questions:

1 - Do I know the signing party. Finding the signing domain listed
    in the rfc822.from's SSP record does not mean that I "know"
    the signing domain: the bad guys can use SSP too. The answer
    requires information outside SSP and outside DKIM-base.

2 - Is the signing party a bad actor. I don't recall the SSP design
    has a feature to say "caution: example.com is a bad actor". Such
    information could be provided by SSP if it were suitably extended.

Reputation information cannot come from SSP. All SSP can tell you is what the owner of each domain chooses to tell you. Reputation information will come from third parties, so you have to decide which third parties to believe.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

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