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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
