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

Reply via email to