Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Neil Anuskiewicz]

> On Apr 14, 2023, at 7:43 PM, Mark Alley 
>  wrote:
> 
> 
> Its not ideal, but I could live with that. That's somewhat less ambiguous 
> than [general purpose] domains, but still ambiguous; the Appendix or the same 
> section could easily clarify "unrestrictive usage policies",  and then maybe 
> the appendix, as you say, could cover the known issues and workarounds. 
> 
> If I'm being honest, given the different versions put forth so far, it seems 
> like this type of language is closer to the compromise on the 
> interoperability statement. The other versions say relatively the same thing. 
> 
> - Mark Alley

I think what Mark’s saying isn’t perfect for but I think it can get the rough 
consensus we’re seeking. That’s my humble opinion.

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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Neil Anuskiewicz]

> On Apr 15, 2023, at 4:21 PM, Scott Kitterman  wrote:
> 
> 
> 
>> On April 15, 2023 10:58:06 PM UTC, Neil Anuskiewicz 
>>  wrote:
>> 
>> 
 On Apr 14, 2023, at 8:26 PM, Scott Kitterman  wrote:
>>> 
>>> Perfect.  The goal is working towards consensus is to find something we 
>>> can 
>>> live with, so that's exactly what I was hoping for.  I don't think it's 
>>> ideal 
>>> either, but I can live with it.
>>> 
>>> Scott K
>> 
>> Yes sir, that’s it. However, I’d like to see less of some narratives in the 
>> discussion especially around costs and benefits. It’s not you, Scott, but 
>> your post seems apropos.
>> 
>> 1. Cousin domains. We all get that dmarc doesn’t touch those. Dmarc is to 
>> stop spoofing of exact domains. There are other technologies and methods 
>> whose responsibility it is to track down and take down fraudsters.
>> 
>> 2. I would like to know if general purpose domain == org domain in most 
>> cases. Someone suggested the registration of a separate domain for general 
>> purposes. That sounds reasonable as long as the advice is clear that this 
>> isn’t advocating cousin domains.
>> 
>> 3. Dmarc should be made to work is as well as possibility to prevent exact 
>> domain spoofing. I’ve seen spoofing of org domains of companies that you 
>> wouldn’t think of as a high priority impact. It can cause catastrophic 
>> consequences to the organization so spoofed. I don’t have to say more here 
>> as presumably everyone here knows. If you don’t I think it’s critical to 
>> understand that. If you can’t feel it emotionally then you’ve not explored 
>> the consequences of spoofing.
>> 
>> So I humbly request a practice of steal manning and dispense with the straw 
>> men and especially the red herrings.
>> 
> What color herrings would you prefer?
> 
> I really have no idea what that last paragraph means.
> 
> If we can stick to trying to get some consensus on the MUSTard in the main 
> part of the document, I think we can (and should) address details in the 
> appendix the proposed language suggests we point to.
> 
> Dude, I have literally worked on email authentication for 20 years.  Do you 
> think I did that without understanding it's a problem?
> 

Scott, I said it wasn’t your posts that had those problems. See above. I 
responded to you with this as I see you as the person who is going to actually 
write the compromise text in the actual document. I meant no disrespect, Scott. 
I know who you are from SPF fame on.

I was just seeing arguments that not much benefit has been seen from enforcing 
policies not to mention cousin domains and so on. I get the feeling that 
position is from someone who’s never witnessed the consequences of malicious 
spoofing.

So I apologize, Scott, I neglected to explain my concerns.

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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Scott Kitterman]

On April 15, 2023 10:58:06 PM UTC, Neil Anuskiewicz 
 wrote:
>
>
>> On Apr 14, 2023, at 8:26 PM, Scott Kitterman  wrote:
>> 
>> Perfect.  The goal is working towards consensus is to find something we can 
>> live with, so that's exactly what I was hoping for.  I don't think it's 
>> ideal 
>> either, but I can live with it.
>> 
>> Scott K
>
>Yes sir, that’s it. However, I’d like to see less of some narratives in the 
>discussion especially around costs and benefits. It’s not you, Scott, but your 
>post seems apropos.
>
>1. Cousin domains. We all get that dmarc doesn’t touch those. Dmarc is to stop 
>spoofing of exact domains. There are other technologies and methods whose 
>responsibility it is to track down and take down fraudsters.
>
>2. I would like to know if general purpose domain == org domain in most cases. 
>Someone suggested the registration of a separate domain for general purposes. 
>That sounds reasonable as long as the advice is clear that this isn’t 
>advocating cousin domains.
>
>3. Dmarc should be made to work is as well as possibility to prevent exact 
>domain spoofing. I’ve seen spoofing of org domains of companies that you 
>wouldn’t think of as a high priority impact. It can cause catastrophic 
>consequences to the organization so spoofed. I don’t have to say more here as 
>presumably everyone here knows. If you don’t I think it’s critical to 
>understand that. If you can’t feel it emotionally then you’ve not explored the 
>consequences of spoofing.
>
>So I humbly request a practice of steal manning and dispense with the straw 
>men and especially the red herrings.
>
What color herrings would you prefer?

I really have no idea what that last paragraph means.

If we can stick to trying to get some consensus on the MUSTard in the main part 
of the document, I think we can (and should) address details in the appendix 
the proposed language suggests we point to.

Dude, I have literally worked on email authentication for 20 years.  Do you 
think I did that without understanding it's a problem?

Scott K

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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Neil Anuskiewicz]

> On Apr 14, 2023, at 8:26 PM, Scott Kitterman  wrote:
> 
> Perfect.  The goal is working towards consensus is to find something we can 
> live with, so that's exactly what I was hoping for.  I don't think it's ideal 
> either, but I can live with it.
> 
> Scott K

Yes sir, that’s it. However, I’d like to see less of some narratives in the 
discussion especially around costs and benefits. It’s not you, Scott, but your 
post seems apropos.

1. Cousin domains. We all get that dmarc doesn’t touch those. Dmarc is to stop 
spoofing of exact domains. There are other technologies and methods whose 
responsibility it is to track down and take down fraudsters.

2. I would like to know if general purpose domain == org domain in most cases. 
Someone suggested the registration of a separate domain for general purposes. 
That sounds reasonable as long as the advice is clear that this isn’t 
advocating cousin domains.

3. Dmarc should be made to work is as well as possibility to prevent exact 
domain spoofing. I’ve seen spoofing of org domains of companies that you 
wouldn’t think of as a high priority impact. It can cause catastrophic 
consequences to the organization so spoofed. I don’t have to say more here as 
presumably everyone here knows. If you don’t I think it’s critical to 
understand that. If you can’t feel it emotionally then you’ve not explored the 
consequences of spoofing.

So I humbly request a practice of steal manning and dispense with the straw men 
and especially the red herrings.

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

Re: [dmarc-ietf] Give up on SPF alone

[Hector Santos]

