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. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
