Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/5/20 8:14 PM, John R Levine wrote:

On Sat, 5 Dec 2020, Jim Fenton wrote:
Of course not.  That's just the tiny gorillas stamping their teensy 
feet. Why would anyone expect that the people publishing that flag 
actually understood what it meant?  Many will just turn it on 
because someone said it's "more secure."


FWIW, I don’t think a lot of the people publishing p=reject 
understood the implications of that, either. This is not 
significantly more arcane.


Then I think we agree.  There's no difference from p=reject and 
p=reject-I-really-mean it.



If the operating assumption is that people implementing DMARC is that 
they are all illiterate, then our project is done.


Mike


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[John R Levine]

On Sat, 5 Dec 2020, Jim Fenton wrote:
Of course not.  That's just the tiny gorillas stamping their teensy feet. 
Why would anyone expect that the people publishing that flag actually 
understood what it meant?  Many will just turn it on because someone said 
it's "more secure."


FWIW, I don’t think a lot of the people publishing p=reject understood the 
implications of that, either. This is not significantly more arcane.


Then I think we agree.  There's no difference from p=reject and 
p=reject-I-really-mean it.


... If the recipient domain accepts modifications by zero-reputation 
intermediaries (because there are so many of them, after all)


I wouldn't call that a reasonable implementation of ARC.  The set of hosts 
that are likely to send you mail with interesting ARC chains is relatively 
small, and I don't think it changes very fast.  Most of the hosts that 
send you non-spam mail aren't going to send you mail that needs ARC.


If you're setting up a new mailing list host or forwarder, getting 
yourself into whatever whitelists people use will be somewhat painful but 
there's nothing new about that.


I’d be interested in other opinions on this. Or whether this is a fundamental 
problem with ARC.


I'd certainly be interested in hearing how people plan to compile and 
maintain their lists of ARC-worthy hosts.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Jim Fenton]

On 5 Dec 2020, at 18:22, John R Levine wrote:

If a domain publishes p=reject, they’re requesting particular 
handling of a message they originate. ARC modifies that, which is 
good for mailing lists and similar intermediaries, but depends on a 
list of trusted intermediaries that is not under the control of the 
originating domain. That increases the attack surface for DMARC 
considerably.


Not if the recipients use ARC reasonably, e.g., only on mail from 
hosts with a history of not sending botware, use it to see whether a 
message was originally aligned.  Anyone who misuses ARC is going to 
have worse spam leakage than anyone can fix for them.


“Use ARC reasonably” then seems to depend on whether the recipient 
has a good reputation system for evaluating the trustworthiness of 
message modifiers. There isn’t a good track record in creating and 
deploying such reputation systems, as you well know. In this case 
specifically, there is the question of what happens when a domain user 
subscribes to a mailing list, or has their mail forwarded with 
modification, from a new intermediary.


The question I have is: Should DMARC have a policy (or policy 
modifier) that says, “Do not accept modifications to this 
message?” In other words, that the originator values the integrity 
of their messages over deliverability.


Of course not.  That's just the tiny gorillas stamping their teensy 
feet. Why would anyone expect that the people publishing that flag 
actually understood what it meant?  Many will just turn it on because 
someone said it's "more secure."


FWIW, I don’t think a lot of the people publishing p=reject understood 
the implications of that, either. This is not significantly more arcane.


A lot of this boils down to what if some entity sends signed valid 
DMARC aligned mail but somehow doesn't mean it, e.g., an internal 
policy says no mailing lists but their users participate in lists 
anyway.  If they can't control their own mail system, it is not anyone 
else's job to do it for them.


It isn’t a question of controlling their own mail system. One of the 
value propositions of DMARC is effectiveness against phishing. Suppose a 
phishing attacker composed a message purporting to be from someone the 
victim trusts (including a DKIM signature that doesn’t verify because 
the message has supposedly been modified), and then makes it look like 
it has been forwarded by a throw-away intermediary they control and adds 
valid ARC header fields signed by the supposed intermediary. If the 
recipient domain accepts modifications by zero-reputation intermediaries 
(because there are so many of them, after all), DMARC policy is ignored 
and the message is delivered normally. The premise of DMARC is that the 
originating domain has an interest in expressing how messages purporting 
to come from their domain should be handled, and this attack uses ARC to 
override that.


