Stephen Farrell wrote:
I don't think its too verbose, but I don't understand how it
answers the question I asked ;-)
You want to add a requirement "The protocol MUST...state..."
I wanted you to give me a strawman statement that would meet
that requirement (that you think is reasonable).
LOL, somewhere we're out of sync. AFAIK we're still discussing
the "requirement-02", is that correct ? For the "requirements"
we don't need to go into details about gateways etc., but we can
"require" that the future SSP defines 'DKIM signing ciomplete'
in a way understood by anybody considering to publish some kind
of "I sign everything" policy.
IFF "I sign everything" means "reject or even annotate (= drop)
all mails with a 2822-From 'me' without 'my' signature" (incl.
"known" cases of signatures broken by irregular mailing lists),
then the future SSP has to enumerate all "known" cases where it
will cause havoc.
So far we have irregular (mutilating and munging) mailing lists.
Another case are news2mail gateways. A third case are articles
in moderated newsgroups, depending on how the server forwards it
to the moderator. USEFOR is about to fix the latter, but until
it's deployed worldwide in Netnews... let's say 2020 or later :-(
There might be more cases (MMS-to-mail, IM-to-mail), I can't tell,
I only know why I don't like PRA. The SSP-"I-sign-everything" is
apparently _far_ more restrictive than spf2.0/pra. We could as
well tell potential users that they can draft a no-nonsense (= no
NEUTRAL) PASS or FAIL PRA-policy. If they can't figure out that
one they also won't understand WTH "DKIM-signing-complete" is.
They don't need to publish their no-nonsense PRA policy, but they
do need a DKIM-signing agent somewhere on all of its routes. For
some domains it might be as simple as a decree "we have one MSA --
formerly known as a smart host -- and you're gonna use it or die.
And stay away from mailing lists and Netnews with from-addresses
in this domain".
For other domains wishing to be 'DKIM-signing-complete' it might
be less simple. For a domain bank.example it could be an idea to
create a subdomain office.bank.example for mails sent "from the
office" (i.e. DKIM-signing-complete). Maybe the future SSP could
mention this deployment strategy. Maybe their MSA could rewrite
any From bank.example to From office.bank.example before signing
it. That's not covered by RFC 4409 at the moment, maybe we need
a son-of-4409 (?)
A domain claiming to be 'DKIM-signing-complete' has to be sure
that there's some DKIM-signing agent on _all_ routes before one
of their spf2.0/pra PASS or NEUTRAL IPs. Otherwise they screwed
up, causing harm for mails "from" their domain.
I think that last is a fair point. But I'm still not convinced
that it's up to the DKIM WG (now) to figure out all details of
all such gatewaying cases, which is where we'd be heading if we
start on that road.
Not *now*, now we IMO only need a requirement that any future SSP
"I sign everything" has to be very clear about its implications.
No weasel words like "annotation as suspicious". We're talking
about reject or maybe even drop depending on the receiver policy
(if they look at SSP at all). And no unclear uses of "sender", a
2822-From isn't related to the "sender" in many valid cases.
E.g. the word "sender" in requirements-02 chapter 4.1 4th paragraph
is unclear, apparently it should be "author" if it's limited to the
2822-From. In chapter 5.3 it's not yet obvious what happened with
Alice's "I sign everything" SSP after Bob resends it. Did he also
resend her signature ? Has one of Doug's anti-replay MDAs stripped
her signature ? What if Bob feels like resending Alice's mail 25
years later, will it still work as expected and required wrt STD 11
and 2822 ? (Of course not, SHA-256 will be long dead then, the SSP
"I sign everything" concept has also temporal limits.)
The longer I think about it the more I feel that this SSP "I sign
everything" could be handled as special application of spf2.0/pra.
It's in essence the same mess. Adding "'I' DKIM-sign everything"
_syntax_ to spf2.0/pra is simple, and maybe the SPF folks will add
this _syntax_ anyway IFF the semantics is clear.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html