On 4/15/2023 11:27 AM, Douglas Foster wrote:
Sorry Hector, but you are wrong on the theory and off topic.   DMARC 
and SPF authenticate different things.  DMARC is designed to 
override SPF Fail to handle the case of forwarding without SRS, 
which would be optimal if all messages were signed.


SPF is ignorant of DMARC both literally and technically.  DMARC 
depends on SPF and it may never get a chance to be tested.  That's the 
reality.  Sorry.


Bandwidth optimization was an issue when we were on dial-up, but now 
we size capacity to need, and use other defenses for DDoS attacks 
that saturate bandwidth.


Who is we?  Anyhow. Not applicable.

Discarding DMARC is not feasible, because you cannot revoke an RFC 
and you cannot make people stop knowing what they already know


Way over my head.

--
Hector Santos,
https://santronics.com
https://winserver.com



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

Re: [dmarc-ietf] list history, Signaling MLMs

[Wei Chuang]

On Sat, Apr 15, 2023 at 1:40 PM Scott Kitterman 
wrote:

>
>
> On April 15, 2023 8:17:41 PM UTC, John R Levine  wrote:
> >> I'm assuming that the "long list of stinky possible workarounds" are
> the existing "whatever" mitigations, and rewriting seems to be acceptable
> enough as a mitigation to convince large [enterprise] mail systems to move
> forward with restrictive policies. ...
> >
> >I think you are greatly overestimating the connection between cause and
> effect here.  The people setting the policies have no idea what effect they
> have on their users, and to the degree they do, they do not care. IETFers
> at large organizations who support their IETF work, and that have p=reject,
> tell me they've told the IT departments that the policy is making it hard
> for them to get their work done and the response is either "duh?" or "not
> our problem."
> >
> >> I intentionally published > "p=quarantine pct=0" specifically to find
> the MLMs that implemented no mitigations, weighed that against what I knew
> about which receivers enforced non-mitigated mail, and then made a judgment
> call to move forward.
> >
> >It sure would be nice if people at other organizations were as concerned
> about the quality of mail service to their users.  But noo.
> >
> >> I believe Wei suggested that we need to find a better "whatever" (in
> the form of an alternative to SPF and DKIM that works with mailing lists)
> ...
> >
> >I would like a pony, too.  But ARC is as good as we have now and after a
> decade of beating our heads against the wall, I don't think we're going to
> find anything better.  I've suggested a bunch of things that would make
> lists' life better, and nobody is interested:
> >
>
> Agreed.
>
> If someone has a great idea for a third way in email authentication, they
> should develop the idea, get some deployment experience, and then document
> the protocol.  After that would come the question of adding it to DMARC.
> This is not the working group to do that work.
>

Agreed such a proposal shouldn't be worked on in DMARC.  Also agreed that
it's a good idea to get deployment experience.  That said, I think there is
a lot of value in getting early IETF feedback in some other
forum/mailing-list to help review the potential proposals.

-Wei


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


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] list history, Signaling MLMs

[Hector Santos]

On 4/15/2023 4:39 PM, Scott Kitterman wrote:

On April 15, 2023 8:17:41 PM UTC, John R Levine  wrote:
I would like a pony, too. But ARC is as good as we have now and 
after a decade of beating our heads against the wall, I don't think 
we're going to find anything better. I've suggested a bunch of 
things that would make lists' life better, and nobody is interested: 

Agreed.

If someone has a great idea for a third way in email authentication, they 
should develop the idea, get some deployment experience, and then document the 
protocol.  After that would come the question of adding it to DMARC.  This is 
not the working group to do that work.



ARC is overhead junk to reach a more optimized solution with a TPA 
(Third Party Authorization) protocol. Anyone. Pick one.


Maybe we should add an optional new SPF directive

-DMARC:5322.From.domain

To help resolve this problem DMARC discovery issues at SMTP?

ARC is junk.  Why is it IETF perpetuated is beyond me.  Soon we will 
I-D proposals to clean up this massive overhead.


--
HLS

--
Hector Santos,
https://santronics.com
https://winserver.com



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

Re: [dmarc-ietf] list history, Signaling MLMs

[Scott Kitterman]

On April 15, 2023 8:17:41 PM UTC, John R Levine  wrote:
>> I'm assuming that the "long list of stinky possible workarounds" are the 
>> existing "whatever" mitigations, and rewriting seems to be acceptable enough 
>> as a mitigation to convince large [enterprise] mail systems to move forward 
>> with restrictive policies. ...
>
>I think you are greatly overestimating the connection between cause and effect 
>here.  The people setting the policies have no idea what effect they have on 
>their users, and to the degree they do, they do not care. IETFers at large 
>organizations who support their IETF work, and that have p=reject, tell me 
>they've told the IT departments that the policy is making it hard for them to 
>get their work done and the response is either "duh?" or "not our problem."
>
>> I intentionally published > "p=quarantine pct=0" specifically to find the 
>> MLMs that implemented no mitigations, weighed that against what I knew about 
>> which receivers enforced non-mitigated mail, and then made a judgment call 
>> to move forward.
>
>It sure would be nice if people at other organizations were as concerned about 
>the quality of mail service to their users.  But noo.
>
>> I believe Wei suggested that we need to find a better "whatever" (in the 
>> form of an alternative to SPF and DKIM that works with mailing lists) ...
>
>I would like a pony, too.  But ARC is as good as we have now and after a 
>decade of beating our heads against the wall, I don't think we're going to 
>find anything better.  I've suggested a bunch of things that would make lists' 
>life better, and nobody is interested:
>

Agreed.

If someone has a great idea for a third way in email authentication, they 
should develop the idea, get some deployment experience, and then document the 
protocol.  After that would come the question of adding it to DMARC.  This is 
not the working group to do that work.

Scott K

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

Re: [dmarc-ietf] list history, Signaling MLMs

[John R Levine]

I'm assuming that the "long list of stinky possible workarounds" are the 
existing "whatever" mitigations, and rewriting seems to be acceptable 
enough as a mitigation to convince large [enterprise] mail systems to 
move forward with restrictive policies. ...


I think you are greatly overestimating the connection between cause and 
effect here.  The people setting the policies have no idea what effect 
they have on their users, and to the degree they do, they do not care. 
IETFers at large organizations who support their IETF work, and that have 
p=reject, tell me they've told the IT departments that the policy is 
making it hard for them to get their work done and the response is either 
"duh?" or "not our problem."


I intentionally published > "p=quarantine pct=0" specifically to find 
the MLMs that implemented no mitigations, weighed that against what I 
knew about which receivers enforced non-mitigated mail, and then made a 
judgment call to move forward.


It sure would be nice if people at other organizations were as concerned 
about the quality of mail service to their users.  But noo.


I believe Wei suggested that we need to find a better "whatever" (in the 
form of an alternative to SPF and DKIM that works with mailing lists) ...


