Subject: [dmarc-ietf] draft-ietf-dmarc-interoperability-12 posted

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 30 Nov 2015 17:15:52 -0800

I just posted -12 which includes fixes for all of the inputs I had seen
except for the following one:

On Mon, Nov 16, 2015 at 10:59 PM, Eliot Lear <[email-masked]> wrote:

> In Section 2.1, re SPF:
>
> >    SPF can provide two Authenticated Identifiers.  The DMARC relevant
> >    Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM
> >    [RFC7208] based on the RFC5321.MailFrom [RFC5321] domain, or, if the
> >    RFC5321.MailFrom address is absent (as in the case of "bounce"
> >    messages), on the RFC5321.HELO/EHLO SMTP domain.  The SPF validated
> >    domain in RFC7208.MAILFROM must be part of the same Organizational
> >    Domain as the domain in the RFC5322.From header field to be aligned.
> >    It is important to note that even when an SPF record exists for the
> >    domain in RFC5322.From [RFC5322], SPF will not authenticate it unless
> >    it is also the domain checked by SPF.  Also note that the
> >    RFC7208.MAILFROM definition is different from the RFC5321.MailFrom
> >    [RFC5321] definition.
>
> This section is sufficiently dense that I would suggest that an example
> would be very helpful.  Thee examples could go here or they could go
> elsewhere, but a handful would definitely help.  I'm happy to develop
> some, if people are comfortable with that.  Similarly, a DKIM example
> could be useful.  We could probably borrow a message from this mailing
> list to prove the point.
>
> In addition we should probably be matching case between RFC 7208 and
> this document as we did for RFC 5321 so that someone who is searching
> can easily find the name, and so "RFC7208.mailfrom".
>

I've been noodling on how to "fluff up" (in a non-pejorative sense) the
dense language that Elliot pointed out but did not want to delay the other
fixes any longer while I figure out a way to tackle this particular point.

--Kurt