I’d be interested in other opinions on this. Or whether this is a 
fundamental problem with ARC.


-Jim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Hector Santos]

On 12/5/2020 5:07 PM, Michael Thomas wrote:


On 12/5/20 2:02 PM, John Levine wrote:

OK, ARC doesn't do that. This does not mean that ARC is broken, only
that you appear to have different policy priorities than other people.
As you know, DMARC has never obliged recipients to follow senders'
policies so this is nothing new.


If ARC is advocating for a bypass of p=reject that introduces a new
state. If my policy is reject, I want you to reject the mail. If I
want you to reject the mail unless you think it has come from an
acceptable place with receipts, then you need a new policy tag like
reject-except-valid-arc.


I have long suggested one way to resolve this is by using a new DMARC 
extended "arc=" switch.  Allow the author domain define what is 
acceptable from an ARC standpoint, if interested.


arc=N   where N is the arc seal count, whatever amount is allow to 
"promote" a failed DKIM to a pass.  The inherent default arc=0 would 
suggest arc should not be a consideration DKIM fails.


In principle, I am for using DMARC extended switches to outline the 
different protocol behaviors.


arc=1  DMARC Receiver MAY consider using arc for failure promotion

atps=1  DMARC MAY consider using RFC6541

rewrite=0 Mailing List SHOULD NOT rewrite 5322.From

Keep it simple folks.

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] is DMARC informational?

[Jim Fenton]

On 4 Dec 2020, at 15:00, Kurt Andersen (b) wrote:


The entire point of this working group (and the bis version that is in
progress) is to move DMARC into the fully-recognized "standards" 
track.
Note that even the current email specs are not "standards" in IETF 
parlance
(there's another WG addressing that). It's mostly organizational 
semantic

slicing-and-dicing.


The current email specs (specifically RFC 5321 and 5322) are Draft 
Standard, which is part of Standards Track. There is an enormous 
difference between Informational and Standards Track in terms of the 
amount of vetting and consensus required for approval. From RFC 2026:


An "Informational" specification is published for the general 
information of the Internet community, and does not represent an 
Internet community consensus or recommendation.


-Jim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/5/20 6:22 PM, John R Levine wrote:



A lot of this boils down to what if some entity sends signed valid 
DMARC aligned mail but somehow doesn't mean it, e.g., an internal 
policy says no mailing lists but their users participate in lists 
anyway.  If they can't control their own mail system, it is not anyone 
else's job to do it for them.


PS: if IETF must assume that people cannot understand our standards and 
their intent, then we might as well shut down. if they cannot understand 
our intent, that is squarely on us, not them. This sort of cynicism is 
poisonous.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/5/20 6:22 PM, John R Levine wrote:
The question I have is: Should DMARC have a policy (or policy 
modifier) that says, “Do not accept modifications to this message?” 
In other words, that the originator values the integrity of their 
messages over deliverability.


Of course not.  That's just the tiny gorillas stamping their teensy 
feet. Why would anyone expect that the people publishing that flag 
actually understood what it meant?  Many will just turn it on because 
someone said it's "more secure."
Financial institutions are "tiny gorillas"? Who knew? The federal 
government is "tiny gorillas"? What is the metric here?


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[John R Levine]

If a domain publishes p=reject, they’re requesting particular handling of a 
message they originate. ARC modifies that, which is good for mailing lists 
and similar intermediaries, but depends on a list of trusted intermediaries 
that is not under the control of the originating domain. That increases the 
attack surface for DMARC considerably.


Not if the recipients use ARC reasonably, e.g., only on mail from hosts 
with a history of not sending botware, use it to see whether a message was 
originally aligned.  Anyone who misuses ARC is going to have worse spam 
leakage than anyone can fix for them.


The question I have is: Should DMARC have a policy (or policy modifier) that 
says, “Do not accept modifications to this message?” In other words, that the 
originator values the integrity of their messages over deliverability.


Of course not.  That's just the tiny gorillas stamping their teensy feet. 
Why would anyone expect that the people publishing that flag actually 
understood what it meant?  Many will just turn it on because someone said 
it's "more secure."


A lot of this boils down to what if some entity sends signed valid DMARC 
aligned mail but somehow doesn't mean it, e.g., an internal policy says no 
mailing lists but their users participate in lists anyway.  If they can't 
control their own mail system, it is not anyone else's job to do it for 
them.


R's,
John___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Jim Fenton]