I would like a pony, too.  But ARC is as good as we have now and after a 
decade of beating our heads against the wall, I don't think we're going to 
find anything better.  I've suggested a bunch of things that would make 
lists' life better, and nobody is interested:


https://datatracker.ietf.org/doc/draft-levine-may-forward/

https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

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] list history, Signaling MLMs

[Jesse Thompson]

On Sat, Apr 15, 2023, at 12:07 PM, John Levine wrote:
> It appears that Jesse Thompson   said:
> >Why not turn off rewriting on this list, as an experiment? The hypothesis is 
> >that everyone will switch to Gmail and not tilt
> >at IETF, but instead they will tilt at their domain owners.
> 
> That's how we got here. A lot of IETF participants use mail systems
> that enforce DMARC policy (notably including Gmail) and we were
> getting a lot of complaints about lost mail, and a lot of work with
> people getting bounced off lists who list managers had to resubscribe.
> Barry says that even with our mitigations, we still have the latter problem.
> 
> We went through a long list of possible workarounds including several
> kinds of rewrites and several kinds of message wrapping. They all
> stauk but the one we picked, per-address rewrites for domains with
> DMARC policies, stunk less. The option we picked requires more control
> over the MTA than typical mailman or sympa installations have, so most
> people's options are worse.
> 
> I still don't understand the point of this argument. We all agree that
> DMARC causes damage to interoperability, but some people appear to be
> saying we should ignore it or pretend it doesn't exist because DMARC
> has other advantages. The honest thing to do is to describe both. 
> 
> Nobody thinks we're going to get Yahoo to turn off p=reject (they said
> at the time they turned it on that they don't care about mailing
> lists) but I think there's some hope we can get large mail systems to
> be more aware of the damage and use ARC or whatever to mitigate it.

I'm assuming that the "long list of stinky possible workarounds" are the 
existing "whatever" mitigations, and rewriting seems to be acceptable enough as 
a mitigation to convince large [enterprise] mail systems to move forward with 
restrictive policies. I intentionally published "p=quarantine pct=0" 
specifically to find the MLMs that implemented no mitigations, weighed that 
against what I knew about which receivers enforced non-mitigated mail, and then 
made a judgement call to move forward.

I believe Wei suggested that we need to find a better "whatever" (in the form 
of an alternative to SPF and DKIM that works with mailing lists) so that every 
domain, even those with members of the general publiic, may gain the benefits 
of DMARC. If an acceptable mitigation/auth-mechanism is established, does that 
mean DMARC will be revised to remove the "MUST NOT p=reject if general 
purpose"? Or is that going to be permanent?

How about this?:
"MUST NOT publish p=reject|quarantine if the domain owner, after examining the 
report data, has no means to mitigate all identified legitimate mail flow that 
which has no authenticated identifier aligned to the RFC5322.from domain. 
Mitigations may include arranging with all affected intermediaries and email 
sending providers to establish an aligned authenticated identifier, require the 
intermediary/ESP to use a different domain when sending this mail flow, or 
devise an alternative authentication mechanism outside the scope of this 
specification but is otherwise agreed upon by all affected parties."

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

Re: [dmarc-ietf] list history, Signaling MLMs

[John Levine]

It appears that Jesse Thompson   said:
>Why not turn off rewriting on this list, as an experiment? The hypothesis is 
>that everyone will switch to Gmail and not tilt
>at IETF, but instead they will tilt at their domain owners.

That's how we got here. A lot of IETF participants use mail systems
that enforce DMARC policy (notably including Gmail) and we were
getting a lot of complaints about lost mail, and a lot of work with
people getting bounced off lists who list managers had to resubscribe.
Barry says that even with our mitigations, we still have the latter problem.

We went through a long list of possible workarounds including several
kinds of rewrites and several kinds of message wrapping. They all
stauk but the one we picked, per-address rewrites for domains with
DMARC policies, stunk less. The option we picked requires more control
over the MTA than typical mailman or sympa installations have, so most
people's options are worse.

I still don't understand the point of this argument. We all agree that
DMARC causes damage to interoperability, but some people appear to be
saying we should ignore it or pretend it doesn't exist because DMARC
has other advantages. The honest thing to do is to describe both. 

Nobody thinks we're going to get Yahoo to turn off p=reject (they said
at the time they turned it on that they don't care about mailing
lists) but I think there's some hope we can get large mail systems to
be more aware of the damage and use ARC or whatever to mitigate it.

R's,
John

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

Re: [dmarc-ietf] Signaling MLMs

[John Levine]

It appears that Scott Kitterman   said:
>
>
>On April 15, 2023 12:26:16 PM UTC, Laura Atkins  
>wrote:
>>On Apr 15, 2023, at 4:25 AM, Scott Kitterman  wrote:
>>It seems to me that there is zero harm in actively documenting the problems 
>>with DMARC and making interoperability
>recommendations about who should and should not be publishing restrictive 
>policies. 
>
>I agree on documenting the issues with DMARC and making recommendations to 
>improve interoperability.  There are issues and
>they're significant, but we shouldn't catastrophize them either.

Right. I don't find arguments persuuasive that we should ignore DMARC
damage because it has other advanrages. Of course it has other
advantages, none of which make the damage any less real.

Document the reality and move on.  If some people don't like the reality, well, 
OK.

R's,
John

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

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

RFC 5321 restrictions on forwarding cease to be applicable when the message
is modified.   Once the MLM changes the message, the ML domain owns it,
which is why the MLM-created message SHOULD use the ML domain on the new
message.

Additionally:
- The recipient may not trust the author domain, for any number of
reasons.   This is overcome when the ML domain takes responsibility for the
message.
- The list visual appearance is easily impersonated, so the list members
can be deceived without the fake message transiting the list at all.   This
is also overcome if list messages use a From in the list domain and protect
it with DMARC.

There is no alchemy that will cause an evaluator to trust the list until
the list takes responsibility for the message by using its own domain in
the From address.

On other active topics:

   - The strategy of providing a p=none domain is not likely to be
   embraced.   Assume that "example.com" uses "p=reject", but "
   insecure.example.com" uses "p=none".Any system admin will understand
   that the organization remains at risk as long as "insecure.example.com"
   is allowed to operate on the corporate backbone.

   - The strategy of rejecting subscriptions from "p=reject" domains has
   not been embraced, and I doubt it will be in the future.   Rejecting
   subscriptions requires disclosures that serve to embarrass the list:.   "Im
   sorry, your subscription cannot be accepted because your domain protects
   your email identity from impersonation, which obstructs our ability to add
   our highly-valued subject tags and footer information to every message.
   Please resubscribe using a domain that allows us to modify your messages
   and allows spammers to use your identity to mislead your family, friends,
   church, employer, community group, medical providers, and municipal
   government."   I don't think lists will ever be willing to do full
   disclosure.




DF

On Sat, Apr 15, 2023 at 12:10 PM Scott Kitterman 
wrote:

