[ietf-dkim] Re: Collection of use cases for SSP requirements
nobody at xyzzy.claranet.de
Fri Nov 17 12:36:49 PST 2006
Wietse Venema wrote:
> My understanding is that SSP provides statements by the rfc822.from
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" ?
More information about the ietf-dkim