On 5 Dec 2020, at 13:03, John Levine wrote:


In article <4f2d2e0e-c773-95df-0958-12344e963...@mtcc.com> you write:


As I understand ARC, it is means of transporting the original 
auth-res

to the destination in case the origin signature is broken by an
intermediary. From there the destination can decide one way or the 
other

to override the DMARC policy of, say, reject.


Right.


There are, however, use
cases where that is exactly wrong and in no case does the originating
domain want such an override to happen. Consider my bank sending me
transactional email. If somehow somebody managed to get that mail
through a mailing list and arc-resigned it, my bank does *not* want 
that

mail to be delivered regardless of the reputation of the mailing list
because something weird and wrong is happening on its face.


If you get a message from a bank via a trustworthy mailing list with a
valid ARC chain that starts with a DMARC pass, that means someone at
the bank really did send the message to the list. I don't think it's
our job to try to guess whether the bank's users are following some
internal policy we can't see.


I’d like to step back from the specific use case of “a bank”.

If a domain publishes p=reject, they’re requesting particular handling 
of a message they originate. ARC modifies that, which is good for 
mailing lists and similar intermediaries, but depends on a list of 
trusted intermediaries that is not under the control of the originating 
domain. That increases the attack surface for DMARC considerably.


The question I have is: Should DMARC have a policy (or policy modifier) 
that says, “Do not accept modifications to this message?” In other 
words, that the originator values the integrity of their messages over 
deliverability.


-Jim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/5/20 5:47 PM, John Levine wrote:

In article  you write:

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.

Thanks. Lest anyone think this is a new issue, see this message I sent
to the DKIM list in 2006, fourteen years ago:

https://mailarchive.ietf.org/arch/msg/ietf-dkim/CBsHbUVtM512vgiwljiA6dtVJ1Q/#

I reprised it six years ago in 2014:

https://mailarchive.ietf.org/arch/msg/ietf/ngPmSfa0b_B5Q72G1JwzGG2IYKY/


because a domain owner might want an unreasonable thing doesn't imply 
that a domain owner can't want a reasonable thing. this is a logical 
fallacy designed to dismiss any request as unreasonable.



Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[John Levine]

In article  you write:
>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.

Thanks. Lest anyone think this is a new issue, see this message I sent
to the DKIM list in 2006, fourteen years ago:

https://mailarchive.ietf.org/arch/msg/ietf-dkim/CBsHbUVtM512vgiwljiA6dtVJ1Q/#

I reprised it six years ago in 2014:

https://mailarchive.ietf.org/arch/msg/ietf/ngPmSfa0b_B5Q72G1JwzGG2IYKY/

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

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 > 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

Re: [dmarc-ietf] ARC vs reject

[Douglas Foster]

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  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
> dmarc@ietf.org
> http

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Dave Crocker]

On 12/5/2020 3:37 PM, Michael Thomas wrote:

On 12/5/20 3:24 PM, Dave Crocker wrote:

On 12/5/2020 3:15 PM, Michael Thomas wrote:
Can you keep your contempt for me off this list? This is not even 
responsive to what I wrote, and is nothing more than an ad hominem.


Wow. It wasn't an ad hominem.
"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.


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.



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.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/5/20 3:49 PM, Tim Wicinski wrote:

Michael

I don't see john's comments as ad hominem.  He's describing how his 
mail system interprets mail flow.


But I do think a lot of this discussion is getting into very 
esoteric cases.
I'd suggest trying to put your thoughts into a draft we can sit and 
chew on.


Wow, you don't see the last line as questioning my intelligence? The two 
of them have been tag teaming me to get me thrown off of here since I 
returned just like they did on the DKIM list which I finally left 
because it wasn't worth their nastiness. I'll probably do the same here 
since the chairs seem to not care about their continuing hostility, but 
I will always have the fact that myself and two others created and wrote 
DKIM well before IETF came into the picture and the politics and credit 
seeking personalities it brings.


Mike




Tim


On Sat, Dec 5, 2020 at 6:16 PM Michael Thomas > wrote:



On 12/5/20 3:10 PM, John Levine wrote:
> In article mailto:dd59f2f3-b17e-6c2b-f756-7dcad2702...@mtcc.com>> you write:
>> If ARC is advocating for a bypass of p=reject that introduces a new
>> state. If my policy is reject, I want you to reject the mail.
If I want
>> you to reject the mail unless you think it has come from an
acceptable
>> place with receipts, then you need a new policy tag like
>> reject-except-valid-arc.
> Other people will have to speak for themselves but on my system
>
> a) I don't believe you.
>
> 2) I don't care.
>
> I think you will find this reaction pretty common.
>
> I see lots of mail going through my system like the stuff I
described
> for the town clerk. It is obvious who it is intended for, the
only way
> to deliver it to that recipient is to forward it, and if the DMARC
> policy says not to do that, the policy is wrong. I don't even
need ARC
> for that, although ARC can be useful for mail that takes indirect
> routes for the mailing lists they subscribe to.
>
> You can say, no I am smarter than those guys and I REALLY REALLY
mean
> it, but see 2) above.
>

Can you keep your contempt for me off this list? This is not even
responsive to what I wrote, and is nothing more than an ad hominem.

And  your anecdotal evidence drawn from a tiny system is very suspect.

Mike

___
dmarc mailing list
dmarc@ietf.org 
https://www.ietf.org/mailman/listinfo/dmarc


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Tim Wicinski]

Michael

I don't see john's comments as ad hominem.  He's describing how his mail
system interprets mail flow.

But I do think a lot of this discussion is getting into very
esoteric cases.
I'd suggest trying to put your thoughts into a draft we can sit and chew on.

Tim


On Sat, Dec 5, 2020 at 6:16 PM Michael Thomas  wrote:

>
> On 12/5/20 3:10 PM, John Levine wrote:
> > In article  you write:
> >> If ARC is advocating for a bypass of p=reject that introduces a new
> >> state. If my policy is reject, I want you to reject the mail. If I want
> >> you to reject the mail unless you think it has come from an acceptable
> >> place with receipts, then you need a new policy tag like
> >> reject-except-valid-arc.
> > Other people will have to speak for themselves but on my system
> >
> > a) I don't believe you.
> >
> > 2) I don't care.
> >
> > I think you will find this reaction pretty common.
> >
> > I see lots of mail going through my system like the stuff I described
> > for the town clerk. It is obvious who it is intended for, the only way
> > to deliver it to that recipient is to forward it, and if the DMARC
> > policy says not to do that, the policy is wrong. I don't even need ARC
> > for that, although ARC can be useful for mail that takes indirect
> > routes for the mailing lists they subscribe to.
> >
> > You can say, no I am smarter than those guys and I REALLY REALLY mean
> > it, but see 2) above.
> >
>
> Can you keep your contempt for me off this list? This is not even
> responsive to what I wrote, and is nothing more than an ad hominem.
>
> And  your anecdotal evidence drawn from a tiny system is very suspect.
>
> Mike
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/5/20 3:24 PM, Dave Crocker wrote:

On 12/5/2020 3:15 PM, Michael Thomas wrote:
Can you keep your contempt for me off this list? This is not even 
responsive to what I wrote, and is nothing more than an ad hominem.



Wow. It wasn't an ad hominem.


"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.




There is a fundamental flaw in the publisher of a dmarc record 
thinking they have any rights or expectations about how a receiver 
will choose to handle a dmarc failure.  It's fine for the publisher to 
offer their own assessment of what the failure means to them.  It is 
not fine for the publisher to pretend to tell the receiver what to do 
about it.


Even having a publisher's assessment be cast as 'advice' sets up the 
false expectation that the receiver should believe and care about that 
assessment.  Some might.  Others don't.  Talking about a receiver 
'overriding' DMARC policy exemplifies this false and inappropriate 
expectation.


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.


Mike


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Dave Crocker]

On 12/5/2020 3:15 PM, Michael Thomas wrote:
Can you keep your contempt for me off this list? This is not even 
responsive to what I wrote, and is nothing more than an ad hominem.



Wow. It wasn't an ad hominem.  His response followed the exact form that 
was established in your note, in the way the requirement/expectation was 
specified. If you didn't want that form used, don't use it.


In any event...