> On Saturday, April 15, 2023 11:45:34 AM EDT Alessandro Vesely wrote:
> > On Sat 15/Apr/2023 16:42:32 +0200 Scott Kitterman wrote:
> > > On April 15, 2023 1:55:59 PM UTC, Jesse Thompson 
> wrote:
> > >>And the "If a mailing list would like to provide the best customer
> > >>experience...MUST rewrite" suggestion seems like a reasonable way out
> of
> > >>this "interoperability vs reality" standoff.  How about if I soften it
> up
> > >>further:
> > >>
> > >>"Any sender (mailing list, forwarder, ESP, or otherwise) which is
> tasked
> > >>to send unauthenticated email from an address within a
> > >>p=reject|quarantine domain it MUST refuse to send the message or send
> the
> > >>message using an RFC5322.from address in a different domain.">>
> > > That kind of customer experience guidance isn't what goes in an IETF
> > > protocol specification with normative language.  There can, and
> probably
> > > should be, some discussion about that in an appendix, but without the
> > > MUSTard.
> > >
> > > As I recently mentioned in another thread, the From rewriting trick is
> > > explicitly contrary to MUST NOT language in RFC 5321 on mailing lists.
> > > We should quit pretending it's in scope as a component of DMARCbis and
> > > move on.
> > I hope they amend that passage.  There are several shortcomings in that
> > section.  By the same argument, MLMs shouldn't add List-* header field
> > either.
>
> Perhaps, but I don't think the fact that when RFC 2321 was updated, they
> didn't make explicit provisions for RFC 2919 and perhaps should have,
> gives us
> any wiggle room around the fact that From is the one field in the header
> that
> is specifically called out as not being changed.
>
> Scott K
>
>
> ___
> 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] Signaling MLMs

[Alessandro Vesely]

On Sat 15/Apr/2023 18:10:08 +0200 Scott Kitterman wrote:

On Saturday, April 15, 2023 11:45:34 AM EDT Alessandro Vesely wrote:

On Sat 15/Apr/2023 16:42:32 +0200 Scott Kitterman wrote:

On April 15, 2023 1:55:59 PM UTC, Jesse Thompson  wrote:
And the "If a mailing list would like to provide the best customer 
experience...MUST rewrite" suggestion seems like a reasonable way out of 
this "interoperability vs reality" standoff.  How about if I soften it up 
further:


"Any sender (mailing list, forwarder, ESP, or otherwise) which is tasked 
to send unauthenticated email from an address within a 
p=reject|quarantine domain it MUST refuse to send the message or send the 
message using an RFC5322.from address in a different domain."


That kind of customer experience guidance isn't what goes in an IETF 
protocol specification with normative language.  There can, and probably 
should be, some discussion about that in an appendix, but without the 
MUSTard.


As I recently mentioned in another thread, the From rewriting trick is 
explicitly contrary to MUST NOT language in RFC 5321 on mailing lists. 
We should quit pretending it's in scope as a component of DMARCbis and 
move on.


I hope they amend that passage.  There are several shortcomings in that
section.  By the same argument, MLMs shouldn't add List-* header field
either.


Perhaps, but I don't think the fact that when RFC 2321 was updated, they
didn't make explicit provisions for RFC 2919 and perhaps should have, gives us
any wiggle room around the fact that From is the one field in the header that
is specifically called out as not being changed.



That's right.  Yet, that's what everyone does hitting «forward» on a MUA.  Such 
action is indeed exemplified as what a mediator does not do in RFC 5598, near 
the beginning of Section 5.  We're slightly changing Internet mail architecture.


Best
Ale
--








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

Re: [dmarc-ietf] Signaling MLMs

[Alessandro Vesely]

On Sat 15/Apr/2023 04:57:13 +0200 Murray S. Kucherawy wrote:

On Fri, Apr 14, 2023 at 7:32 PM Jesse Thompson  wrote:

On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:

The Sender's users being denied the ability to participate in a list due 
to its policies seems to me like it puts this customer service problem 
where it belongs.


Let's say, tomorrow, IETF configures this list to reject Todd's mail (as 
well as for every other member with p=reject) and/or disables from 
rewriting. Does Todd's domain owner care? No.


This is where it breaks down for me.

What's the calculus here?  The domain owner decides that protecting its 
name in this one targeted way is so valuable that it's fine with whatever 
negative impact it has downstream?  And we're supposed to be OK with giving 
this sort of approach a blanket green light by not declaring such use of 
DMARC not interoperable?  And we're fine with giving their biz dev, PR, 
legal, and all the other teams you named a pass on dealing with the 
aftermath?  Because as I think you can see, those are not the teams in the 
trenches figuring this out.


Why do you believe that the domain owner and its users shouldn't feel the 
pain for such a decision?  That its customers go someplace else that does 
care about these things?  Or that it has to split its mail flows into 
something general purpose and something transactional in the name of 
continued interoperability?



MLM damage is evident.  However, our calling transactional the mail flows that 
don't risk indirect delivery is unreal.  Limiting DMARC to transactional mail 
flows is not a step we can rely upon, as receiver-side forwarding does exist.


MLM traffic is 99.9% indirect (≈0.1% for list masters who participate from the 
list domain).  Chances to run into a forwarded address are much lower, but 
absolutely positive.  So, why don't we say that forwarders MUST NOT break DKIM 
signatures?  Some of them do.  Doesn't that disrupt forwarding just like it 
disrupts MLM?


The transactional vs. general purpose dichotomy relegates us to a protocol that 
/sometimes/ works, which I consider utterly improper.



Best
Ale
--




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

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

On Saturday, April 15, 2023 11:45:34 AM EDT Alessandro Vesely wrote:
> On Sat 15/Apr/2023 16:42:32 +0200 Scott Kitterman wrote:
> > On April 15, 2023 1:55:59 PM UTC, Jesse Thompson  wrote:
> >>And the "If a mailing list would like to provide the best customer
> >>experience...MUST rewrite" suggestion seems like a reasonable way out of
> >>this "interoperability vs reality" standoff.  How about if I soften it up
> >>further:
> >>
> >>"Any sender (mailing list, forwarder, ESP, or otherwise) which is tasked
> >>to send unauthenticated email from an address within a
> >>p=reject|quarantine domain it MUST refuse to send the message or send the
> >>message using an RFC5322.from address in a different domain.">>
> > That kind of customer experience guidance isn't what goes in an IETF
> > protocol specification with normative language.  There can, and probably
> > should be, some discussion about that in an appendix, but without the
> > MUSTard.
> > 
> > As I recently mentioned in another thread, the From rewriting trick is
> > explicitly contrary to MUST NOT language in RFC 5321 on mailing lists. 
> > We should quit pretending it's in scope as a component of DMARCbis and
> > move on.
> I hope they amend that passage.  There are several shortcomings in that
> section.  By the same argument, MLMs shouldn't add List-* header field
> either.

