Re: [dmarc-ietf] Proposed text to close out Ticket 96

[Jesse Thompson]

On Wed, Apr 5, 2023, at 5:20 PM, Seth Blank wrote:
> When we talk about DMARC and interoperability, we have to remember that there 
> are THREE participants within DMARC that need to interoperate, the sender, 
> the receiver, and the domain owner. We keep on discussing the sender and 
> receiver relationship, and leaving the domain owner out to dry. It's the 
> domain owner's authentication, and their policy, which DMARC is all about. 
> DMARC is nothing without domain owners.

+1 ___
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?

[Jesse Thompson]

On Wed, Apr 5, 2023, at 4:41 PM, Jim Fenton wrote:
> This got me to musing: What if IETF decided to remove its From address 
> rewriting and started bouncing all incoming mail to its mailing lists from 
> domains that have a p=reject (and maybe p=quarantine) policy? I don’t think 
> it would be pretty.

Nothing new here. People have moved on. I now use a mailbox provider that has 
p=none for this list, instead of my employer's domain (p=quarantine) or my 
preferred mailbox provider that uses VERP-ish (which subsequently means IETF 
can't identify the MAIL FROM as being subscribed to this list). I also happen 
to really like fastmail and team, so I appreciate that these mailing lists have 
given me the opportunity to enjoy their service.

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

[Dotzero]

On Wed, Apr 5, 2023 at 5:41 PM Jim Fenton  wrote:

> On 1 Apr 2023, at 8:25, Dotzero wrote:
>
> >  Hmm, let's apply this to DMARC.
> >
> > " But it interoperates just fine once you make the effort."
> >
> > Nobody forces a Sender to publish a DMARC record. Nobody forces a
> receiver
> > to validate DMARC. Nobody forces mailing lists to accept mail from
> domains
> > which publish a DMARC record let alone one which publishes  p=reject
> > policy. But it interoperates just fine once you make the effort.
>
> Doesn’t this again assume that all DMARC breakage is due to mailing lists?
>

Not at all. The discussion (and specific post I was responding to) was
about mailing lists but it also applies more generally. A number of years
ago I saw bounces from a Polish domain. Their policy was that if the From
and the Mail From didn't match they would reject the inbound email. I find
that absurdly limiting but they can implement whatever policy they want.
Maybe there are sending domains that do that for all their mail. My point
is that domain owners/admins, at least on certain levels, get to choose how
they interact with other networks/servers.


>
> This got me to musing: What if IETF decided to remove its From address
> rewriting and started bouncing all incoming mail to its mailing lists from
> domains that have a p=reject (and maybe p=quarantine) policy? I don’t think
> it would be pretty.
>

I also don't think it would  be pretty but it's within the realm of options
they can choose from.

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

Re: [dmarc-ietf] Proposed text to close out Ticket 96

[Scott Kitterman]

On April 5, 2023 10:20:28 PM UTC, Seth Blank 
 wrote:
>On Wed, Apr 5, 2023 at 2:57 PM Scott Kitterman  wrote:
>
>> My understanding is that the IETF doesn't do implementation
>> specifications.  I'm not sure what problem that's related to
>> interoperability this is meant to address.
>>
>> I think the ticket should be closed without action
>
>
>The purpose of DMARC from the point of view of a domain owner, is to stop
>spoofing of their exact domain from unauthorized sources.
>
>The document describes certain mechanics of this relative to the Author
>Domain, but never explains what doing this completely for the
>Organizational Domain and its entire hierarchy looks like. As this is the
>goal of many domain owners, it is worth clear definition in the document.
>
>When we talk about DMARC and interoperability, we have to remember that
>there are THREE participants within DMARC that need to interoperate, the
>sender, the receiver, and the domain owner. We keep on discussing the
>sender and receiver relationship, and leaving the domain owner out to dry.
>It's the domain owner's authentication, and their policy, which DMARC is
>all about. DMARC is nothing without domain owners.
>
>This is clunky, because there's normally not a person or business in the
>mix when we talk about interop. With DMARC, there is. Policy needs to work
>as expected, and consistently. Therefore, we need clear definition. I can
>see how this might look like implementation guidance if you're only
>thinking about the bits moving between the sender and the receiver. In the
>DMARC context, the domain owner's desires, and clarity on how to implement
>them, are critical to be spelled out in the document.
>
>The text that I proposed feels like the minimum text needed to address this
>clarity, without telling people what to do.

I don't follow.  Section 5.5 is called Domain Owner Actions.  

Also, that's the goal for some domains, but not others.  We shouldn't 
over-generalize.  Personally, I publish DMARC records for the aggregate 
reports.  I find them useful.  Publishing a DMARC record with anything other 
than p=none is not something I'm considering due to the associated side effects.

Scott K

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

[dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected

[Seth Blank]

I believe there’s a critical use case we missed with the tree walk,
specifically around policy and reporting discovery, not determining
organizational domain alignment.

One of the reasons we discussed a tree walk for DMARC bis in the first
case, was a specific problem with larger more complicated organizations for
whom policy discovery in 7489 does not work as needed. These organizations
include governments, universities, and healthcare organizations, and they
have shared some details both on this list and at M3AAWG.

Specifically, with complex organizations with sub-organizations with
separate reporting and policy needs, the sub-organization policy/reporting
was being skipped by the policy lookup, and the reports wound up at places
unable to act on or properly route them to the right place.

In the most extreme cases (US federal government), we see the following
paradigm with some frequency:

bounce.sender-subdomain.division.agency.department.gov with a 5322.From
generally of division.agency.department.gov or agency.department.gov.
Sometimes the full bounce domain is in the From (especially when things are
first set up but not yet configured well using dmarc, hence the need for
appropriate reporting!)-- this is rare, but essential to get reporting
right when it happens.

The reporting and policy here that are important are around the division or
agency, and rarely the department. In the case where we have a long PSD,
this reporting and policy would be skipped by the current proposed
algorithm with an N=5. e.g. with
sender.agency.department.example.gov.ccTLD, the current discovery mechanism
would skip the agency policy and reporting (which is what is wanted) and
instead land on the department one (which is not).

When we first proposed the tree walk, we thought we’d just walk up 5
labels, and then stop if nothing had been found. This handles this complex
organization use case cleanly for legitimate mail, which was the initial
intent. However, it a) does not handle the abuse use case well (what policy
do you choose if you exhaust the lookups without a policy answer?), and b)
the group rightly pointed out that this misses the use case of determining
organizational domain alignment, which is essential for dmarc overall. The
current jump in the algorithm handles both (a) and (b) effectively.