There is a fundamental flaw in the publisher of a dmarc record thinking 
they have any rights or expectations about how a receiver will choose to 
handle a dmarc failure.  It's fine for the publisher to offer their own 
assessment of what the failure means to them.  It is not fine for the 
publisher to pretend to tell the receiver what to do about it.


Even having a publisher's assessment be cast as 'advice' sets up the 
false expectation that the receiver should believe and care about that 
assessment.  Some might.  Others don't.  Talking about a receiver 
'overriding' DMARC policy exemplifies this false and inappropriate 
expectation.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/5/20 3:10 PM, John Levine wrote:

In article  you write:

If ARC is advocating for a bypass of p=reject that introduces a new
state. If my policy is reject, I want you to reject the mail. If I want
you to reject the mail unless you think it has come from an acceptable
place with receipts, then you need a new policy tag like
reject-except-valid-arc.

Other people will have to speak for themselves but on my system

a) I don't believe you.

2) I don't care.

I think you will find this reaction pretty common.

I see lots of mail going through my system like the stuff I described
for the town clerk. It is obvious who it is intended for, the only way
to deliver it to that recipient is to forward it, and if the DMARC
policy says not to do that, the policy is wrong. I don't even need ARC
for that, although ARC can be useful for mail that takes indirect
routes for the mailing lists they subscribe to.

You can say, no I am smarter than those guys and I REALLY REALLY mean
it, but see 2) above.



Can you keep your contempt for me off this list? This is not even 
responsive to what I wrote, and is nothing more than an ad hominem.


And  your anecdotal evidence drawn from a tiny system is very suspect.

Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[John Levine]

In article  you write:
>If ARC is advocating for a bypass of p=reject that introduces a new 
>state. If my policy is reject, I want you to reject the mail. If I want 
>you to reject the mail unless you think it has come from an acceptable 
>place with receipts, then you need a new policy tag like 
>reject-except-valid-arc.

Other people will have to speak for themselves but on my system

a) I don't believe you.

2) I don't care.

I think you will find this reaction pretty common.

I see lots of mail going through my system like the stuff I described
for the town clerk. It is obvious who it is intended for, the only way
to deliver it to that recipient is to forward it, and if the DMARC
policy says not to do that, the policy is wrong. I don't even need ARC
for that, although ARC can be useful for mail that takes indirect
routes for the mailing lists they subscribe to.

You can say, no I am smarter than those guys and I REALLY REALLY mean
it, but see 2) above.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/5/20 2:02 PM, John Levine wrote:

In article  you write:

our job to try to guess whether the bank's users are following some
internal policy we can't see.

There is no guarantee of that. If my bank says reject that mail, I want
my provider to reject that mail, period. No amount of ARC shenanigans
should change that policy.

OK, ARC doesn't do that. This does not mean that ARC is broken, only
that you appear to have different policy priorities than other people.
As you know, DMARC has never obliged recipients to follow senders'
policies so this is nothing new.


If ARC is advocating for a bypass of p=reject that introduces a new 
state. If my policy is reject, I want you to reject the mail. If I want 
you to reject the mail unless you think it has come from an acceptable 
place with receipts, then you need a new policy tag like 
reject-except-valid-arc.


Mike


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[John Levine]

In article  you write:
>> our job to try to guess whether the bank's users are following some
>> internal policy we can't see.
>
>There is no guarantee of that. If my bank says reject that mail, I want 
>my provider to reject that mail, period. No amount of ARC shenanigans 
>should change that policy.

OK, ARC doesn't do that. This does not mean that ARC is broken, only
that you appear to have different policy priorities than other people.
As you know, DMARC has never obliged recipients to follow senders'
policies so this is nothing new.

My system does a lot of forwards of SPF-only p=reject mail to
addresses that belong to individuals, e.g. cl...@mytown.ny.us to the
town clerk's gmail account. No matter how loudly someone might shout
that I should never ever forward that mail, I will ignore them,
because their policy is in this case silly. We have seen that senders
often publish policies that have silly effects and I see no reason to
pay them more attention than they deserve.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[Michael Thomas]

On 12/5/20 1:03 PM, John Levine wrote:

There are, however, use

cases where that is exactly wrong and in no case does the originating
domain want such an override to happen. Consider my bank sending me
transactional email. If somehow somebody managed to get that mail
through a mailing list and arc-resigned it, my bank does *not* want that
mail to be delivered regardless of the reputation of the mailing list
because something weird and wrong is happening on its face.
  
