On 8/16/2017 8:21 PM, Bron Gondwana wrote:
On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote:
On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote:
On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote:
If we even have a DMARC ARC Policy concept, than that may be
enough to begin pursuing the high cost of experimentation and
development here.
Beyond the protocol and usage specs, what are you looking for?
A practical purpose for supporting (implementing) this work. It
appears ARC wants the network to stamp mail "blindly" as the mail
travels from point to point. I am trying to grasp how it helps
resolve the main issue with "unauthorized" indirect 3rd party
signatures, in particular when dealing with strong, exclusive DKIM
signature policy models such as DMARC p=reject.
We spent a while thinking about this (Neil and myself from FastMail)
at IETF99 after learning how ARC works, and came to the conclusion
that ARC as specified can't help with DMARC p=reject.
The only way you could even hope (as a mailing list) to avoid
rewriting the sender is for every site that currently has DMARC
p=reject to change that to a new policy which explicitly means "only
reject if no ARC chain" - otherwise you can't stop rewriting sender
until you know that every receiver on your list is ARC-aware.
The MLS (Mail List Server) cam also reject submissions from
restrictive (p=reject) domains because that MAY be the intent of the
originating author domain. The MLS can so prohibit new subscriptions
by verifying the user's domain is not restrictive.
We need more protocol information from what extracted from DMARC. As
I see it, these are some of the boundary conditions:
DMARC p=reject; arc=none; ignore ARC, same as no arc= tag
DMARC p=reject; arc=all; reject if any arc seals is invalid
DMARC p=reject; arc=first; don't reject if first arc seal is
valid
DMARC p=reject; arc=last; don't reject if last arc seal is
valid
DMARC p=reject; arc=first,last; don't reject if first and last
arc seals are valid
arc=none (or no arc= tag) means the domain has no interest whatsoever
in ARC. It is a highly exclusive restricted domain and it expects that
complaint DMARC readers will honor the policy. No interference. This
is the highest payout with the highest security value.
It gets more relax with the others; first or last or first and last,
but with arc=all it is a tougher condition that requires all seals to
be valid. If any fails, reject.
I would also try to get more bang for the buck with a tag that could
informs MLS to honor the DMARC p=reject policy by restricting users
from a) subscribing and b) submitting list mail from restricted
p=reject domains, although I think such a tag is needed to tell the
MLS this. It should be a requirement, imo, cross all the teas, dot all
the eyes. If the MLS knows its going to be problematic, it should
restrict the subscription and submission to relax policies only.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
