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