Hi, Murray. MK> I think all of the points in your three messages are good input for a more MK> solid specification, but the timing is unfortunate as we just got MK> publication approval for -12 a week ago.
I apologize for my inadvertently poor timing; I was catapulted into all this last week when my parent domain (also my Organizational Domain) published an SPF record and a DKIM record, and we became concerned that they might implement DMARC, which could have a very negative impact on our mail services unless we take action quickly and become prepared to publish our own DMARC record. Thus, my sudden plunge into all these RFCs and this draft. :-/ MK> Making more changes post-approval MK> would probably not be a good idea, and by my reading none of them rise to MK> the level of being urgent to correct. That's certainly not my call to make; I can only give you a point of view from a fairly small site (about 10K users), where we're not looking to implement any of these mechanisms from scratch (we'll use software someone else wrote, mostly), but we *do* need to understand the implications of our (or our OD's) publishing DNS records for SPF, DKIM, and/or DMARC. Since, as pointed out by Tim Draegen, "DMARC implementations are already in the wild and deployed", one would expect to be able to determine what those implementations do, based on this spec. Sadly this hasn't been possible (so far) for me and my colleague Michael Jack Assels, despite our being two fairly smart cookies, with nearly a half-century of e-mail experience between us. I want to emphasize that I think that the documents in question (at least this draft and RFC7208 - I've barely skimmed RFC6376 on DKIM yet) individually are well written, but trying to understand them in context together is proving to be quite a challenge, and the lack of clarity on the HELO issue is the biggest part of the problem. We're now resorting to running tests to see how the biggest gorilla in this jungle (Google) handles all this. We've just completed an initial set of tests with SPF records only (no DMARC), which show that Google uses the MAIL FROM identity but seems to ignore the HELO identity even in the absence of DMARC, much to our surprise given RFC7208. We haven't yet run our with-DMARC tests, though I suspect that if Google doesn't look at HELO in a "pure SPF" environment, it probably won't use it in the context of DMARC either. If indeed it is the case that (at least in the context of DMARC) the HELO identity is not normally used, I would hope that introducing a small clarification to that effect could be done without significantly impeding the progress of this draft towards publication. Mind you, I don't know that the publication constraints are, so perhaps my hope is utterly in vain! But on the off-chance that it's not impossible to clarify this now, and assuming that my growing suspicion that HELO is ignored is correct, then I would propose: In section "3.1. Identifier Alignment": < For example, [DKIM] authenticates the domain that affixed a < signature to the message, while [SPF] authenticates either < the domain that appears in the RFC5321.MailFrom portion of < [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom < is null (in the case of Delivery Status Notifications). > For example, [DKIM] authenticates the domain that affixed a > signature to the message, while [SPF] can authenticate either > the domain that appears in the RFC5321.MailFrom portion of > [SMTP], or the RFC5321.EHLO/HELO domain, or both. In section "3.1.2. SPF-authenticated Identifiers": < In relaxed mode, the [SPF]-authenticated domain and < RFC5322.From domain must have the same Organizational Domain. < In strict mode, only an exact DNS domain match is considered < to produce identifier alignment. > In relaxed mode, the [SPF]-authenticated domain and > RFC5322.From domain must have the same Organizational Domain. > In strict mode, only an exact DNS domain match is considered > to produce identifier alignment. > > Note that the HELO identity is not used in the context of > DMARC (except when required to "fake" an otherwise null > reverse-path), even though a "pure SPF" implementation > according to [SPF] would check the HELO domain. In "4.1. Authentication Mechanisms": < o [SPF], which authenticates the domain found in an < [SMTP] MAIL command when it is the authorized domain. > o [SPF], which authenticates the domain found in an > [SMTP] MAIL command, or the domain found in the > [SMTP] HELO/EHLO command if the MAIL command has > a null path. Note that in contradiction to [SPF], > in the context of DMARC, the HELO identity is not > checked (except in the case of a null path). Even if it turns out to be impossible to make the above changes before publication, I'd be grateful to the people on this list for confirming (or disconfirming!) my understanding that HELO is not used in the context of DMARC (modulo the null path case). Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca +1 514 848-2424 x2285 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