If you get a message from a bank via a trustworthy mailing list with a

valid ARC chain that starts with a DMARC pass, that means someone at
the bank really did send the message to the list. I don't think it's
our job to try to guess whether the bank's users are following some
internal policy we can't see.


There is no guarantee of that. If my bank says reject that mail, I want 
my provider to reject that mail, period. No amount of ARC shenanigans 
should change that policy.




In practice, I can tell you that many organizations publish p=reject
because it is "more secure" and have no clue about mailing lists, so
it's a feature that ARC lets their users participate in mailing lists
without totally ignoring their DMARC policy.


I'm not talking about misconfigured mail systems. I'm talking about a 
policy state that is not in the current set of p values.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[John Levine]

In article  you write:
>>> Got it.  However, the spec says it's a list of addresses to which aggregate 
>>> feedback is to be sent.  When there are multiple entries, up to now, 
>>> reports 
>>> are sent to each. ...

>The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom 
>used in email addresses and
>ubiquitous in https URIs.  We could convene that when a mailto is to be 
>considered as an alternative ...

If we want to do something like that, I would overload the existing
!size hack. For example, add an "f" for finished flag and say that the
URIs are conceptually processed from left to right and if you send
your report to one with a !f (or !10mf or the like) flag, you can stop.

Still not convinced this is useful but it is slightly more backward
compatible.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Michael Thomas]

On 12/5/20 12:56 PM, John Levine wrote:


2) Last week someone was complaining about the expense of the
signatures in ARC seals, now multiple signatures don't hurt anything.
While I agree with the latter sentiment, what changed?

It means that you can't control somebody else's infrastructure. We can 
control whether standards are created carefully and thoughtfully.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC vs reject

[John Levine]

In article <4f2d2e0e-c773-95df-0958-12344e963...@mtcc.com> you write:
>
>As I understand ARC, it is means of transporting the original auth-res 
>to the destination in case the origin signature is broken by an 
>intermediary. From there the destination can decide one way or the other 
>to override the DMARC policy of, say, reject. 

Right.

>There are, however, use 
>cases where that is exactly wrong and in no case does the originating 
>domain want such an override to happen. Consider my bank sending me 
>transactional email. If somehow somebody managed to get that mail 
>through a mailing list and arc-resigned it, my bank does *not* want that 
>mail to be delivered regardless of the reputation of the mailing list 
>because something weird and wrong is happening on its face.
 
If you get a message from a bank via a trustworthy mailing list with a
valid ARC chain that starts with a DMARC pass, that means someone at
the bank really did send the message to the list. I don't think it's
our job to try to guess whether the bank's users are following some
internal policy we can't see.

In practice, I can tell you that many organizations publish p=reject
because it is "more secure" and have no clue about mailing lists, so
it's a feature that ARC lets their users participate in mailing lists
without totally ignoring their DMARC policy. 

Ditto organizations that publish p=reject and only have SPF, no DKIM,
so all of their mail fails when it's forwarded. I can tell you this
latter situation happens a lot, particularly in US government
organiations where DMARC is just another checklist item.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[John Levine]

In article  you write:
>> I dunno how special that case is, but there are lots of cases where mail 
>> passes
>> through multiple layers of ARC signing mutations.
>>
>> I routinely get mail from Microsoft's farm with an ARC seal or two
>> that has never been near a mailing list. Any time a MS user sends a
>> message to one of my lists, it'll emerge with at least two ARC
>> signatures.
>
>Getting multiple signatures from the originating domain doesn't hurt 
>anything. It's a little wasteful, but that's it.

a) The point of ARC seals is that the cv=pass in seal N tells you that
the signature in seal N-1 was good when the message arrived, so you
can do your filtering based on the state of the message each time it
was modified. DKIM doesn't do that.

2) Last week someone was complaining about the expense of the
signatures in ARC seals, now multiple signatures don't hurt anything.
While I agree with the latter sentiment, what changed?

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] ARC vs reject

[Michael Thomas]