Perhaps, but I don't think the fact that when RFC 2321 was updated, they 
didn't make explicit provisions for RFC 2919 and perhaps should have, gives us 
any wiggle room around the fact that From is the one field in the header that 
is specifically called out as not being changed.

Scott K


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

Re: [dmarc-ietf] Signaling MLMs

[Alessandro Vesely]

On Sat 15/Apr/2023 16:42:32 +0200 Scott Kitterman wrote:

On April 15, 2023 1:55:59 PM UTC, Jesse Thompson  wrote:

And the "If a mailing list would like to provide the best customer experience...MUST rewrite" suggestion seems like a reasonable way out of this "interoperability vs reality" standoff.  How about if I soften it up further: 


"Any sender (mailing list, forwarder, ESP, or otherwise) which is tasked to send 
unauthenticated email from an address within a p=reject|quarantine domain it MUST refuse 
to send the message or send the message using an RFC5322.from address in a different 
domain."



That kind of customer experience guidance isn't what goes in an IETF protocol 
specification with normative language.  There can, and probably should be, some 
discussion about that in an appendix, but without the MUSTard.

As I recently mentioned in another thread, the From rewriting trick is 
explicitly contrary to MUST NOT language in RFC 5321 on mailing lists.  We 
should quit pretending it's in scope as a component of DMARCbis and move on.



I hope they amend that passage.  There are several shortcomings in that 
section.  By the same argument, MLMs shouldn't add List-* header field either.



Best
Ale
--






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

Re: [dmarc-ietf] Give up on SPF alone

[Douglas Foster]

Sorry Hector, but you are wrong on the theory and off topic.   DMARC and
SPF authenticate different things.  DMARC is designed to override SPF Fail
to handle the case of forwarding without SRS, which would be optimal if all
messages were signed.

Bandwidth optimization was an issue when we were on dial-up, but now we
size capacity to need, and use other defenses for DDoS attacks that
saturate bandwidth.

Discarding DMARC is not feasible, because you cannot revoke an RFC and you
cannot make people stop knowing what they already know

DF

On Sat, Apr 15, 2023, 10:52 AM Hector Santos  wrote:

>
>
> On Apr 14, 2023, at 7:31 PM, Dotzero  wrote:
>
> On Fri, Apr 14, 2023 at 5:55 PM Hector Santos  <40isdg@dmarc.ietf.org>> wrote:
>
> Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.
>>
>> DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC
>> failure.  In standard boolean logic is it an OR condition:
>>
>> IF SPF FAILS or DKIM FAILS Then Reject.
>>
>
> You have it absolutely backwards.
>
> DMARC says if either (aligned) SPF validates or (aligned) DKIM validates,
> it passes.
>
>
> Hi Mike,
>
> Appreciate your comment.
>
> This OR gate logic will short-circuit DKIM with SPF validating.
> Optimizing means not processing the payload and just issue a 250 which is
> ‘absolutely' not what we want. In fact, DMARC logic is an AND gate of two
> protocols; one standard, one informational with some controversial
> constraints (alignment).  I think you maybe meant:
>
> SPF predates ADSP/DMARC. It is a 5321 level technology.  It is not a
> payload 5322 technology.   Interestingly, you might be thinking in terms of
> SenderID which was a 5322 technology which offers SPF with the PRA
> (5322.From) as a new identity to evaluate.
>
> I know it’s hard to believe for many but there is still a good percentage
> of domains that do not do ADSP or DMARC and maybe not even DKIM.  Just
> consider platforms using Integrated Mail Bots to automate things and they
> who don’t need the overhead. SPF is good enough.
>
> Using Pareto, SPF is the only thing needed for hard reject policy (-ALL).
> DMARC is useless at this point unless you want it to override SPF hardfail
> rejects and record and send reports,  That would be a local policy.  An
> implementation detail.
>
> Over 88% of the time, when SPF fails, DKIM/ADSP/DMARC, if available would
> also fail.  So the payoff is high to short-circuit and lowered when you
> needless transfer a potential large and harmful payload.
>
> But for SPF soft failures (~ALL), that is when the interest of coupling
> SPF soft fail results  with ADSP results got traction.
>
> SPF verifiers will pass SPF weaker policy results in meta-header data and
> that meant the payload protocol can help here.  Microsoft explored this
> method and had a secret source to determine how soft failures can be
> coupled with ADSP results.
>
> DMARC never considered partial results. DMARC see SPF as a pass not
> soft-fail.  So if DKIM passes and all four (4) domain identities are
> aligned, the transaction passes.  That’s an AND gate and you don’t need to
> even to process SPF or do DKIM validation if the domains do not align.
>
> —
> HLS
>
>
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 14, 2023, at 7:31 PM, Dotzero  wrote:
> 
> On Fri, Apr 14, 2023 at 5:55 PM Hector Santos  > wrote:
>> Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.
>> 
>> DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC 
>> failure.  In standard boolean logic is it an OR condition:
>> 
>> IF SPF FAILS or DKIM FAILS Then Reject.
> 
> You have it absolutely backwards.
> 
> DMARC says if either (aligned) SPF validates or (aligned) DKIM validates, it 
> passes.

Hi Mike, 

Appreciate your comment. 

This OR gate logic will short-circuit DKIM with SPF validating.  Optimizing 
means not processing the payload and just issue a 250 which is ‘absolutely' not 
what we want. In fact, DMARC logic is an AND gate of two protocols; one 
standard, one informational with some controversial constraints (alignment).  I 
think you maybe meant:

SPF predates ADSP/DMARC. It is a 5321 level technology.  It is not a payload 
5322 technology.   Interestingly, you might be thinking in terms of SenderID 
which was a 5322 technology which offers SPF with the PRA (5322.From) as a new 
identity to evaluate.  

I know it’s hard to believe for many but there is still a good percentage of 
domains that do not do ADSP or DMARC and maybe not even DKIM.  Just consider 
platforms using Integrated Mail Bots to automate things and they who don’t need 
the overhead. SPF is good enough.

Using Pareto, SPF is the only thing needed for hard reject policy (-ALL).  
DMARC is useless at this point unless you want it to override SPF hardfail 
rejects and record and send reports,  That would be a local policy.  An 
implementation detail.

Over 88% of the time, when SPF fails, DKIM/ADSP/DMARC, if available would also 
fail.  So the payoff is high to short-circuit and lowered when you needless 
transfer a potential large and harmful payload.

But for SPF soft failures (~ALL), that is when the interest of coupling SPF 
soft fail results  with ADSP results got traction.  

SPF verifiers will pass SPF weaker policy results in meta-header data and that 
meant the payload protocol can help here.  Microsoft explored this method and 
had a secret source to determine how soft failures can be coupled with ADSP 
results. 

