Re: [dmarc-ietf] ARC vs reject

[Douglas Foster <[e-mail]>]

1) Michael. you have belabored your questions about DKIM vs ARC rather too
long.    It is what it is.

2) On the issue of "Do Not Forward":  It is certainly an available feature
of postal mail, which the postal service enforces.   Email has no central
authority to reliable enforce such a policy.   Just as importantly, no one
should (and few businesses do) consider email to be an environment where
sensitive information is transmitted.   Any competent bank will send an
email telling you to log into their website to obtain the sensitive
information.   I do not see a "Do Not Forward" policy as something that is
useful or likely to be used.

3) On the issue of p=reject:    You have been usefully pressing the
question of what purpose lies behind the technology.    In the case of
DMARC, the purpose is to block spoofed messages.    We know that mailing
lists turn a legitimate message into a looks-like-spoof message.   ARC is
trying to fix the false spoof, which is a worthy goal.   More precisely, it
is trying to provide information to the recipient system so that the
recipient system can determine that the message is forwarded but not
spoofed.

4) On the future of ARC:   The idea is harmless, but I do not see it
achieving the list-industry goal of eliminating From rewrite.  It actually
reminds me of DKIM without DMARC - a technology looking for an algorithm to
which it can contribute.    Since nobody can articulate how a recipient
uses ARC information to reach an expected conclusion, something important
is still missing.    As I wrote in my last post, I think it fails to
provide enough information for a useful algorithm to be defined.    Even if
that can be solved, there are bigger problems.   We have no algorithm for a
list to know if a particular recipient uses ARC, or whether it will use the
ARC information to draw the desired conclusion about list messages.
 Without those answers, the list is doomed to continue From rewrite even if
when it would not be necessary.    And much of this is about AOL in
particular, and the currently available information suggests that AOL is
not on board with ARC.

5) The work you and Alessandro have done with reverse transformation is
more likely to produce a solution for the mailing lists.   The lists will
continue to do From rewrite, but reverse-transform recipients can validate
the true source of the message and restore the From if desired.

On Sat, Dec 5, 2020 at 7:42 PM Michael Thomas <[e-mail]> wrote:

>
> On 12/5/20 4:21 PM, Dave Crocker wrote:
> > On 12/5/2020 3:37 PM, Michael Thomas wrote:
> >> "You can say, no I am smarter than those guys and I REALLY REALLY
> >> mean it, but see 2) above."
> >>
> >> This is really not about questioning my intelligence. eye roll. If I
> >> said the same thing to you, you'd be screaming bloody murder to the
> >> chairs to try to get me banned again.
> >
> > Note that what you have just done is, in fact, an ad hominem and
> > arguably does violate IETF participation rules.
>
> How can me pointing out that you would call that an ad hominem, become
> ad hominem?
>
> This is the bizzarro world that caused me to leave the last time.
>
> >
> > Again, the response you are objecting two exactly followed the
> > linguistic form of the setup you offered.  As such, the response was
> > not directly at you, the author of the posting, but at the
> > hypothetical person you formulated.
>
> Oh yeah, I just missed the implied royal you in the reply directed at me
> from somebody who has a long history of antagonism to me including petty
> 5xx messages from direct mail to him. Whatever was I thinking in the
> Panglossian world we live in?
>
> >
> >> If the publisher of the DMARC record cannot accurately state its
> >> desires/policy, that is a deficiency in the protocol. Reject means I
> >> want you to reject it. It doesn't carve out exceptions. ARC is trying
> >> to carve out exceptions. If it wants an exception, the originating
> >> domain should have a say in whether it desires the receiving domain
> >> to carve out an exception one way or the other.
> >
> > The domain owner might want all sorts of unreasonable things. Having a
> > way to let the domain owner publish demands that are widely ignored
> > indicates a seriously flawed semantic model. And that is, indeed, the
> > current reality for DMARC.
> >
> You are fixated on what the receiver must or must not do. I never said
> anything about that. That is a strawman. I'm pointing out that ARC is
> trying to get two states out of reject where there only is one. It is
> certainly not unreasonable for my bank to say "please reject anything
> that is not by the letter of the law". I don't want somebody to figure
> out how to game all of this ARC stuff to phish me from my bank. That is
> far from unreasonable.
>
> But you can say, no I am smarter than those banks and I REALLY REALLY
> mean it, but I don't care.
>
> Mike
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>