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

[Frank Ellermann]

Wietse Venema wrote:
 
> My understanding is that SSP provides statements by the rfc822.from
> domain

Okay, let's assume that's the case.  You take the 2822-From, assuming
there's exactly one address in it, extract the domain, and get the SSP
for that domain.  Now what:
 
> 1 - no valid signature                   (DKIM-base sans SSP)
> 2 - no valid signature, SSP requires one (DKIM-base plus SSP)

How does that work for resent / redistributed / news2mail gatewayed 
etc. cases ?  Maybe my SSP says "my mail is always signed".  And that
still allows me to say "From: me" in jabber or news or elsewhere, and
without DKIM signature (so far only defined for mail).

And somebody getting that message can inject it into SMTP using his
or her "Sender: somebody" + "From: me".  Still without DKIM signature,
or at best the signature of somebody, not me.  That's IMO a perfectly
legal use of 2822-header fields, and any SSP claiming that this is
"wrong" is FUBAR.

> 5 - valid signature, not blessed by SSP  (DKIM-base plus SSP)

That's the case where somebody (e.g. the news2mail gateway) adds its
signature and some corresponding Sender or Resent-From header field.

A policy talking about _only_ the 2822-From is strictly limited to
mail with PRA == 2822-From.  If that's the case, we could also say
that a policy always talks about the PRA, which would be logical to
some degree (determined by RFC 2822, not DKIM base).

Limiting SSP to mails with PRA == 2822-From is hocuspocus, the bad
guys simply add some dummy Resent-Sender (with a SenderID +all PASS
while they're at it), and the limited SSP would be bypassed.

We _could_ ask MUA implementors to flag mails with PRA != 2822-From
as "suspicious", but does that make any sense ?  Header fields like
Sender, Resent-From, and Resent-Sender are in use for decades, can
some obscure RFC suddenly claim that that's "suspicious" ?  
   
Frank