DMARC never considered partial results. DMARC see SPF as a pass not soft-fail.  
So if DKIM passes and all four (4) domain identities are aligned, the 
transaction passes.  That’s an AND gate and you don’t need to even to process 
SPF or do DKIM validation if the domains do not align. 

—
HLS




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

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

On April 15, 2023 1:55:59 PM UTC, Jesse Thompson  wrote:
>On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote:
>> On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote:
>> > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
>> > > The Sender's users being denied the ability to participate in a list due
>> > > to its policies seems to me like it puts this customer service problem
>> > > where it belongs.
>> > Let's say, tomorrow, IETF configures this list to reject Todd's mail (as
>> > well as for every other member with p=reject) and/or disables from
>> > rewriting. Does Todd's domain owner care? No. Todd cares. Todd can't argue
>> > with his CISO and IT security team and biz dev team and public relations
>> > team and legal team and all of the other forces that caused his domain
>> > owner to publish p=reject. But he can argue with IETF for making the
>> > decision to make the change, because he feels like the IETF considers him
>> > an important stakeholder.
>> > 
>> > It's this list's customer service problem, like it or not.
>> > 
>> > After calling IETF customer service, Todd finds out his options are:
>> > 1. Create an email address in a domain that houses members of the general
>> > public, instead of one that represents his identity as a member of a
>> > company. 2. Don't participate in the list.
>> > 
>> > But Todd is really important to this list, and doesn't like these options.
>> > Surely something can be done for an old friend? John, having been escalated
>> > this customer service dilemma seeks DMARCbis for guidance and finds:
>> > 
>> > ...MUST NOT p=reject...
>> > (Todd's company is pretty clearly stating Todd mustn't be representing his
>> > company on any mailing list.)
>> > 
>> > ...Domain Owner MUST provide a different domain with p=none for mailing 
>> > list
>> > participants. (Maybe they do, maybe they don't, but it's worth asking.)
>> > 
>> > ...Mailbox providers MUST NOT reject or quarantine email based solely on a
>> > DMARC policy violation. (John could ask each mailbox provider to create an
>> > exception to their DMARC policy enforcement)
>> > 
>> > and he also finds something like:
>> > 
>> > ...If a mailing list would like to provide the best customer experience for
>> > authors within domains that violate the "MUST NOT p=reject" and to deliver
>> > the author's mail to mailbox providers violate their "MUST NOT solely
>> > enforce", for those authors the mailing list MUST rewrite the From header
>> > to use a different domain. This is a new mode of interoperability the
>> > mailing list may choose to adhere to.
>> > 
>> > John now knows what he MUST do to provide the best customer experience 
>> > given
>> > the reality he finds himself in with an important stakeholder. He can
>> > choose to ignore that MUST as much as the domain owners and mailbox
>> > providers will choose to ignore their MUST NOTs.
>> > 
>> > I feel like there will be very few mailing lists that will ever stop
>> > rewriting (among those who are doing it), especially if DMARC adoption
>> > (publishing and enforcement) continues to rise. This is the new way of
>> > interoperating, in reality.
>> > 
>> > Throw them a bone so that they have a MUST to justify the things they had 
>> > to
>> > do to interoperate all this time. It's not as easy for them to justify
>> > their reality with only this page
>> > 
>> > to lean on.
>> 
>> Or Todd gets a Gmail account for his IETF work and doesn't bother tilting at 
>> windmills.
>
>That was the first option in the customer service dilemma, and it is the 
>option I have chosen for now. I do not carry my company's brand in anything I 
>say here. All opinions expressed are my own, [but maybe my opinions carry less 
>weight as a result?]

For the IETF, this is a net good as everyone participates as an individual.

>Why not turn off rewriting on this list, as an experiment? The hypothesis is 
>that everyone will switch to Gmail and not tilt at IETF, but instead they will 
>tilt at their domain owners.

That moves the damage to list participants who are using systems that reject on 
DMARC fail and isn't (as I understood it) what was being proposed.  The 
proposal was to prevent email from p=reject domains from being posted at all, 
which is rather different.  If we did that experiment, I wouldn't particularly 
mind, but I don't think you would get a representative result, since people 
know it's an experiment.

>Earlier it was accused that no one is offering alternative language proposals. 
> 
>
>I feel like "Domain Owner MUST provide a domain with p=none for mailing list 
>participants" was a reasonable suggestion, and isn't incompatible with "MUST 
>NOT p=reject for domains with members of the general public". A couple of 
>people found it acceptable when I suggested it before, and no one else 
>rejected it (or read it). That kind of language makes it more clear that the 

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

On April 15, 2023 12:26:16 PM UTC, Laura Atkins  wrote:
>On Apr 15, 2023, at 4:25 AM, Scott Kitterman  wrote:
...
>> Or [person] gets a Gmail account for his IETF work and doesn't bother 
>> tilting at 
>> windmills.
>
>That solution only works until gmail publishes p=reject. At one point they 
>said they were going to do that. 
>
>It seems to me that there is zero harm in actively documenting the problems 
>with DMARC and making interoperability recommendations about who should and 
>should not be publishing restrictive policies. 

I agree on documenting the issues with DMARC and making recommendations to 
improve interoperability.  There are issues and they're significant, but we 
shouldn't catastrophize them either.

To your other point, if that happens then people will move to another provider 
if it affects them negatively.  If free email providers that don't have 
p=reject get hard to find, then that probably creates a demand signal and some 
entrepreneur will fill the void.

Scott K

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

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

I can support Todd's language:

"Domain Owner MUST provide a domain with p=none for mailing list
participants"

because it presupposes participation with a mailing list, in particular a
mailing list that presumes a right to modify content in transit.

Mailing lists are not the only cause of non-malicious DMARC violations, but
they are apparently the most significant.   Another potential cause is
forwarding after a content-altering spam filter.The use of "external
sender" disclaimers has become pretty common as part of cyber-insurance
contracts.   Appropriate language would be:

   - Domains that allow forwarding to external sources should not allow
   spam filters to add or alter content.   Similarly, domains that allow spam
   filters to add or alter content should not allow forwarding outside of the
   organization.

Many of the other problems involve the From user being set to match the
recipient address, because the message was triggered by the recipient using
the sender's website.   This problem is more contained and probably not
worthy of our mention, since those senders should behave differently.

Doug Foster




On Sat, Apr 15, 2023 at 9:56 AM Jesse Thompson  wrote:

> On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote:
>
> On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote:
> > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
> > > The Sender's users being denied the ability to participate in a list
> due
> > > to its policies seems to me like it puts this customer service problem
> > > where it belongs.
> > Let's say, tomorrow, IETF configures this list to reject Todd's mail (as
> > well as for every other member with p=reject) and/or disables from
> > rewriting. Does Todd's domain owner care? No. Todd cares. Todd can't
> argue
> > with his CISO and IT security team and biz dev team and public relations
> > team and legal team and all of the other forces that caused his domain
> > owner to publish p=reject. But he can argue with IETF for making the
> > decision to make the change, because he feels like the IETF considers him
> > an important stakeholder.
> >
> > It's this list's customer service problem, like it or not.
> >
> > After calling IETF customer service, Todd finds out his options are:
> > 1. Create an email address in a domain that houses members of the general
> > public, instead of one that represents his identity as a member of a
> > company. 2. Don't participate in the list.
> >
> > But Todd is really important to this list, and doesn't like these
> options.
> > Surely something can be done for an old friend? John, having been
> escalated
> > this customer service dilemma seeks DMARCbis for guidance and finds:
> >
> > ...MUST NOT p=reject...
> > (Todd's company is pretty clearly stating Todd mustn't be representing
> his
> > company on any mailing list.)
> >
> > ...Domain Owner MUST provide a different domain with p=none for mailing
> list
> > participants. (Maybe they do, maybe they don't, but it's worth asking.)
> >
> > ...Mailbox providers MUST NOT reject or quarantine email based solely on
> a
> > DMARC policy violation. (John could ask each mailbox provider to create
> an
> > exception to their DMARC policy enforcement)
> >
> > and he also finds something like:
> >
> > ...If a mailing list would like to provide the best customer experience
> for
> > authors within domains that violate the "MUST NOT p=reject" and to
> deliver
> > the author's mail to mailbox providers violate their "MUST NOT solely
> > enforce", for those authors the mailing list MUST rewrite the From header
> > to use a different domain. This is a new mode of interoperability the
> > mailing list may choose to adhere to.
> >
> > John now knows what he MUST do to provide the best customer experience
> given
> > the reality he finds himself in with an important stakeholder. He can
> > choose to ignore that MUST as much as the domain owners and mailbox
> > providers will choose to ignore their MUST NOTs.
> >
> > I feel like there will be very few mailing lists that will ever stop
> > rewriting (among those who are doing it), especially if DMARC adoption
> > (publishing and enforcement) continues to rise. This is the new way of
> > interoperating, in reality.
> >
> > Throw them a bone so that they have a MUST to justify the things they
> had to
> > do to interoperate all this time. It's not as easy for them to justify
> > their reality with only this page
> > <
> https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail>
> > to lean on.
>
> Or Todd gets a Gmail account for his IETF work and doesn't bother tilting
> at
> windmills.
>
>
> That was the first option in the customer service dilemma, and it is the
> option I have chosen for now. I do not carry my company's brand in anything
> I say here. All opinions expressed are my own, [but maybe my opinions carry
> less weight as a result?]
>
> Why not turn off rewriting on this list, as an experiment? The hypothesis

Re: [dmarc-ietf] Signaling MLMs

[Jesse Thompson]

On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote:
> On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote:
> > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
> > > The Sender's users being denied the ability to participate in a list due
> > > to its policies seems to me like it puts this customer service problem
> > > where it belongs.
> > Let's say, tomorrow, IETF configures this list to reject Todd's mail (as
> > well as for every other member with p=reject) and/or disables from
> > rewriting. Does Todd's domain owner care? No. Todd cares. Todd can't argue
> > with his CISO and IT security team and biz dev team and public relations
> > team and legal team and all of the other forces that caused his domain
> > owner to publish p=reject. But he can argue with IETF for making the
> > decision to make the change, because he feels like the IETF considers him
> > an important stakeholder.
> > 
> > It's this list's customer service problem, like it or not.
> > 
> > After calling IETF customer service, Todd finds out his options are:
> > 1. Create an email address in a domain that houses members of the general
> > public, instead of one that represents his identity as a member of a
> > company. 2. Don't participate in the list.
> > 
> > But Todd is really important to this list, and doesn't like these options.
> > Surely something can be done for an old friend? John, having been escalated
> > this customer service dilemma seeks DMARCbis for guidance and finds:
> > 
> > ...MUST NOT p=reject...
> > (Todd's company is pretty clearly stating Todd mustn't be representing his
> > company on any mailing list.)
> > 
> > ...Domain Owner MUST provide a different domain with p=none for mailing list
> > participants. (Maybe they do, maybe they don't, but it's worth asking.)
> > 
> > ...Mailbox providers MUST NOT reject or quarantine email based solely on a
> > DMARC policy violation. (John could ask each mailbox provider to create an
> > exception to their DMARC policy enforcement)
> > 
> > and he also finds something like:
> > 
> > ...If a mailing list would like to provide the best customer experience for
> > authors within domains that violate the "MUST NOT p=reject" and to deliver
> > the author's mail to mailbox providers violate their "MUST NOT solely
> > enforce", for those authors the mailing list MUST rewrite the From header
> > to use a different domain. This is a new mode of interoperability the
> > mailing list may choose to adhere to.
> > 
> > John now knows what he MUST do to provide the best customer experience given
> > the reality he finds himself in with an important stakeholder. He can
> > choose to ignore that MUST as much as the domain owners and mailbox
> > providers will choose to ignore their MUST NOTs.
> > 
> > I feel like there will be very few mailing lists that will ever stop
> > rewriting (among those who are doing it), especially if DMARC adoption
> > (publishing and enforcement) continues to rise. This is the new way of
> > interoperating, in reality.
> > 
> > Throw them a bone so that they have a MUST to justify the things they had to
> > do to interoperate all this time. It's not as easy for them to justify
> > their reality with only this page
> > 
> > to lean on.
> 
> Or Todd gets a Gmail account for his IETF work and doesn't bother tilting at 
> windmills.

That was the first option in the customer service dilemma, and it is the option 
I have chosen for now. I do not carry my company's brand in anything I say 
here. All opinions expressed are my own, [but maybe my opinions carry less 
weight as a result?]

Why not turn off rewriting on this list, as an experiment? The hypothesis is 
that everyone will switch to Gmail and not tilt at IETF, but instead they will 
tilt at their domain owners.

Earlier it was accused that no one is offering alternative language proposals.  

I feel like "Domain Owner MUST provide a domain with p=none for mailing list 
participants" was a reasonable suggestion, and isn't incompatible with "MUST 
NOT p=reject for domains with members of the general public". A couple of 
people found it acceptable when I suggested it before, and no one else rejected 
it (or read it). That kind of language makes it more clear that the domain 
owner must work to sort out their mixed-use domains (by adopting all of the 
great subdomain/treewalk/psd additions in DMARCbis).

And the "If a mailing list would like to provide the best customer 
experience...MUST rewrite" suggestion seems like a reasonable way out of this 
"interoperability vs reality" standoff.  How about if I soften it up further: 

"Any sender (mailing list, forwarder, ESP, or otherwise) which is tasked to 
send unauthenticated email from an address within a p=reject|quarantine domain 
it MUST refuse to send the message or send the message using an RFC5322.from 
address in a different domain."

Re: [dmarc-ietf] Signaling MLMs

[Laura Atkins]

