Earl,
I don't see the problem here. I'm thinking PROTOCOL LOGIC here. In other
words, what will it take to make it DKIM work.
Lets go thru each policy to explain why it works. The overall assumption is
that all DKIM-ready signers, especally public domains such as gmail.com,
will double check DKIM SSP policies. Lets go thru each one:
SSP Policies:
NONE (no signing expected)
o=? WEAK (signature optional, no third party)
o=~ NEUTRAL (signature optional, 3rd party allowed)
o=- STRONG (signature required, 3rd party allowed)
o=! EXCLUSIVE (signature required, no 3rd party)
o=. NEVER (no mail expected)
o=^ USER
If example.com has a NONE or WEAK policy, gmail.com MUST not sign the
message.
If example.com has a NEUTRAL policy, gmail.com is allowed to do what it
wants because the target verifier will not fail a 3rd party gmail.com
signature.
If example.com has a STRONG policy, gmail.com MUST sign the message.
If example.com has a EXCLUSIVE, NEVER or USER policy, then gmail.com must
not allow the user to use this domain. It must honor these OA policies not
only to protect EXAMPLE.COM, but also the GMAIL.COM service from becoming a
source of exploition much like a OPEN RELAY SMTP server has become a source
of open-ended exploitation.
I see nothing wrong with this. Its not fuzzy. Its all technical protocol
logic based on satisfy domain policy.
The only real issue when consistent SSP checking behavior is adopted across
the board, is that it might suggest that a good bit of S/W must change.
You can't use DKIM for a mailing list service or a public service without
doing the SSP checking. Otherwise, it just opens the doors for exploitation
and when that happens, overhead and redundancy will emerge, and when that
happens, SMTP vendor and operators will quickly learn to turn off DKIM
processing all together since the potential will be really high that it will
be spoofed or bad information anyway. And since we are talking about the
PAYLOAD, an adminitration and user concern, ignoring DKIM will mostly be the
ultimate outcome.
So it is what its. A draft spec was written. The SSP checking is what makes
it work. If this is not what the designers wanted, well, I don't want to
buck the system, but I can't see how it work otherwise.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Earl Hood" <earl(_at_)earlhood(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Saturday, October 29, 2005 6:33 PM
Subject: [ietf-dkim] A potential problem with SSP bound to From
Some email service providers support the ability for their users
to specify an alternate From address from the address supplied
by the provider. I know Yahoo supports this for Mail Plus users
and Gmail now supports it also.
The problem is the email service provider may not be able to DKIM sign
messages sent out by such users since the domain in the rfc2822.From
does not match the sending domain.
Gmail does the following when using an alternate From:
From: user(_at_)example(_dot_)com
Sender: usersgmailname(_at_)gmail(_dot_)com
Now, if Gmail is able to bind a DKIM signature to Sender, then
it does not have worry about the SSP policy of example.com. If
it cannot, Gmail is discouraged to sign such messages since
signing them may reduce the chance the message gets delivered.
If example.com has an exclusive always-sign, non-3rd-party signing
policy, then the above user cannot do something like the above since
any DKIM verifier will fail such messages, regardless of Gmail's
signing policies.
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org