John Levine suggested I was twisting myself in knots trying to solve both
these use cases, when the simplest solution was to leave the algorithm
exactly as it is, and just revisit N.

So how do we handle this? What’s the worst case? Looking at the above
example, the longest “complex org” would be 5 labels long. I think we’ve
already agreed, backed by data from the PSL, that the longest PSD would be
4 labels long.

This seems to say that revisiting an N of (max complex labels, + max psd
labels, + 1) = 10 would cover even the most complex use cases without
needing to change the normative part of the document. Maybe there’s a
better N at 8 or 9. We should discuss. Below, I’ve proposed some
explanatory text and updated examples if we do want to revisit. I’ve used
N=10 as a placeholder, so if we end up at a lesser N, we only need to
remove examples, not generate more.

To be clear, due to the current policy discovery mechanics (check author
domain then jump to organizational domain), I'm not aware of any of these
complex orgs setting dmarc policies on Author Domains at such a depth. i.e.
N=5 today would not break anything currently in place. However, the tree
walk now enables these complex orgs to set policy much deeper in their
hierarchy, which would then potentially not work as expected and possibly
send reports to the wrong destination due to the current N=5.

I don't feel strongly about N=10, but I do feel strongly that N=5 is
insufficient. My gut feel is that 6 or 7 is likely more than enough to
cover all real world examples, but it's a gut feel only and not backed by
data.

Have at it!

Seth, as an individual

---

I propose that the existing text in rev -27 be slightly modified. Current
text is shown here, and current text with proposed modifications in bold
italics is shown on subsequent pages:

OLD

##  DNS Tree Walk {#dns-tree-walk}

The DMARC protocol defines a method for communicating information through
the publishing of records in DNS. Both the content of the records and their
location in the DNS hierarchy are used for two purposes: policy discovery
(see Section 4.7
)
and Organizational Domain determination (see Section 4.8

).