On Apr 15, 2023, at 4:25 AM, Scott Kitterman  wrote:
> 
> On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote:
>>> On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
>>> The Sender's users being denied the ability to participate in a list due
>>> to its policies seems to me like it puts this customer service problem
>>> where it belongs.
>> Let's say, tomorrow, IETF configures this list to reject Todd's mail (as
>> well as for every other member with p=reject) and/or disables from
>> rewriting. Does Todd's domain owner care? No. Todd cares. Todd can't argue
>> with his CISO and IT security team and biz dev team and public relations
>> team and legal team and all of the other forces that caused his domain
>> owner to publish p=reject. But he can argue with IETF for making the
>> decision to make the change, because he feels like the IETF considers him
>> an important stakeholder.
>> 
>> It's this list's customer service problem, like it or not.
>> 
>> After calling IETF customer service, Todd finds out his options are:
>> 1. Create an email address in a domain that houses members of the general
>> public, instead of one that represents his identity as a member of a
>> company. 2. Don't participate in the list.
>> 
>> But Todd is really important to this list, and doesn't like these options.
>> Surely something can be done for an old friend? John, having been escalated
>> this customer service dilemma seeks DMARCbis for guidance and finds:
>> 
>> ...MUST NOT p=reject...
>> (Todd's company is pretty clearly stating Todd mustn't be representing his
>> company on any mailing list.)
>> 
>> ...Domain Owner MUST provide a different domain with p=none for mailing list
>> participants. (Maybe they do, maybe they don't, but it's worth asking.)
>> 
>> ...Mailbox providers MUST NOT reject or quarantine email based solely on a
>> DMARC policy violation. (John could ask each mailbox provider to create an
>> exception to their DMARC policy enforcement)
>> 
>> and he also finds something like:
>> 
>> ...If a mailing list would like to provide the best customer experience for
>> authors within domains that violate the "MUST NOT p=reject" and to deliver
>> the author's mail to mailbox providers violate their "MUST NOT solely
>> enforce", for those authors the mailing list MUST rewrite the From header
>> to use a different domain. This is a new mode of interoperability the
>> mailing list may choose to adhere to.
>> 
>> John now knows what he MUST do to provide the best customer experience given
>> the reality he finds himself in with an important stakeholder. He can
>> choose to ignore that MUST as much as the domain owners and mailbox
>> providers will choose to ignore their MUST NOTs.
>> 
>> I feel like there will be very few mailing lists that will ever stop
>> rewriting (among those who are doing it), especially if DMARC adoption
>> (publishing and enforcement) continues to rise. This is the new way of
>> interoperating, in reality.
>> 
>> Throw them a bone so that they have a MUST to justify the things they had to
>> do to interoperate all this time. It's not as easy for them to justify
>> their reality with only this page
>> 
>> to lean on.
> 
> Or Todd gets a Gmail account for his IETF work and doesn't bother tilting at 
> windmills.

That solution only works until gmail publishes p=reject. At one point they said 
they were going to do that. 

It seems to me that there is zero harm in actively documenting the problems 
with DMARC and making interoperability recommendations about who should and 
should not be publishing restrictive policies. 

Laura



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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Fri 14/Apr/2023 21:36:54 +0200 Dotzero wrote:

On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins  wrote:

On 14 Apr 2023, at 18:38, Alessandro Vesely  wrote:
On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:

On 12 Apr 2023, at 12:21, Douglas Foster  
wrote:

Any form of security creates inconvenience.

Yes. And we make tradeoffs between that. In this case, the security is 
ensuring that users at specific domains can and should only send mail 
through approved channels managed by those domains. Many users have 
violated those security policies, by participating in mailing lists. This 
caused problems for other folks on the mailing lists - as they were the 
ones removed from the list due to the security policy. The lists responded 
by rewriting. This causes yet more inconvenience to other subscribers and, 
additionally, allows the users to bypass their domain security policy. 
I am not seeing how this creates an arena of security.


Security is not From: munging.  That's the workaround that security 
requires.


No security (at least in the viewpoint of some people) is using a p=reject 
for mail from their domain. In that context, From: munging is actively 
subverting the security  settings of domains.



I guess the subversion you mean is that From: munging gets people used to see 
such kind of fake.  I agree that incongruity between display-phrase and actual 
address can be a security threat.  However, there are innocent forms of it.



Based on the header rewriting done by IETF, I have a hard time seeing how 
its rewrite of Comcast addresses can cause any of the problems that you 
cite.


That’s how the IETF rewrites, it’s not how everyone rewrites.


Couldn't the IETF say how to rewrite?

There’s currently a deployed base where there are many different ways to 
munge. "It is a _fact_.”



Yes.  Yet, better munging can always be applied without altering 
functionalities.



But does your domain require even headers to be rewritten?Why doesn't
IETF ask you, and omit rewrite if that is what your domain wants?


Because that doesn’t scale for the IETF.


Mailman options do scale.  From: rewriting is going to fade off by first 
allowing single subscribers to disable it, for the posts directed to them, 
after their MX set up some kind of agreement with the MLM. >>>
The _fact_ still remains that From: rewriting is actively subverting the 
security of domains that choose to publish p=reject.



I'd rather call it training readers on the significance of the display-phrase 
part of a From: line.  Phishermen will keep on exploiting it in any case.



It is hard for me to cry over mailing lists when they cannot ensure that a 
post comes from the asserted poster and they cannot adapt their DMARC 
defenses to the preferences of the recipient domains.   Life is hard.   It 
only gets harder if I wait for someone else to solve problems that I can 
solve myself.


I don’t understand how header rewriting ensures the authenticity of a 
poster. Given the data is being modified by the MLM, it seems to me that 
rewriting compounds the problem.


It doesn't.  The authenticity should be checked on entry.  THIS IS ABUSE 
post had dkim=fail by ietfa.amsl.com, but they didn't bother rejecting 
for that, which is what they should have done.  We are suffering all the 
damage caused by DMARC but don't enjoy any of the advantages it could bring.


I encourage you to think very hard about why, after more than a decade, we 
still don’t see any of the advantages to DMARC.



Didn't get that.   I'd guess that implementing DMARC wasn't a priority for IETF 
mailing lists.



While the you part of "we" may not see any advantages, quite a few 
financials, greeting card sites, retailers AND many receivers have seen the 
advantages, including p=reject. One thing I've learned over the years is 
that it is presumptuous to speak on behalf of "everyone" when you don't 
actually have their authorization to speak on their behalf. It's kind of 
like sending email claiming to be from someone else's domain without their 
permission.



Michael obviously understood Laura's point better than me.  The only part I 
understood is that "we" are the ML subscribers.  We see no advantage because 
DMARC is not implemented on ietfa.amsl.com.


Oh, certainly until the only abusive messages we see are those straw men, there 
is no actual worry.  It's the principle...



Best
Ale
--





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