Scott,
I think that each domain would have a public key and the aggregator MTA
that is shared would sign on behalf of that domain
Jobob.com uses mx.isp.com to send mail
jobob.com would have a dns record containing public key information
mx.isp.com would sign using jobob.com keys.
Now conversely keeping jobob.com keys updated in a timely manner would
be time consuming so perhaps isp.com would have a policy that
I sign all mail
And maintain a single record. This would be trivially spoofable until
the message hits the verifier which would then fail the signature.
Thanks,
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Scott Kitterman
Sent: Wednesday, July 26, 2006 11:34 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options
On Wednesday 26 July 2006 11:03, Arvel Hathcock wrote:
I think we've got a winner here -- and deliverable within a reasonable
time frame -- if we can keep the core requirements to a minimum.
As we think through the definition of minimum, I think it important that
we
consider the class of domains that are not supported by one or more
dedicated
mail servers. Domains that send through shared servers are a large
fraction
of the domains in existence (although no doubt a much smaller fraction
of
e-mail being sent).
Is the concept of operations that these servers should sign using the
provider's key (so all signatures for the domain are 3rd party) or that
the
provider should manage multiple keys to support per domain keys and sign
the
messages first party for the domain?
When one says 'signs all messages' does that mean first party signatures
or
any signature? Announcing that all messages are signed, but may be
signed by
anybody, is trivially spoofable.
I understand and agree that we need to keep this to a minimum set of
functionality to produce something useful, I believe that there is a
irreduceable amount of complexity we need to consider. I think it's
better
to work through it now and produce a simpler policy protocol.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html