Subject: [dmarc-ietf] handful of issues with draft-ietf-dmarc-interoperability-11

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Nov 2015 07:59:53 +0100

Hi everyone,

In doing a review of this current version, I note a small number of
issues that can be resolved fairly quickly, I think.

In Section 1:

>    Email messages that do not conform to other email specifications but
>    are considered legitimate by the intended recipients are not
>    discussed in this document.  

I know this may seem obvious to those in this working group, but I think
we mean other "IETF email specifications" above, and we should say so.

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".

In Section 2.2:

>    Message forwarding is a generic concept encapsulating a variety of
>    behaviors.

This sentence doesn't really convey anything relevant and should be removed.

The front of Section 3.1 may lead people to believe we are defining the
term "Mediator".  We are not.  It also comes from RFC 5598 and it should
be rephrased as follows:

   RFC 5598 also defines a Mediator is a hybrid of several component
types.  A Mediator is given
   special consideration in this section due to the unique issues they
face when attempting to interoperate
   with DMARC.

In Section 3.1.1, the following text is somewhat imprecise:

>    MSA interoperability issues with DMARC begin when an aMSA accepts a
>    message where the RFC5322.From header field contains a domain that is
>    outside of the ADMD of the MSA.  The ADMD will almost certainly not
>    be capable of sending email that yields Authenticated Identifiers
>    aligned with the domain found in the RFC5322.From header field.
>    Examples of this issue include "forward-to-friend" functionality
>    commonly found on news/article websites or "send-as" functionality
>    present on some MUAs.

In fact a number of systems have gotten around this by forming a message
in the browser and passing it to the MUA.  There is also an ambiguous
meaning to the second sentence.  For instance, it could mean that
someone buying email service from Google who happens to have their own
domain will not be able to send mail.  If SPF records are configured in
their domain, that is not the case.

And so I would propose rewriting this paragraph as follows:

   MSA interoperability issues with DMARC begin when an aMSA accepts a
   message where the RFC5322.From header field contains a domain that is
   outside of the ADMD of the MSA.  These issues manifest themselves in one
   of several ways, such as when someone uses a mail service with their own
   domain but has failed to properly configure an SPF record; or when an
   MUA attempts to transmit mail as someone else.  Examples of the
latter issue
   include "forward-to-friend" functionality commonly found on news/article
   websites or "send-as" functionality present on some MUAs.

It may also be worth mentioning in Section 4.1.1 an additional bullet:

 o  When implementing "forward-to-friend" functionality one approach to
avoid
     DMARC failures is to pass a well formed message to the user's MUA
so that
     it may fill in an appropriate identity.

Section 3.1.2.  The chapeau seems to dangle with a meaninglessly general
statement:

> 3.1.2.  Message Transfer Agents
>
>    MTAs relay a message until the message reaches a destination MDA.

I propose a slight change just for flow:

3.1.2.  Message Transfer Agents

   MTAs relay a message until the message reaches a destination MDA; and
are thus
   in a position to introduce interoperability problems.

Section 3.2

Based on the previous edit the first sentence can be removed.

Eliot

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 17 Nov 2015 09:19:59 -0800

> issues that can be resolved fairly quickly, I think.

Thank you for the suggestions. I'll work on incorporating them in the next
couple of days. If I have questions as I do that, I'll ping you (Eliot)
directly.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Nov 2015 20:32:51 -0800

On Tue, Nov 17, 2015 at 9:19 AM, Kurt Andersen <[email-masked]> wrote:

> directly.\\

Since this document is in WGLC, could we please do that on the list?

-MSK

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 19 Nov 2015 14:56:53 -0800

Yes, will do.

On Tue, Nov 17, 2015 at 8:32 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>> Thank you for the suggestions. I'll work on incorporating them in the
>> next couple of days. If I have questions as I do that, I'll ping you
>> (Eliot) directly.\\
>>
>