On 12/5/20 5:20 PM, Douglas Foster wrote:
1) Michael. you have belabored your questions about DKIM vs ARC rather
too long. It is what it is.
ARC is an experiment. Experiments require peer review.
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.
DKIM is a mechanism which allows you to be assured that the forwarding
was done without altering. Since email is more like postcard than a
letter in an envelope that is a good property.
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.
Yes, but my bank seriously does not want any "acceptable"
transformations. There are no acceptable transformations. DMARC needs to
provide for that use case (and, in fact, it does currently). ARC is
setting up a situation where there is no way for my bank to say, "no
way, never".
4) On the future of ARC: The idea is harmless
To the contrary security protocols often create unintended consequences.
The are never "harmless" until proven so. An experiment is hardly
confidence-inspiring that it has been fully vetted.
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.
I'm starting to get a little more serious about my quip that the MLM can
insert a sed script in a header to unmangle the message since it knows
what transforms it has done, unlike the receiving MTA trying to guess
the common transformations.
Mike
On Sat, Dec 5, 2020 at 7:42 PM Michael Thomas <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmarc
<https://www.ietf.org/mailman/listinfo/dmarc>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
