----- 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?
There is some text here:
http://trac.tools.ietf.org/html/rfc7208#section-10.1.3
The HELO string is not evaluated all the time, it is more like a fall back.
Also I have trouble to understand why you may be affected by your OD? What is
the relation between your domain and your OD? I suspect this is concordia.ca?
If you look at the public suffix list, google has put a separation at
blogspot.com level, so that each hosting domain, can be organizationally
separated.
https://publicsuffix.org/list/effective_tld_names.dat
I would suggest you publish a DMARC record in monitoring mode (p=none) so that
you get reports (and no impact) and better understand your email infrastructure
and what needs to be done.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