The relevant DMARC record for these purposes is not necessarily the DMARC
policy record found in DNS at the same level as the name label for the
domain in question. Instead, some domains will inherit their DMARC policy
records from parent domains one level or more above them in the DNS
hierarchy. 

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

[Douglas Foster]

Yes, imperfections will always be with us.That is my point.

Why should we expect that millions of organizations, operating
independently, will produce a result where the good guys always have
perfectly correct information?

My implementation expects problems.Separating the harmless mistakes
from the spammer is part of my job.   Senders provide me with usable
information 93% of the time.  My job is to make sense of the other
7%, which I do.  Not an unreasonable burden.  As I said previously, for
high-end filtering problems, a really good user quarantine module could
avoid an excess of system administrator labor.

When my problem set is large, I let the unauthenticated messages through,
and hope that my content filtering will catch the bad stuff, which it
usually does.   I review the data after the fact and tune my reputation
database.

As the reputation database grows, the problem gets easier, because:

   - The volume of unauthenticated messages goes down.
   - The acceptable subset of unauthenticated messages become progressively
   less important to the recipient.
   - The acceptable percentage of unauthenticated messages becomes smaller
   and smaller.

All of this means that quarantine delays become an acceptable burden on the
filtering process.

My frustration is that RFC 7208 and RFC 7489 are written as if all data
will be perfect, so no discussion of exceptions is necessary.   Then
product developers implement the same assumption.   The result is "Check
box 1 to block on SPF Fail," and "Check box 2 to block on DMARC Fail."
 Worse yet, the administrator often has to start blocking messages to find
out how much damage results, because there is no option to gather data
before acting on it.   When he does find problems, there is a good chance
that whitelisting around the problem will create security holes that
whitelist potential spam.   We have a global problem of mis-set
expectations and defective products.   The current draft of DMARCbis does
nothing to fix the misunderstanding.

When evaluators implement SPF and DMARC in a way that expects problems,
legitimate senders will be a lot happier, and illegitimate senders will
have to work harder.   Our document(s) need to move the world in that
direction.

Doug Foster


On Wed, Apr 5, 2023 at 7:18 AM Neil Anuskiewicz 
wrote:

>
>
> On Apr 5, 2023, at 3:58 AM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
> 
> The sad thing is that there is no need to do a bandage pull if evaluators
> can learn how to serve the interests of their users properly.   I don't
> throw away any mail based on Sender Authentication failure alone.   But I
> also don't tolerate the idea that I have to accept malicious impersonation
> in order to accept all of the mail that my users should receive.
>
> In this group, I have been arguing a losing cause that DMARC
> authentication can wisely be applied whether a DMARC policy exists or not.
>  After discarding blacklisted message sources, here are my results from
> applying DMARC-like rules to all of my mail:
>
>
> Ideally, what you’re saying is true but many larger organizations had no
> real controls in place, which of course leads to the proliferation of
> shadow IT, including ESP’s sending bulk mail right from the org domain.
> It’s like herding gerbils for the system and security folks to influence
> the account admins. Often an ESP admin is a marketing person which isn’t
> inherently bad as there are some extraordinary marketers. But they often
> feel uncomfortable with techie stuff so choose to pretend that IT and
> security haven’t been asking for help with the offer to the marketing folks
> of screen shares, etc., yet often these account admins don’t show at
> meetings. Then I see tech execs talking more and more about how they’ve
> really tried to go this the right way but unfortunately we need to piss
> some people off to get their attention. Often the right question can help
> though that right question is essentially please play ball. It’s coming
> from the top, we need to have this done within a couple months so I’m going
> to need your cooperation.
>
>
> 61% are aligned with both SPF PASS and DKIM PASS
> 16% are aligned with SPF only
> 16% are aligned with DKIM only
> 
> 93% aligned with DMARC-like logic
>   4% are authenticated using local policy that allows non-standard
> alignment or overrides a non-PASS SPF result.
> 
> 97% of all FROM address are verified to my satisfaction
>
> Clearly, I am within reach of 100% verification of the RFC5322.From domain.
>
> I don't know that I receive any mailing list traffic, but this is how it
> would fit into my model:
> - Failure to verify causes the message to be flagged for review.
> - Review indicates that the message is from a mailing list
> - Research determines that the MLM provides reliable Sender Authentication
> and best effort spam filtering, so I do not need to repeat sender
> authentication
> - I create a local policy that accepts 

