This is a really good instance of what the base level requirements are.
On the one hand we can say that the requirement is that an ISP signing
on behalf of a customer actually sign on behalf of the customer. That
is, the d=customer.com rather than d=isp.com.
What I see here is the desire to actually have d=isp.com with the policy
saying that that is ok. One downside of this is that you'd require a policy
lookup because the From: address would still be customer.com, not
isp.com (ie, it looks like a third party). On the other hand, it doesn't
seem like it's a very big burden on the signing software to know what
domains it signs for, but I'm not as convinced about that from an
operational standpoint.
Mike
Scott Kitterman wrote:
On Wednesday 26 July 2006 11:54, Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
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.
And this is where there might be a complexity trade-off that is worth
considering.
If our policy protocol gives jobob.com the ability to say "all mail is signed
and the signer is isp.com" then the need for the added management complexity
associated with multiple keys for multiple domains on the same host is
mitigated.
It is, of course, important to note that this would place a requirement on
isp.com to ensure that messages it signed on behalf of jobob.com really were
from jobob.com.
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