Hector Santos writes: > http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2
Thank you for the URL. In the following, I do not mean to discuss the concrete proposal as if it were WG business (I don't believe it is). I'm trying to understand what model of Internet mail system behavior is presumed, which I believe is WG business, as it is essential to framing BCPs and new protocols to improve security. > o Original Party Signatures (OP) > > * never expected > * always expected > * optional I don't understand the differentation between 'optional' and 'never' here in terms of real mail system behavior. What would the interpretation of a valid DKIM signature satisfying identity alignment? That's not a question about the spec (I can and will read the spec). The point is that in practice lots of admins do not read the spec, and even those who do often provide some heuristic interpretation rather than follow it precisely. I doubt the answers would be consistent with each other or with the spec. That sounds like trouble to me. We should prefer conceptualizations that are crisp and intuitive to non-IETF-ers. > o 3rd Party Signatures (3P) > > * never expected > * always expected > * optional Again, I don't understand the semantics of "expected" here, and they're quite different from the semantics of the same values for OP. Some 3rd parties will sign, others won't. What key do they sign with? Some will be authorized 3PS, some won't. etc. etc. I don't see how this three-valued parameter can possibly be a good fit for most "naive" admins' mental models, or for what they want the system to do. > Subscription Controls As I explain in more detail elsewhere, no policy framework I've seen can justify subscription controls. Overall, I get the impression that your mental model of email is framed almost entirely by the corporate transactional mail use case, where the employer can and does forbid "personal" and "indirect" use of mailboxes in the corporate domain. That's an important use case, but your proposals leave little room for reliable and convenient service to other use cases. Rather, they arrogate all policy decisions to Domain Owners, which will surely be a bottleneck for small organizations running mailing lists and new entrants wishing to develop new 3rd party email services. Such services will want to mitigate (ie, non-conforming behavior to avoid validation failure). You threaten non-conforming services with > thats the purpose of this *security* concept. Breaking it and > assuming the original domains will allow this to occur unchallenged > is not a good idea, playing with fire. but in practice it seems to me that the restrictions and inconvenience involved in conforming to your proposals is already everything those "original domains" can use to threaten mailing lists, and quite restrictive (at least) for other 3rd party services! In any case, Google and several MTA vendors were already providing relaxed implementations combining DMARC policy information with other metadata and content analysis in making acceptance decisions. Yahoo! and AOL quite obviously *want* the "security broken" (they thank us for doing exactly what you describe as "playing with fire"). Aren't they "original domains"? If they are, the "original domains" are going to have to sort things out among themselves to get a coherent protocol. If they aren't, aren't *they* the problem, not the 3rd party services who are only doing what their clients and their clients' domain owners want done? That is, shouldn't you advocates of full OP control figure out how to arrange that your protocol doesn't get hijacked by domains that permit unregulated use of 3rd party services by mailbox users? Steve _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