As I understand ARC, it is means of transporting the original auth-res 
to the destination in case the origin signature is broken by an 
intermediary. From there the destination can decide one way or the other 
to override the DMARC policy of, say, reject. There are, however, use 
cases where that is exactly wrong and in no case does the originating 
domain want such an override to happen. Consider my bank sending me 
transactional email. If somehow somebody managed to get that mail 
through a mailing list and arc-resigned it, my bank does *not* want that 
mail to be delivered regardless of the reputation of the mailing list 
because something weird and wrong is happening on its face.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Michael Thomas]

On 12/5/20 10:29 AM, John Levine wrote:

In article  
you write:

mailing list to mailing list mail is very common in GSuite, but maybe we're
a special case.

I dunno how special that case is, but there are lots of cases where mail passes
through multiple layers of ARC signing mutations.

I routinely get mail from Microsoft's farm with an ARC seal or two
that has never been near a mailing list. Any time a MS user sends a
message to one of my lists, it'll emerge with at least two ARC
signatures.


Getting multiple signatures from the originating domain doesn't hurt 
anything. It's a little wasteful, but that's it.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76)

[John Levine]

In article 

 you write:
>Hello,
>
>There's currently a ticket that suggests that the requirement for external 
>validation be removed.  Today, if
>example.com has an RUA that points at example.net, the latter must create a 
>record as such:
>
>example.com._report._dmarc.example.net TXT "v=DMARC1"

Whether or not the mailbombing problem is a practical problem,
everyone has already implemented this check so I do not see what
problem we would solve by getting rid of it. It's not like the
test is expensive or publishing the record is hard.

I think it may somewhat mitigate hammering on third parties when
someone misspells its rua= target.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[John Levine]

In article  
you write:
>mailing list to mailing list mail is very common in GSuite, but maybe we're
>a special case. 

I dunno how special that case is, but there are lots of cases where mail passes
through multiple layers of ARC signing mutations.

I routinely get mail from Microsoft's farm with an ARC seal or two
that has never been near a mailing list. Any time a MS user sends a
message to one of my lists, it'll emerge with at least two ARC
signatures.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[John R Levine]

My intention is that if you send the report by https, you're done.



The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom 
used in email addresses and ubiquitous in https URIs.  We could convene that when a 
mailto is to be considered as an alternative to an https, then the former should precede 
the latter, separated by a slash.  For example:
v=DMARC1; p=none; rua=mailto:lo...@example.com, 
mailto:report@service.example/https://service.example/report/;


Ugh.  Given what other people have said it sounds like it would be more 
useful to keep the current rules that you try to deliver the report 
everywhere.  That preseves the ability to send it both to your local 
address and to someone like Dmarcian, even if Dmacian also supports https.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76)

[Brotman, Alex]

Hello,

There's currently a ticket that suggests that the requirement for external 
validation be removed.  Today, if example.com has an RUA that points at 
example.net, the latter must create a record as such:

example.com._report._dmarc.example.net TXT "v=DMARC1"

The original thought was that a bad actor could overwhelm a target with 
unrequested reports.  It seems in reality, most report generators only send 
once per day.  Additionally, there appear to be some generators who ignore the 
absence of these records.

https://tools.ietf.org/html/rfc7489#section-7.1

We'd like to have discussion wrapped up in about two weeks or so.  Again, thank 
you for your participation.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

On Fri 04/Dec/2020 23:45:47 +0100 Brandon Long wrote:

On Wed, Dec 2, 2020 at 3:11 AM Alessandro Vesely  wrote:

On Wed 02/Dec/2020 03:14:46 +0100 Brandon Long wrote:

On Tue, Dec 1, 2020 at 2:37 AM Alessandro Vesely  wrote:

On Tue 01/Dec/2020 05:56:46 +0100 Brandon Long wrote:

On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely  wrote:

On 25/11/2020 20:16, Michael Thomas wrote:

On 11/25/20 11:11 AM, Alessandro Vesely wrote:

On 25/11/2020 19:24, Jesse Thompson wrote:

On 11/25/20 11:30 AM, Alessandro Vesely wrote:

Without resorting to ARC, it is still possible to validate
author domain's signatures directly if the MLM just adds a
subject tag and a footer >

I agree that ARC isn't really needed to do this (trust the
last hop from the MLM and determine the original
authenticity from the MLM's perspective) 

I didn't mean to trust the MLM.  I meant remove the subject
tag and the footer, then the original DKIM signature verifies.
See:
https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ >>>

