I had some off-list discussions with Seth, who was very much against
my original proposed text, and he suggested an alternative
organization that would be more palatable to him. I've attempted to
set that out below. The idea is to remove the normative requirements
about using p=reject from Sections 5.5.6 and 5.8, and instead put a
broader discussion of the issues, along with the normative
requirements, into a new "Interoperability Considerations" section.
This makes it explicitly clear that any MUST/SHOULD stuff with regard
to using and honoring p=reject is an issue of interoperating with
existing Internet email features. I can accept that mechanism also,
and so, below is my attempt at writing that proposal up.
Barry
-----------------------------------------------------------------------------
— Section 5.5.6 —
ADD
In making this decision it is important to understand the
interoperability issues involved and problems that can result for
mailing lists and for deliverability of legitimate mail. Those
issues are discussed in detail in the Interoperability
Considerations section [see Section x.x].
END
— Section 5.8 —
OLD
Mail Receivers MAY choose to accept email that fails the DMARC
mechanism check even if the published Domain Owner Assessment Policy
is "reject". In particular, because of the considerations discussed
in [RFC7960], it is important that Mail Receivers SHOULD NOT reject
messages solely because of a published policy of "reject", but that
they apply other knowledge and analysis to avoid situations such as
rejection of legitimate messages sent in ways that DMARC cannot
describe, harm to the operation of mailing lists, and similar.
NEW
Mail Receivers MAY choose to accept email that fails the DMARC
mechanism check even if the published Domain Owner Assessment Policy
is "reject". In particular, because of the considerations discussed
in [RFC7960] and in the Interoperability Considerations section of
this document [see Section x.x], it is important that Mail Receivers
not reject messages solely because of a published policy of "reject",
but that they apply other knowledge and analysis to avoid situations
such as rejection of legitimate messages sent in ways that DMARC
cannot describe, harm to the operation of mailing lists, and similar.
END
— New section —
ADD
x.x Interoperability Considerations
As discussed in “Interoperability Issues between DMARC and Indirect
Email Flows [RFC7960], use of p=reject can be incompatible with and
cause interoperability problems to indirect message flows such as
“alumni forwarders”, role-based email aliases, and mailing lists
across the Internet.
Even a domain that expects to send only targeted messages to
account holders — a bank, for example — could have account
holders using addresses such as jo...@alumni.example.edu (an
address that relays the messages to another address with a real
mailbox) or finance@association.example (a role-based address that
does similar relaying for the current head of finance at the
association). When such mail is delivered to the actual recipient
mailbox, it will necessarily fail SPF checks, as the incoming
IP address will be that of example.edu or association.example, and
not an address authorized for the sending domain. DKIM signatures
will generally remain valid in these relay situations.
It is therefore critical that domains that publish p=reject
MUST NOT rely solely on SPF, and MUST apply valid DKIM signatures
to their messages.
Domains that have general users who send routine email are
particularly likely to create interoperability issues if they
publish p=reject. For example, domains that serve as mailbox hosts
and give out email addresses to the general public are best advised
to delay adoption of p=reject until the authentication ecosystem
becomes more mature and deliverability issues are better resolved.
In particular, if users in p=reject domains post messages to
mailing lists on the Internet, those messages can cause operational
problems for the mailing lists and for the subscribers to those
lists, as explained below and in [RFC7960].
It is therefore critical that domains that host users who might
post messages to mailing lists SHOULD NOT publish p=reject.
Domains that choose to publish p=reject SHOULD implement
policies that their users not post to Internet mailing lists.
As noted in [Section 5.8], receiving domains need to apply more
analysis than just DMARC evaluation in their disposition of
incoming messages. An example of the consequences of honoring
p=reject without further anaysis is that rejecting messages that
have been relayed by a mailing list can cause your own users to
have their subscriptions to that mailing list cancelled by the
list software’s automated handling of such rejections — it looks
to the list manager as though the recipient’s email address is no
longer working, so the address is automatically unsubscribed.
It is therefore critical that receiving domains MUST NOT reject
incoming messages solely on the basis of a p=reject policy by
the sending domain. Receiving domains must use the DMARC
policy as part of their disposition decision, along with other
knowledge and analysis.
Failure to understand and abide by these considerations can cause
legitimate, sometimes important email to be rejected, can cause
operational damage to mailing lists throughout the Internet, and
can result in trouble-desk calls and complaints from your own
employees, customers, and clients.
END
-----------------------------------------------------------------------------
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