Re: [dmarc-ietf] Proposed text to close out Ticket 96

[Seth Blank]

On Wed, Apr 5, 2023 at 2:57 PM Scott Kitterman  wrote:

> My understanding is that the IETF doesn't do implementation
> specifications.  I'm not sure what problem that's related to
> interoperability this is meant to address.
>
> I think the ticket should be closed without action


The purpose of DMARC from the point of view of a domain owner, is to stop
spoofing of their exact domain from unauthorized sources.

The document describes certain mechanics of this relative to the Author
Domain, but never explains what doing this completely for the
Organizational Domain and its entire hierarchy looks like. As this is the
goal of many domain owners, it is worth clear definition in the document.

When we talk about DMARC and interoperability, we have to remember that
there are THREE participants within DMARC that need to interoperate, the
sender, the receiver, and the domain owner. We keep on discussing the
sender and receiver relationship, and leaving the domain owner out to dry.
It's the domain owner's authentication, and their policy, which DMARC is
all about. DMARC is nothing without domain owners.

This is clunky, because there's normally not a person or business in the
mix when we talk about interop. With DMARC, there is. Policy needs to work
as expected, and consistently. Therefore, we need clear definition. I can
see how this might look like implementation guidance if you're only
thinking about the bits moving between the sender and the receiver. In the
DMARC context, the domain owner's desires, and clarity on how to implement
them, are critical to be spelled out in the document.

The text that I proposed feels like the minimum text needed to address this
clarity, without telling people what to do.

Seth, hatless

-- 

*Seth Blank * | Chief Technology Officer
*e:* s...@valimail.com
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text to close out Ticket 96

[Scott Kitterman]

My understanding is that the IETF doesn't do implementation specifications.  
I'm not sure what problem that's related to interoperability this is meant to 
address.

I think the ticket should be closed without action 

