On Tuesday, January 20, 2015 16:38:43 Franck Martin wrote: > ----- Original Message ----- > > > From: "Scott Kitterman" <[email protected]> > > To: [email protected] > > Sent: Tuesday, January 20, 2015 2:29:10 PM > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > > > On Tuesday, January 20, 2015 16:14:32 Franck Martin wrote: > > > ----- Original Message ----- > > > > > > > From: "Anne Bennett" <[email protected]> > > > > To: "DMARC list" <[email protected]> > > > > Sent: Tuesday, January 20, 2015 1:44:16 PM > > > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > > > > > > > > > > > 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: > > > Your confusion on HELO is may be related to the fact that the HELO > > > string > > > is > > > only used when the MAIL-FROM: is empty? > > > > The confusion is that many people think that HELO is only used when Mail > > From is empty. It's been recommended as a stand alone test in both RFC > > 4408 and that's not changed in RFC 7208. It's just more obvious now. > > > > You do use postmaster@$HELO when Mail From is empty, which is relevant to > > DMARC use of SPF results. > > > > You can also use HELO on it's own, which is not. SPF pass on the HELO > > identity isn't useful as an accept criteria. SPF fail on the HELO > > identity > > can, however, be useful as a reject criteria. > > Yes, RFC7208 says evaluate both in parallel, but the result of an > spf=pass/fail is highly constrained on the success or failure of the MAIL > FROM spf test. > > I mean, it seems quite rare to find an SPF record on the HELO string but not > one the MAIL FROM string
Last time I had stats, it was about 10% as common as Mail From oriented records. Much less common, but I wouldn't say rare. When done this way, there isn't a singe "SPF" result, there are two: SPF/Mail From and SPF/HELO. Only SPF/Mail From is relevant to DMARC. In the case of the message having a null Mail From, you can still get two SPF results, they will just be the same. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
