Mark Delany wrote:
Note: ADSP is incompatible with valid DKIM usage in which a
signer
uses "i=" with values that are not the same as addresses in
mail
headers. In that case, a possible workaround could be to add a
second DKIM signature a "d=" value that matches the Author
Address, but no "i=".
I'll start by proposing text that we could use if we adopted an
alternate definition of Author Signature based on the d= value only.
Then I'll describe what I think we'll lose by going to that
definition.
Given that i= is an arbitrary value assigned by the signer, the
question to me is what value does it add beyond what signed RFC2822
headers can do just as well. Eg, why not set an rfc2822.Sender Field
and sign that rather than invent i=?
IOW, what is the value-add in inventing yet another identity called
DKIM.i= when we already have rfc2822.From, rfc2822.sender,
rfc2822.resent-from, rfc2822.resent-sender and rfc2821.mailfrom?
Are you suggesting that DKIM.i= should have preference over signed
RFC2822 identifiers?
Good points Mark.
I think it may help if we can take a (small) step back into the
balcony, to better understand what ADSP was designed to over.
Without getting into details, can we summarize what the goals of ADSP are?
From my POV, I see three goals:
1) Provide a 1st party signature requirement authority.
2) Provide a new technical (and indirectly legal) justification
for the discarding of SMTP accepted message.
RFC 5321 has new semantics which relaxes the several decade old
tradition of requiring a bounce notification. Prior specs
did not have this relaxation. See RF5321 6.2.
For systems that are planning to process DKIM online
(at DATA stage), this was never an issue. ADSP will
help systems that always accept mail and process in
in a delayed fashion.
3) Lay the framework for future more advanced (beyond goal 1)
policy mechanisms, including 3rd party signatures.
It would of been my preference to see a simple YES/NO "Allow 3rd
party" signature policy that might cater to email services like
gmail.com which allows non-gmail but verified author from addresses
to be used with d=gmail.com signings.
Personally, the ADSP response is to light. If people are concern about
too many ADSP queries, then at the very least give it more data to be
returned that can be useful. I don't think we can cover all 3rd
party scenarios, but a simple 3rd party policy with a tag contains X
limited domains would be very useful.
DKIM=DISCARDABLE; 3PS=gmail.com, mipassoc.org
that will say that all my winserver.com mail will be signed either by
one of the following domains:
d=winserver.com (default signer based on from.domain)
d=gmail.com
d=mipassoc.org
I doubt a major amount of the domains will ever need more than 512
bytes yet alone 80 or 160 bytes! But even so, for these rare larger
needs, DNS is designed to handle a streaming request when needed.
No "opague" i= to confuse what is being attempted and valid signatures
will probably still need reputation and trust services. Good
signatures is not enough to trump security.
But this will at least allow for a good segment of market to use DKIM
in 1st and 3rd party authorized manner.
Its not ideal, but I think it would be better what we have now with
ADSP which is so limited even the authors believe its worthless.
Well, lets get it some reason to exist.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html