Quick review note:
The draft introduction talks about the "False Positive" problem with
restrictive DMARC policies -- the reason why we are here.
We need to keep in mind, DMARC also comes with "True Positives" DMARC
failures as well. DMARC Author Domains who will either be ignorant
(unaware of ARC) and/or does not wish to implement it (yet) and expect
all DMARC failed messages to be handled according (rejects/quarantine)
by receivers. This is expected to be especially true during the
experimentation and migration to support period. We are here because
of the reject/quarantine problem. People are not going to just stop
processing this filter until ARC proves itself.
For easier plug and play logic, the compliant ARC Receivers will need
a signal from the DMARC Author Domain that ARC can/should be applied
when DMARC failures. I suggest a new ARC section for an DMARC
extended tag, "arc=" and/or using the first Author Domain created ARC
header to signal ARC compliance.
For the DMARC Extended Tag (throwing it out there):
arc=0 ARC not expected to preempt failures (default)
arc=1 The Original Domain signs with ARC, not required
if author domain is the first seal.
arc=y The Original Domain MAY NOT sign with ARC but
others can to forward failed messages.
Something like the above to convey the various possibilities the
DMARC/ARC will mostly be encountering which will basically be:
if DMARC fails
{
//==========================
// NEW! Added ARC Policy support
//==========================
if Mail.Headers["ARC-Seal"].domain == AuthorDomain
or DMARC.Tags["arc"] != "0"
{
Add ARC seals/headers
return SUCCESS;
}
//==========================
Fail the message
return FAILURE;
}
Thanks
On 1/22/2018 5:47 PM, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting
& Conformance WG of the IETF.
Title : Authenticated Received Chain (ARC) Protocol
Authors : Kurt Andersen
Brandon Long
Steven Jones
Seth Blank
Murray Kucherawy
Filename : draft-ietf-dmarc-arc-protocol-11.txt
Pages : 54
Date : 2018-01-22
Abstract:
The Authenticated Received Chain (ARC) protocol creates a mechanism
whereby a series of handlers of an email message can conduct
authentication of the email message as it passes among them on the
way to its destination, and record the status of that authentication
at each step along the handling path, for use by the final recipient
in making choices about the disposition of the message. Changes in
the message that might break DKIM or DMARC can be identified through
the ARC set of header fields.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-11
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-11
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