If you really think we need this, I think the Enforcement definition needs 
something about the domains (and subdomain) at issue either aren't affected by 
the interoperability issues discussed in 5.5.6 or has accepted the associated 
interoperability risk.  It needs to be Barry's version of 5.5.6 that's the 
starting point for the new definitions (if we are going to have them at all, 
which I think we shouldn't).

Scott K

On April 5, 2023 9:34:51 PM UTC, Seth Blank 
 wrote:
>https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/96
>
>I tried to write up an INFORMATIONAL paragraph, for ticket #96, and it kept
>on coming out strangely and did not feel appropriate in the document as a
>section unto itself.
>
>However, I think we can meet the intent of this ticket by condensing it
>into two definitions for section 3.2, an added sentence to 5.5.4 and a new
>paragraph in 5.5.6 (that stands regardless of the output of the other
>thread in process on 5.5.6), as follows:
>
>3.2.
>
>Monitoring Mode: At p=none with a valid reporting address, the domain owner
>receives reports that showcase authorized and unauthorized mail streams, as
>well as gaps pertaining to authentication information pertaining to both
>streams.
>
>Enforcement: When the Organizational Domain and all subdomains below it are
>covered by a policy that is not none. This means that the domain and its
>subdomains can only be used to send mail that is properly authenticated,
>and mail using the domain name that is unauthenticated will not reach the
>inbox of a mail receiver that validates DMARC.
>
>5.5.4 OLD
>
>Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's
>time to publish a DMARC record. For best results, Domain Owners usually
>start with "p=none", (see Section 5.5.5) with the rua tag containing a URI
>that references the mailbox created in the previous step. If the
>Organizational Domain is different from the Author Domain, a record also
>needs to be published for the Organizational Domain.
>
>5.5.4 NEW
>
>Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's
>time to publish a DMARC record. For best results, Domain Owners usually
>start with "p=none", (see Section 5.5.5) with the rua tag containing a URI
>that references the mailbox created in the previous step. This is commonly
>referred to as putting the Author Domain into Monitoring Mode. If the
>Organizational Domain is different from the Author Domain, a record also
>needs to be published for the Organizational Domain.
>
>5.5.6 OLD
>
>Once the Domain Owner is satisfied that it is properly authenticating all
>of its mail, then it is time to decide if it is appropriate to change the
>p= value in its DMARC record to p=quarantine or p=reject. Depending on its
>cadence for sending mail, it may take many months of consuming DMARC
>aggregate reports before a Domain Owner reaches the point where it is sure
>that it is properly authenticating all of its mail, and the decision on
>which p= value to use will depend on its needs.
>
>5.5.6 NEW
>
>Once the Domain Owner is satisfied that it is properly authenticating all
>of its mail, then it is time to decide if it is appropriate to change the
>p= value in its DMARC record to p=quarantine or p=reject. Depending on its
>cadence for sending mail, it may take many months of consuming DMARC
>aggregate reports before a Domain Owner reaches the point where it is sure
>that it is properly authenticating all of its mail, and the decision on
>which p= value to use will depend on its needs.
>
>Some Domain Owners may wish to ensure a policy exists for the
>Organizational Domain and all its subdomains, which is known as the
>Organizational Domain being at Enforcement. This prevents the entire
>Organizational domain's hierarchy from exact-domain spoofing. This is
>difficult for many Domain Owners to achieve, as they must repeat the above
>process to ensure mail is properly authenticated for each subdomain. Being
>at Enforcement means an Organizational Domain has no recourse if Mediators
>modify authentication information as outlined in section 8.5.
>

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

[Jim Fenton]

On 1 Apr 2023, at 8:25, Dotzero wrote:

>  Hmm, let's apply this to DMARC.
>
> " But it interoperates just fine once you make the effort."
>
> Nobody forces a Sender to publish a DMARC record. Nobody forces a receiver
> to validate DMARC. Nobody forces mailing lists to accept mail from domains
> which publish a DMARC record let alone one which publishes  p=reject
> policy. But it interoperates just fine once you make the effort.

Doesn’t this again assume that all DMARC breakage is due to mailing lists?

This got me to musing: What if IETF decided to remove its From address 
rewriting and started bouncing all incoming mail to its mailing lists from 
domains that have a p=reject (and maybe p=quarantine) policy? I don’t think it 
would be pretty.

-Jim

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

[dmarc-ietf] Proposed text to close out Ticket 96

[Seth Blank]

https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/96

I tried to write up an INFORMATIONAL paragraph, for ticket #96, and it kept
on coming out strangely and did not feel appropriate in the document as a
section unto itself.

However, I think we can meet the intent of this ticket by condensing it
into two definitions for section 3.2, an added sentence to 5.5.4 and a new
paragraph in 5.5.6 (that stands regardless of the output of the other
thread in process on 5.5.6), as follows:

3.2.

Monitoring Mode: At p=none with a valid reporting address, the domain owner
receives reports that showcase authorized and unauthorized mail streams, as
well as gaps pertaining to authentication information pertaining to both
streams.

Enforcement: When the Organizational Domain and all subdomains below it are
covered by a policy that is not none. This means that the domain and its
subdomains can only be used to send mail that is properly authenticated,
and mail using the domain name that is unauthenticated will not reach the
inbox of a mail receiver that validates DMARC.

5.5.4 OLD

Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's
time to publish a DMARC record. For best results, Domain Owners usually
start with "p=none", (see Section 5.5.5) with the rua tag containing a URI
that references the mailbox created in the previous step. If the
Organizational Domain is different from the Author Domain, a record also
needs to be published for the Organizational Domain.

5.5.4 NEW

Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's
time to publish a DMARC record. For best results, Domain Owners usually
start with "p=none", (see Section 5.5.5) with the rua tag containing a URI
that references the mailbox created in the previous step. This is commonly
referred to as putting the Author Domain into Monitoring Mode. If the
Organizational Domain is different from the Author Domain, a record also
needs to be published for the Organizational Domain.

5.5.6 OLD

Once the Domain Owner is satisfied that it is properly authenticating all
of its mail, then it is time to decide if it is appropriate to change the
p= value in its DMARC record to p=quarantine or p=reject. Depending on its
cadence for sending mail, it may take many months of consuming DMARC
aggregate reports before a Domain Owner reaches the point where it is sure
that it is properly authenticating all of its mail, and the decision on
which p= value to use will depend on its needs.

5.5.6 NEW

Once the Domain Owner is satisfied that it is properly authenticating all
of its mail, then it is time to decide if it is appropriate to change the
p= value in its DMARC record to p=quarantine or p=reject. Depending on its
cadence for sending mail, it may take many months of consuming DMARC
aggregate reports before a Domain Owner reaches the point where it is sure
that it is properly authenticating all of its mail, and the decision on
which p= value to use will depend on its needs.

Some Domain Owners may wish to ensure a policy exists for the
Organizational Domain and all its subdomains, which is known as the
Organizational Domain being at Enforcement. This prevents the entire
Organizational domain's hierarchy from exact-domain spoofing. This is
difficult for many Domain Owners to achieve, as they must repeat the above
process to ensure mail is properly authenticated for each subdomain. Being
at Enforcement means an Organizational Domain has no recourse if Mediators
modify authentication information as outlined in section 8.5.

-- 

*Seth Blank * | Chief Technology Officer
*e:* s...@valimail.com
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
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 5, 2023, at 3:58 AM, Douglas Foster  wrote:The sad thing is that there is no need to do a bandage pull if evaluators can learn how to serve the interests of their users properly.   I don't throw away any mail based on Sender Authentication failure alone.   But I also don't tolerate the idea that I have to accept malicious impersonation in order to accept all of the mail that my users should receive.In this group, I have been arguing a losing cause that DMARC authentication can wisely be applied whether a DMARC policy exists or not.   After discarding blacklisted message sources, here are my results from applying DMARC-like rules to all of my mail:Ideally, what you’re saying is true but many larger organizations had no real controls in place, which of course leads to the proliferation of shadow IT, including ESP’s sending bulk mail right from the org domain. It’s like herding gerbils for the system and security folks to influence the account admins. Often an ESP admin is a marketing person which isn’t inherently bad as there are some extraordinary marketers. But they often feel uncomfortable with techie stuff so choose to pretend that IT and security haven’t been asking for help with the offer to the marketing folks of screen shares, etc., yet often these account admins don’t show at meetings. Then I see tech execs talking more and more about how they’ve really tried to go this the right way but unfortunately we need to piss some people off to get their attention. Often the right question can help though that right question is essentially please play ball. It’s coming from the top, we need to have this done within a couple months so I’m going to need your cooperation.61% are aligned with both SPF PASS and DKIM PASS16% are aligned with SPF only16% are aligned with DKIM only93% aligned with DMARC-like logic  4% are authenticated using local policy that allows non-standard alignment or overrides a non-PASS SPF result.97% of all FROM address are verified to my satisfactionClearly, I am within reach of 100% verification of the RFC5322.From domain.I don't know that I receive any mailing list traffic, but this is how it would fit into my model:- Failure to verify causes the message to be flagged for review.- Review indicates that the message is from a mailing list- Research determines that the MLM provides reliable Sender Authentication and best effort spam filtering, so I do not need to repeat sender authentication- I create a local policy that accepts any From domain when the SMTP and Server information identify the mailing list.- Mailing list messages are forwarded to content filtering for normal acceptance processing.So my "stream info" proposal is trying to solve the "research" entry on the list above. If the mailing list cannot be trusted to perform Sender Authentication, then I need to implement code which parses the entire set of Received headers, ARC headers, and possibly other headers.  I am probably not willing put that processing burden on every message to solve a problem for a poorly-managed list    I will be easier to refuse the accommodation and tell the user to join the list with a Google account.So I think we need a document that tells evaluators how to "not be stupid".    I may be the only one present who can write it, and I could do so if the scope is willing to move in that direction.   But as long as there are stupid evaluators, senders have to cope with the reality in front of them.Yes sir, with well written documentation that’s prompted as important could help. But at the end of the day, when there are so many people and personalities a small percentage of them seem to want to do everything the hard way. To each their own.NOn Wed, Apr 5, 2023 at 4:14 AM Neil Anuskiewicz  wrote:I’m with Doug on this one. The bandage should be pulled off quickly and sympathy expressed to those who miss backward compatibility. I wouldn’t say utilitarianism is the right frame but here why wouldn’t it be morally right not to mention technically sound to inconvenience and anger the few to create positive downstream effects for the majority.If mailing list managers were also flogged then my opinion would shift right back in favor of the manager. Regardless, I feel gratitude for the work of ml managers but I’m sorry maybe the day has come to discuss making decisions for the community as a whole even if it inconveniences (granted not trivially).I had trouble sleeping so I hope my response holds up as being reasonable when I re read it in the morning. Thanks.NeilOn Mar 29, 2023, at 7:01 PM, Douglas Foster  wrote:If my cigarette smoke inconveniences 100 people on my plane flight, should I come prepared to go smokeless or should they come prepared with masks?    The mailing list problem is created by mailing list practices, and it is the mailing lists problem to solve the problem they created.We actually have an abundance of options for them 

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

[Douglas Foster]

The sad thing is that there is no need to do a bandage pull if evaluators
can learn how to serve the interests of their users properly.   I don't
throw away any mail based on Sender Authentication failure alone.   But I
also don't tolerate the idea that I have to accept malicious impersonation
in order to accept all of the mail that my users should receive.

In this group, I have been arguing a losing cause that DMARC authentication
can wisely be applied whether a DMARC policy exists or not.   After
discarding blacklisted message sources, here are my results from applying
DMARC-like rules to all of my mail:

61% are aligned with both SPF PASS and DKIM PASS
16% are aligned with SPF only
16% are aligned with DKIM only

93% aligned with DMARC-like logic
  4% are authenticated using local policy that allows non-standard
alignment or overrides a non-PASS SPF result.

97% of all FROM address are verified to my satisfaction

Clearly, I am within reach of 100% verification of the RFC5322.From domain.

I don't know that I receive any mailing list traffic, but this is how it
would fit into my model:
- Failure to verify causes the message to be flagged for review.
- Review indicates that the message is from a mailing list
- Research determines that the MLM provides reliable Sender Authentication
and best effort spam filtering, so I do not need to repeat sender
authentication
- I create a local policy that accepts any From domain when the SMTP and
Server information identify the mailing list.
- Mailing list messages are forwarded to content filtering for normal
acceptance processing.

So my "stream info" proposal is trying to solve the "research" entry on the
list above.

If the mailing list cannot be trusted to perform Sender Authentication,
then I need to implement code which parses the entire set of Received
headers, ARC headers, and possibly other headers.  I am probably not
willing put that processing burden on every message to solve a problem for
a poorly-managed listI will be easier to refuse the accommodation and
tell the user to join the list with a Google account.

So I think we need a document that tells evaluators how to "not be
stupid".I may be the only one present who can write it, and I could do
so if the scope is willing to move in that direction.

But as long as there are stupid evaluators, senders have to cope with the
reality in front of them.

Doug Foster



On Wed, Apr 5, 2023 at 4:14 AM Neil Anuskiewicz 
wrote:

> I’m with Doug on this one. The bandage should be pulled off quickly and
> sympathy expressed to those who miss backward compatibility. I wouldn’t say
> utilitarianism is the right frame but here why wouldn’t it be morally right
> not to mention technically sound to inconvenience and anger the few to
> create positive downstream effects for the majority.
>
> If mailing list managers were also flogged then my opinion would shift
> right back in favor of the manager. Regardless, I feel gratitude for the
> work of ml managers but I’m sorry maybe the day has come to discuss making
> decisions for the community as a whole even if it inconveniences (granted
> not trivially).
>
> I had trouble sleeping so I hope my response holds up as being reasonable
> when I re read it in the morning. Thanks.
>
> Neil
>
> On Mar 29, 2023, at 7:01 PM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
> 
> If my cigarette smoke inconveniences 100 people on my plane flight, should
> I come prepared to go smokeless or should they come prepared with masks?
> The mailing list problem is created by mailing list practices, and it is
> the mailing lists problem to solve the problem they created.
>
> We actually have an abundance of options for them right now:
>
>- Do not alter content.
>- Mung the From address
>- Use ARC to indicate that the list is forwarding and modifying
>traffic from someone else.
>- As part of the subscription process, require subscribers to get a
>filtering exception implemented for the list traffic.
>- Use test messages to determine whether a recipient domain blocks on
>p=reject, and do conditional munging for only those recipient domains that
>need it.
>
> In the case of this IETF list, probably zero participants need From
> munging, but IETF mungs everything from Comcast because they are unwilling
> to attempt conditional munging.   So Comcast should allow its domain to be
> impersonated so that IETF does not have to collect and use
> subscriber-specific information?
>
> For any mailing list trust system to work, the mailing list would have to
> be trustworthy.Most mailing lists should be able to require 100% SPF
> PASS on posts, as well as exact match between MailFrom domain and From
> domain, because posts should be individual contributions.   However, the
> testimony of knowledgeable people in this group is that most mailing lists
> cannot be bothered to enforce sender authentication at all.These lists
> aren't 

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

[Neil Anuskiewicz]

I’m with Doug on this one. The bandage should be pulled off quickly and sympathy expressed to those who miss backward compatibility. I wouldn’t say utilitarianism is the right frame but here why wouldn’t it be morally right not to mention technically sound to inconvenience and anger the few to create positive downstream effects for the majority.If mailing list managers were also flogged then my opinion would shift right back in favor of the manager. Regardless, I feel gratitude for the work of ml managers but I’m sorry maybe the day has come to discuss making decisions for the community as a whole even if it inconveniences (granted not trivially).I had trouble sleeping so I hope my response holds up as being reasonable when I re read it in the morning. Thanks.NeilOn Mar 29, 2023, at 7:01 PM, Douglas Foster  wrote:If my cigarette smoke inconveniences 100 people on my plane flight, should I come prepared to go smokeless or should they come prepared with masks?    The mailing list problem is created by mailing list practices, and it is the mailing lists problem to solve the problem they created.We actually have an abundance of options for them right now:Do not alter content.Mung the From addressUse ARC to indicate that the list is forwarding and modifying traffic from someone else.As part of the subscription process, require subscribers to get a filtering exception implemented for the list traffic.Use test messages to determine whether a recipient domain blocks on p=reject, and do conditional munging for only those recipient domains that need it.In the case of this IETF list, probably zero participants need From munging, but IETF mungs everything from Comcast because they are unwilling to attempt conditional munging.   So Comcast should allow its domain to be impersonated so that IETF does not have to collect and use subscriber-specific information?For any mailing list trust system to work, the mailing list would have to be trustworthy.    Most mailing lists should be able to require 100% SPF PASS on posts, as well as exact match between MailFrom domain and From domain, because posts should be individual contributions.   However, the testimony of knowledgeable people in this group is that most mailing lists cannot be bothered to enforce sender authentication at all.    These lists aren't protecting their subscribers from impersonation fraud, yet they are complaining that evaluators are suspecting them of forwarding impersonation fraud.  That is hypocrisy.Someone please explain to me why everyone should make themselves more vulnerable to ransomware and other attacks so that mailing lists can avoid being inconvenienced and avoid having secure operating practices.Doug FosterOn Wed, Mar 29, 2023 at 7:56 PM Barry Leiba  wrote:1. IETF has installed a very ugly workaround to the problem, rewriting the "from" header field.  It's absolutely a workaround, and not a proper solution.2. Without the workaround, the real pain is not that a message from Comcast posted to the list doesn't get to you (though that's true): the real pain is that if Valimail rejects (bounces) those messages, the Mailman software will eventually unsubscribe you -- YOU, not the Comcast user -- from the list for exceeding the bounce threshold.3. Even with the workaround, I see, as a list owner, several unsubscribe notifications a week due to excessive bounces.The damage to mail list operations is real, and expecting every mailing list manager to install an ugly workaround is not the right answer.  Telling those deploying DMARC what interoperability problems an inappropriate choice of p=reject causes, and telling them not to do that... is the right answer.And, as I said, when they decide that their needs are more important than those interoperability problems, they have that right, and at least they will now be making an informed decision.  The standard needs to say this.BarryOn Thu, Mar 30, 2023 at 6:41 AM Todd Herr 40valimail@dmarc.ietf.org> wrote:Colleagues,Can someone please point me to a mailing list server or other indirect mail flow that I might somehow engage with so that I can experience the pain of not having a message reach its destination when sent with a policy of p=reject?I post to various IETF mailing lists from my work address, and my employer, like Mr. Brotman's, publishes a DMARC record with p=reject. Thanks to the work of the folks who manage the IETF mailing list software, my participation in these discussions is not hindered in any way; I can post to lists, people can reply directly to me if they choose, and I can reply to the list and/or to the author of any post without any extra work on my part.This leaves me in a position where I do not appreciate how a DMARC policy of p=reject can harm interoperability, or perhaps better stated, I do not appreciate that it does harm interoperability. I understand that it can, because SPF can fail when mail transits intermediaries and DKIM can fail if the