ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Attempted summary, SSP again

2006-01-27 10:53:58

----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>

So in other words, for the EXCLUSIVE (o=!) policy.

    DO NOT ACCEPT IF AN OA SIGNATURE IS MISSING.
    DO NOT ACCEPT IF A 3RD PARTY SIGNATURE IS PRESENT.

Only the first DO NOT.  The second DO NOT is unnecessary and
potentially harmful.

Ok, lets discuss that. But keep in mind that is not specification. The
specification clearly says "No 3rd party."  (So John, it is a REJECT.)

We can discuss a proposal to change draft specifications, I am all for
it. Steve wants us to wait, but ....

What if the author is forced to send via a route where a
3rd party routinely adds its signature without caring
about SSP ?

There are two parts here:

    - Exclusive domain using his domain in public
    - Non-Compliant DKIM/SSP resigner

That non-compliant DKIM/SSP signer is going to cause trouble for any
DKIM domain using that server.

Don't you think the exclusive domain is irresponsible for using it?  He
shouldn't be using an exclusive policy because, according to the SSP
spec, the DKIM verification can fail it.  It says no 3rd party. The
final machine will fail it.

If he wants to allow this or he is forced, then he needs to use a
different policy that allows 3rd party signing.

What if the receiver forwards his mail to another MRN, and
his clueless forwarder always adds a 3rd party signature ?

Again, consistency.  If anyone breaks it, it isn't going to work.  We
would be talking about non-compliant software - a buggy DKIM/SSP
software.

The important point is the first DO NOT. the second would at
best save you (as the checking receiver) a few lines of code.

if DKIM/SSP can not offer an exclusive, no 3rd party signing protocol,
then we are really just wasting our time :-)

That's like saying SPF has no -ALL policy :-)

It if  didn't, I don't then many would of supported it.  Not that it is
a MUST, but not to offer it?  I would not have been a very good idea.

Same with DKIM.  You need an exclusive policy and software must support
it.  If we can't have that confidence, and what's the use? :-)

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com







_______________________________________________
ietf-dkim mailing list
http://dkim.org