Douglas Otis wrote:
On Feb 11, 2008, at 11:33 PM, Hector Santos wrote:
Doug,
The way I read SSP-02 is that MTA verifiers are no longer in the
picture but rather MUAs and it is MUAs that would do the DISCARDING:
discardable All mail from the domain is signed with an Author
Signature. Furthermore, if a message arrives without a valid
Author Signature due to modification in transit, submission via
a path without access to a signing key, or other reason, the
domain encourages the recipient(s) to discard it.
Apple's dictionary- recipient:
a person or thing that receives or is awarded something
In the SMTP "dictionary", recipients are RCPT-TO forwarding paths A.K.A
end users.
Per the SSP-02 abstract:
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transport Agents (MTAs) or Mail
User Agents (MUAs). The primary DKIM protocol is described in
This document describes the records that authors' domains can use to
advertise their practices regarding signing their outgoing mail, and
how other hosts can access, parse and interpret those records.
Clearly SSP is intended for use by both MUAs and MTAs. However,
discarding is _not_ appropriate at the MTA in many cases. Message
handling should be defined by a follow-on document. One such
document might be written for use at the MTA, and another at the
MUA.
Clearly, this is what happens when you have 2+ years of work
commandeered in less than 2 weeks (admittedly a thing of beauty in the
art of Mastering Chaos) with essentially a Find/Replace string stripped
down document (IMO borderline unethical) where you end up with
conflictive semantics all over the place.
Clearly, the attempt was to remove all MTA verifiers logic for filtering
DKIM mail with the only explicit semantics provided for a MUA entity.
But you also need to ask, why even have an SSP or ASP "skeleton"
document? We already have the model of ideas in RFC 4871 and RFC 5016.
At this point, I would vote for a total SSP/ASP abandonment rather than
risk the email world to such questionable late minute changes without
thinking much about the consequences.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html