On 8/8/2017 9:59 AM, Bron Gondwana wrote:
On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote:
Is your concern that the last hop (or any other) can essentially do
a wholesale replacement of the message contents and that there is no
way to distinguish that from a semantically meaningless footer tweak?
I'm not sure that I understand your assertion that you can forge an
AS any more than you could forge a DKIM signature.
The whole point of verifying the chain of AS all the way back to i=1
is that you can tell that the message went through those servers, in
that order.
But it's bogus, because AS doesn't sign anything except itself and
some AMS and AAR. Once AMS doesn't validate any more (any change at
all) then you can't really tell that the message passed through there,
just the _a_ message passed through there.
So I could take an existing message that had passed through Google and
create a brand new message and pass it off as if it had passed through
Google before passing through my server on its way to you.
In which case - the AS is meaningless. It claims something which is
only true if everyone plays by the rules. But if everyone plays by
the rules, then it's excessive. You could just check the previous AAR
and know that the previous site had validated the hop before it, and
so on. It's crypto that doesn't add anything of value.
It's not actively damaging (other than the advice to do excessive DNS
lookups), but it's also not doing anything meaningful, and it's adding
something forgeable that looks like it means something.
I think we are falling back a Policy Model where we need to know what
the all important originating Author domain desires. What is the
expected here for mail processing by the domain?
I thought the main reason, purpose, the "PayOff" for ARC, was to help
deal with indirect mail breakage when a DMARC p=reject policy is set
and more importantly, SMTP receivers with embedded DMARC support have
begun honoring with hard 55x rejects or ACCEPT/DISCARD/SPAM local
policy logic.
It is the same problem ADSP had, but it wasn't fully realized, only a
proof of concept (demo) was shown (here in the list, by me). Receivers
had yet to implement or turn on the ADSP DISCARD switch but we
envisioned the indirect mail issue would begin when they did. So it
was foreseeable Mailing List members would begin to get unsubscribed
due to perpetual erroneous receiver rejections. DMARC proved it when
the idea was implemented and honored and the screaming began.
ARC is trying to automate something without the help of the
originating domain. If ARC is suppose to help save the "message" and
the author domain from using a p=reject on a mailing list or indirect
mail travel, then it leverage the DNS lookup it is already doing.
I think we have made this all too complex by resisting a policy
concept that helps with all this main processing. ADSP and DMARC had
to same issue, so when was ADSP abandoned and replaced with the
"Super ADSP" version called DMARC, the only difference was the
reporting stuff, which is really not helping.
Anyway, food for thought, a DMARC Tag Extension called ArcSeal. I'm
just winging it, so the ARC cogs can consider, or not:
ArcSeal=All ; All ARC seals must be valid start to finish.
ArcSeal=Last ; Only the last sender/ARC signer is
necessary (because
of the chain of trust).
I suppose there is a "Hops" count concept in there, but the ArcSeal
tag does not exist, the the message is in an indeterminate state. If
it exist, thats added value to the Domain declaring to the world what
it expects and allows, including desirable hard rejection.
The main thing is the automation. It help with an incentive to
encourage implementors sitting on the fence. It can help by relaxing
the rejection of the DMARC p=reject policy using ARC. Isn't that a big
help?
Personally, I really don't want to waste any more years working on
this ARC complex proposal and really, this DKIM project since the
early 2000s. Folks, we are approaching 15 years on this stuff!!!! It
has been a battle of the Trust Model vs Policy Model. We almost had
it VBR for TRUST and for Policy with ADSP (proposed standard) plus
ATPS (experimental) as a possible solution to the indirect mail
problem. But abandoned and replaced with DMARC (Informational) which
has the same problem ADSP was abandoned far.
Sorry for repeating the same thing, but DMARC is the same problem and
whey we are here, no?
So if DMARC is it, can we please fix it and have it work with ARC to
help resolve the indirect mail problem?
If not, than other than marketing bullshit, is there any "mail"
benefit and convincing reason why ARC should be implemented?
Thanks.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