When I was at Cisco, with l= and some subject line heuristics I
could get probably like 90+% verification rate across the entire
company, a company that uses external mailing lists a lot.
Definitely not 100% though. >>

DKIM itself is not 100%.  You always have lines beginning with
"From " or occasional autoconversions. >>
l= doesn't cover multipart/alternative nor
Content-Transfer-Encoding: base64. In addition, the DKIM spec
discourages its usage and suggests that "Assessors might wish to
ignore signatures that use the tag." >

Right, some of the other dkim-light or diff concepts we discussed
would be better than using l= >
We again got hung up on the 100% solution, though... something that
handled subject-prefix and footer in a transport agnostic way might
have worked. 

I'm not clear about the meaning of "100%".  If an author domain puts
no DKIM signatures, there is no way to verify them.  Hence, some
compliance of the author domain has to be required. 
The same holds for conditional signatures.

The same holds for MLM transformations.


Yes, by 100% I meant of messages that were already authenticated and
therefore should continue to be authenticated through the relay. >>

That's ARC.  If a message lacks DKIM and was SPF-authenticated, there's
no way it can continue to be authenticated through a relay. >>
OTOH, mailing lists and relays are two different beasts.  For one thing,
it is very unusual for a mailing list to send to another mailing list.
Thus, we can safely specify a non-stackable authentication method. >
mailing list to mailing list mail is very common in GSuite, but maybe we're 
a special case.  Part of that was that aliases were moved to the mailing 
list infra (which is definitely more of an "our problem" than everyone), but 
we also see common usage where companies make groups matching their 
hierarchy (the all company group goes to all department groups which go to 
all local groups etc).  We also see some where announce groups mix contrib 
groups, etc.  Especially since we also use the same groups as ACL groups for 
GSuite and Google Cloud, so hierarchical groups are very common.


I'm not familiar with that feature.  How does a list get subscribed to another 
list?


In general, a list accepts messages from subscribed users, so if dmarc-ietf 
distributed this message to another list which I'm not a subscriber of, it 
would not pass.  (From: rewriting changes that behavior.  For example, one 
could subscribe to a list which routinely rewrites From: on behalf of this 
list, dmarc-ietf.  If the former list traffic is very high, that subscribing 
could be a sort of DoS attack to us.)



(there was a recent common where someone said who needs an org chart when 
we have email, showing the list of footers for all of the org level mailing 
lists the message went to to get to them)


The mlm-transform draft (referenced above) limits footers to 10 lines of text, 
each shorter than 80 characters.  If the hierarchy is not deeper than 10,  the 
chart can fit within a single footer.  Note that every added line breaks all 
previous signatures.  However, only the author domain's signature is worth 
being recovered, as far as MLM transformations are concerned.  ARC can still 
certify the whole chain.


The 10 lines limit is arbitrary.  It is meant to avoid that recipients mistake 
the footer for the main part of the message.



(one construction of hierarchical announce lists that was not well 
considered did result in every person on the combined list getting 9000 
copies of messages to the list, so flattening lists is sometimes much 
preferred) >
Which isn't to say we couldn't work around it or do the work to flatten the 
lists, though it increases the complexity of the product (can you 
unsubscribe from the top level list but not a sub list?)


I guess some coordination among sublists is required anyway.

To recognize that a message arrives from a sublis

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Alessandro Vesely]

On Fri 04/Dec/2020 19:21:33 +0100 John R Levine wrote:
>>> I meant "at the same time" as in during the same reporting run.  As Dave 
>>> noted, if you sent any particular report by https, there's no need to send 
>>> it again by mail.
>>
>> Got it.  However, the spec says it's a list of addresses to which aggregate 
>> feedback is to be sent.  When there are multiple entries, up to now, reports 
>> are sent to each.
> 
> Hm, we might want to revisit that.  If a domain wants mail sent to three 
> places, it's not like it's hard to arrange for forwarding.  My intention is 
> that if you send the report by https, you're done.


The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom 
used in email addresses and ubiquitous in https URIs.  We could convene that 
when a mailto is to be considered as an alternative to an https, then the 
former should precede the latter, separated by a slash.  For example:

v=DMARC1; p=none; rua=mailto:lo...@example.com, 
mailto:report@service.example/https://service.example/report/;


Best
Ale
-- 


















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc