Re: [dmarc-ietf] Jumping the Gun

[Jesse Thompson]

On Wed, Oct 25, 2023, at 4:06 PM, Todd Herr wrote:
> Someone posting at Security Boulevard has decreed that DMARCbis (at least the 
> t= tag parts of it) are now codified:
> 
> https://securityboulevard.com/2023/10/dmarc-t-tag-replaces-pct-in-dmarcbis/
> 
> This person did a fantastic job of cutting and pasting from DMARCbis to 
> "create" their "content".

It's a good summary IMO

Is it advisable to use "t=y pct=0" for backwards compatibility?

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

Re: [dmarc-ietf] Why Relaxed Alignment?

[Jesse Thompson]

Correct. ESPs need to process async bounces to help their customers adhere to 
best practices. The only way to do that (for a rfc5322.from domain which 
typically has MX pointed at a mailbox host) is to use a return path subdomain 
with MX pointed at the ESP.

Strict DKIM alignment would be easier to consider requiring since individual 
selectors can be delegated easily.

Jesse 

On Wed, Oct 18, 2023, at 3:45 PM, Neil Anuskiewicz wrote:
> 
> 
> 
>> On Oct 18, 2023, at 7:24 AM, Todd Herr 
>>  wrote:
>> 
>> On Tue, Oct 17, 2023 at 9:51 PM Douglas Foster 
>>  wrote:
>>> Why do we need to support relaxed alignment at all?
>>> 
>> 
>> A common use case for relaxed alignment is when an organization (e.g., 
>> WeSellStuff) employs a third party Email Service Provider (e.g., 
>> WeSendEmail) to send mail on the organization's behalf. In that case, we 
>> might have the following:
>> 
>> Return-Path domain: bounces.wesellstuff.com
>> DKIM signing domain: wesendemail.wesellstuff.com
>> RFC5322.From domain: marketing.wesellstuff.com
>> 
>> The above configuration allows for WeSendEmail to manage the SPF record for 
>> bounces.wesellstuff.com and for an MX record for bounces.wesellstuff.com to 
>> be pointed at WeSendEmail, so that they can handle bounce processing and 
>> other Delivery Status Notifications.
>> 
>> It also allows for WeSendEmail to DKIM sign on behalf of WeSellStuff using a 
>> dedicated subdomain that is delegated to WeSendEmail, which can publish the 
>> public key in DNS and generate the private key and keep it private to use 
>> for signing mail it sends. 
>> 
>> Meanwhile, WeSellStuff only has to delegate responsibility for those parts 
>> of the DNS that are specific to WeSendEmail's sending to WeSendEmail.
> 
> Yes, strict alignment would be *very* disruptive to a LOT of senders.
> ___
> 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] p=interoperability p=compliance p=orgname:policyname

[Jesse Thompson]

On Wed, Aug 23, 2023, at 11:11 AM, John Levine wrote:
> It appears that Jesse Thompson   said:
> >I'm beginning to think that a solution to this problem is "other channels"
> >
> >Let's discuss p=interoperability, p=compliance, or p=orgname:policyname
> 
> Please, no.  This WG has already run a year past its sell-by date.  Stuff
> like this will just tell the world that we'll never finish.

Apologies. I wasn't trying to disrupt dmarcbis finishing. Ever since I saw 
consensus start to form, I started citing dmarcbis whenever explaining how 
DMARC works (or should work) to people who need to know. Most are still relying 
on the original language/assumptions as the basis for their knowledge, so there 
are going to be questions to answer and operational practices to think about 
during the transition period (forever). Is there a better place to discuss 
future topics like this?

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

[dmarc-ietf] p=interoperability p=compliance p=orgname:policyname

[Jesse Thompson]

On Mon, Jul 24, 2023, at 1:03 PM, Neil Anuskiewicz wrote:
> 
> 
> > On Jul 19, 2023, at 3:21 PM, Douglas Foster 
> >  wrote:
> > 
> > 
> > Perhaps you can clarify what you think DMARC is.
> > 
> > Apparently a significant number of evaluators think that "DMARC Fail with 
> > p=reject always means unwanted mail".   Or to use Michael Hammer's 
> > language, "DMARC Fail with p=reject means the domain owner wants it 
> > rejected so I will reject it."These are exactly the attitudes that 
> > cause us so much trouble because (a) DMARC Fail with p=reject does not mean 
> > that rejection is always the correct response, and (b) DMARC Fail with 
> > p=none is an important piece of information.   
> 
> Doug, if what you’re saying is true then the root cause might be our fault. 
> If we’ve not communicated clearly enough DMARC’s purpose. A communication 
> problem likely needs to be solved with more and better communication via the 
> standards doc itself and other channels.
> 

(again, apologies if already suggested, still working my way through the 
backlog in my spare time)

I'm beginning to think that a solution to this problem is "other channels"

Let's discuss p=interoperability, p=compliance, or p=orgname:policyname

"By the book" receivers who see an "invalid" policy will treat it no 
differently than p=none, and intermediaries will not bother trying to munge. 
So, it is achieving the interoperability objectives of IETF

"Smart" receivers will see that the policy is a reference to a policy 
definition that can be queried in some standard fashion. The policy owner can 
articulate clearly what the policy means.

IETF should not be in the business of describing the mail handling policies 
that exist in practice or any that will emerge, but should define how those 
policies are communicated (for interoperability sake).

Domain owners interested in achieving compliance will gravitate towards 
p=compliance over p=reject (because compliance is what they are trying to 
achieve), or they may choose to define their own p=orgname:policyname namespace 
if they want to get more specific in describing their intended mail flows

Those that wish to express backwards compatibility can use p=interoperability 
or a p=orgname:policyname namespace that expresses policy in some other way

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

Re: [dmarc-ietf] Another p=reject text proposal

[Jesse Thompson]

On Sat, Aug 12, 2023, at 11:48 AM, John Levine wrote:
> It appears that Jesse Thompson   said:
> >> This of course requires that the recipient SMTP server can't simply
> >> reject the incoming email after the MAIL FROM because SPF checks do
> >> not match, they actually need to receive the email so they can check
> >> ARC and DKIM headers... 
> >
> >During my 19 year career we used software built by Ned Freed. It was 
> >perfectly capable of evaluating full content (as well as
> >integrating with 3rd party evaluation software) and return an appropriate 
> >SMTP response after DATA. Why is it still so difficult?
> 
> I am in yet another argument with a guy who is complaining that he's
> not getting forwarded mail, I point out that he's rejecting on SPF
> failure so that's not a bug, it's what he has told his system to do,
> and he insists it's my fault. For some reason this attitude is
> unusually common in mail systems in central Europe.

The guy presumably rejects based on SPF during MAIL FROM, right? Rejecting due 
to DMARC missing SPF alignment would need to wait until DKIM alignment and 
other factors are known would need to occur after DATA. Sounds like this could 
be spelled out as a best practice, if it isn't.


> To reiterate the obvious, you can't do DMARC without processing the
> entire message during the SMTP session at least enough to check the
> DKIM signatures. No sensible mail system rejects on SPF failure (other
> than bare -all for no mail), because the error rate is so huge.
> 
> A very long time ago people tried to minimize the work in the SMTP
> daemon because there were small fixed size connection tables and on
> systems without shared libraries, many copies of the daemon could
> cause a lot of swapping. These days the connection table never fills
> up, my SMTP daemon uses about 30 shared libraries, and my decade old
> server can handle 100 connections and barely notices the load. So,
> yeah, you can do it all in the SMTP daemon and in practice everyone
> does now.

I get that there is a lot of legacy code to support which will take forever to 
change. If it's a matter of requiring increased memory overhead (etc) to get 
the desired result of being able to consider complete context before issuing 
the most appropriate SMTP response after DATA, it is technically possible today 
and is in the receiver's best interest to invest in the additional cost of 
doing it. Another best practice? 

I suppose that if per-RCPT considerations are factored into the SMTP response 
after DATA, it implies that senders will be able to achieve the best 
interpretation of SMTP response messages by sending to a single recipient per 
transaction (which sounds like is needed for some of the potential 
implementations for the "identification of the RCPT TO" for fixing DKIM Replay)

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

Re: [dmarc-ietf] Another p=reject text proposal

[Jesse Thompson]

I'm woefully behind on this list. Apologies if these points have already been 
made.

On Wed, Jul 19, 2023, at 4:42 PM, Tero Kivinen wrote:
> Wei Chuang writes:
> > 2) The proposed language calls out "“alumni forwarders”, role-based email
> > aliases, and mailing lists" for consideration by receivers.  How should
> > receivers be aware that traffic failing authentication should be 
> > reconsidered?
> >   Mailing-lists sometimes uses RFC2919 List-id headers.  Can Section 5.8 [1]
> > call out more strongly the application of those List-id headers?  Can
> > something be done so that receivers can identify the other scenarios e.g.
> > role-based email aliases and alumni-forwarders?  
> 
> For alumni forwarders / role-based forwarders things are different, as
> users who set those up, actually knows who does the forwarding, and
> they themself recognize that emails coming to those addresses are
> important to them, and they also trust (university etc) the one doing
> forwarding.
> 
> So if the alumni forwarder / role-based forwarder adds ARC signatures,
> then the final recipient can whitelist that ARC signer in their setup
> and say that the policy code that checks the SPF/DKIM/DMARC results
> can fully trust the signed ARC authentication results from that
> signer.

As someone who provided mail services for a R1 research university for 19 
years...

Pretty much all universities have migrated to O365 or Gmail due to economic 
factors, which have tiered pricing for hosting legacy addresses that use the 
same domain as the active faculty/students. Researchers and grad students want 
their old address to remain active because it what they publish on papers, and 
they want the mail sent to their old address to follow them to their new 
academic institution(s) and employer(s) when they move on. Yes, the Alumni 
division also offers a different domain for alumni, hosted by admins who don't 
know much about email interoperability, but that is just another domain hosted 
on Gmail, so the forwarding problem is Gmail's so solve, as much as it is a 
problem for the university to solve for allowing forwarding for active/former 
faculty/students.


> This of course requires that the recipient SMTP server can't simply
> reject the incoming email after the MAIL FROM because SPF checks do
> not match, they actually need to receive the email so they can check
> ARC and DKIM headers... 

During my 19 year career we used software built by Ned Freed. It was perfectly 
capable of evaluating full content (as well as integrating with 3rd party 
evaluation software) and return an appropriate SMTP response after DATA. Why is 
it still so difficult?

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

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Jesse Thompson]

On Tue, Jul 11, 2023, at 7:49 PM, Wei Chuang wrote:
> Also can we do more to harden SPF?  The SPF upgrade attacks needs three 
> things:
>  • IPs shared by multiple sending domains
>  • Some sender uses those IPs that permits spam and phish traffic
>  • Those multiple sending domains have SPF policies that include those IPs

To the last item. We (as an ESP) only send with relaxed SPF alignment. Therefor 
our SPF include should [ideally] not be on the RFC5322.From domain (granted, I 
am working on revising some docs that still rely on PRA assumptions).

> Perhaps one way to harden to SPF for DMARC is to detect if the IPs are 
> shared.  The authenticator in addition to regular to SPF validation, might be 
> able to use reverse PTR lookup and match the SPF record domain name (or match 
> some subset like the org domain) to forward validate.  Only one domain can 
> claim ownership for the IPs and be allowed to SPF authenticate for DMARC.  

I think that with relaxed alignment it requires that a potential spoofer 
(through our service) to be able to produce an SPF aligned result that is a 
subdomain of the RFC5322.From domain (which I don't think is happening with the 
SPF upgrade attacks today, at least for us) and the spoofer would need to be 
able to know and use the same subdomain (which includes our SPF) that has a 
high reputation in your trust models. I do have concerns about penalizing 
shared IPs in general, since they are a necessity with IPv4.

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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Jesse Thompson]

On Sat, Aug 5, 2023, at 11:49 AM, Dave Crocker wrote:
> On 8/5/2023 9:30 AM, Jesse Thompson wrote:
> > Governance seems like the best word to me, since Governance is what 
> > Reporting has provided to ADs in Monitoring Mode, but I do not want to 
> > say DMARG out loud either :-)
> 
> Here, too, the domain owner does not govern the platform receiver.

I don't disagree with you. My point was that the reports, provided by the 
receivers, give to the security team the provisions they need to 
convince/coerce employees to adhere to their intended governance model, 
regardless of whether the receivers honor the governance model. i.e. Monitoring 
Mode is not an exercise done in a vacuum. The reason to monitor is to achieve 
local compliance; to govern your mail streams.

p=quarantine pct=0 (now in DMARCbis: t=y) is useful to determine the extent to 
which people are participating in mailing lists and to identify lists that are 
not compensating for the interoperability issues. Without t=y, the people in 
charge of governance may just assume [incorrectly] that one or the other 
situation is rare. Sadly, I think the t=y benefit will be overlooked, because 
S people don't really care if the organization's employees can't easily 
participate in mailing lists. They may hope/assume that receivers will honor 
the policy, so "testing" implies "governance objective not yet complete".

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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Jesse Thompson]

On Sun, Jul 23, 2023, at 4:38 PM, Neil Anuskiewicz wrote:
> > On Jun 30, 2023, at 11:33 AM, Dave Crocker  wrote:
> > > On 6/30/2023 11:22 AM, Todd Herr wrote:
> >> Why is the mechanism called "Domain-based Message Authentication, 
> >> Reporting, and Conformance" and not "Domain-based Message Authentication, 
> >> Reporting, and Disposition"?
> > 
> > Say DMARC out loud.  Now say DMARD out loud.
> 
> I like the way you think, Mr. Crocker. What a difference a letter makes. 
> Dmarc sounds important, serious. DMARD sounds like something a high college 
> friend might have made up to describe something stupid. 

It also phonetically sounds like an abbreviation of Demarcation, which make it, 
what, a double entendre?

Conformance has a synonym Compliance, which may be a reason why people in the 
ranks of Security and Compliance in "general purpose" Author Domains fixate on 
p=quarantine|reject as a rubric to assess their perceived security posture 
without any serious knowledge/consideration of the email interoperability 
issues, and then inevitably there's some kind of unsolvable security incident 
that convinces the CISO to say "damn the torpedoes".

Governance seems like the best word to me, since Governance is what Reporting 
has provided to ADs in Monitoring Mode, but I do not want to say DMARG out loud 
either :-)

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Jesse Thompson]

On Sat, Jun 10, 2023, at 12:50 AM, Barry Leiba wrote:
> Are there working group participants who can do this sort of
> evaluation, not just giving numbers but also analyzing why DKIM
> failures happened when they should not have?

As primarily an outbound ESP, we don't have access to relevant inbound logs, 
nor DMARC reports for customer domains, so our awareness of this issue is 
dependent on being told.

That said, at MAAWG we were made aware of an edge case which is resulting in 
DKIM failures. Presumably, unknown bugs like this are inflating the numbers to 
support the "pro keeping SPF in DMARC" argument.

I typically advise customers that DKIM (CNAMEs with managed rotation) is 
enough. But that's speaking as a sender that supports DKIM. I suppose that some 
senders still aren't willing to implement DKIM today.

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

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Jesse Thompson]

On Thu, Apr 27, 2023, at 9:54 PM, Scott Kitterman wrote:
> 
> 
> On April 28, 2023 2:49:48 AM UTC, Jesse Thompson  wrote:
> >On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote:
> >> On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote:
> >>> Also, state that serious consideration includes testing p=quarantine; 
> >>> pct=0^H t=y.
> >> 
> >> I was going to say something similar but I think that it is implied by 
> >> section A.7
> >
> >Actually, I like referencing A.7 here as a pointer.
> >
> >This achieves consensus on the rewrite objection. 
> >
> >A.7 describes the rewrite without condoning it:
> >
> >   Operational experience showed ...
> >   ... header rewriting by an
> >   intermediary meant that a Domain Owner's aggregate reports could
> >   reveal to the Domain Owner how much of its traffic was routing
> >   through intermediaries that don't rewrite the RFC5322.From header
> 
> I think we can describe what people are doing without placing a strong value 
> judgement on it, but I think we have to say we haven't assessed all the 
> associated interoperability impacts of it and at least mention that 5321 says 
> not to do it.

Restricting the "MUST NOT" to the context of 5321 achieves consensus, I think

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

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Jesse Thompson]

On Thu, Apr 27, 2023, at 9:52 PM, Scott Kitterman wrote:
> 
> 
> On April 28, 2023 2:25:57 AM UTC, Jesse Thompson  wrote:
> >On Thu, Apr 27, 2023, at 9:30 AM, Brotman, Alex wrote:
> >> Attempt to make it a tad more concise (I think), altering some of the 
> >> language:
> >> 
> >> -
> >> There can be inherent damage to the ability to use certain SMTP-based 
> >> systems in conjunction with a policy of quarantine or reject.  These could 
> >> include, though are not limited to, mailing lists, forwarding services, 
> >> and other types of indirect mail flows.  Especially in situations where 
> >> the sending domain is SPF-only, or the intermediary is known to alter 
> >> messages.  If the users of the domain may utilize these types of systems, 
> >> the domain administrator MUST NOT deploy a policy of quarantine or reject 
> >> without serious considerations to the impact to interoperability.  These 
> >> considerations will be informed by careful analysis of DMARC aggregate 
> >> reports prior to deploying such a policy.  Some third-party systems may be 
> >> willing to create a workaround for these situations, though it cannot be 
> >> guaranteed.  Domain owners MAY choose to create a sub-domain 
> >> (listmail.example.org) or cousin domain (listmail-example.org) which uses 
> >> a different policy for users wishing to utilize those service
> s.
> >> -
> >
> >I like this, and it gives room for best common practices to evolve that 
> >don't necessarily conflict.
> >
> >s/
> >Especially in situations where the sending domain is SPF-only, or the 
> > intermediary is known to alter messages.  If the users of the domain may 
> > utilize these types of systems, the domain administrator MUST NOT deploy
> >/
> >For situations where the sending domain is not DKIM signing all of its 
> > traffic in an aligned fashion or there is legitimate use of an intermediary 
> > known to alter messages, the domain administrator MUST NOT deploy
> >/x
> 
> I think most of this would be good in a non-normative appendix.  For my 
> immediate purpose, I'm imagining that in addition to the [adjective] domain, 
> there would need to be an amplification of [adjective] that would explain 
> exactly what we mean by [adjective] and what actions a domain owner might 
> take in order to be [not adjective].
> 
> I don't think it's formally part of the protocol, but it's quite important.

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

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Jesse Thompson]

On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote:
> On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote:
>> Also, state that serious consideration includes testing p=quarantine; 
>> pct=0^H t=y.
> 
> I was going to say something similar but I think that it is implied by 
> section A.7

Actually, I like referencing A.7 here as a pointer.

This achieves consensus on the rewrite objection. 

A.7 describes the rewrite without condoning it:

   Operational experience showed ...
   ... header rewriting by an
   intermediary meant that a Domain Owner's aggregate reports could
   reveal to the Domain Owner how much of its traffic was routing
   through intermediaries that don't rewrite the RFC5322.From header
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Jesse Thompson]

On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote:
> Also, state that serious consideration includes testing p=quarantine; pct=0^H 
> t=y.

I was going to say something similar but I think that it is implied by section 
A.7

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

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Jesse Thompson]

On Thu, Apr 27, 2023, at 9:30 AM, Brotman, Alex wrote:
> Attempt to make it a tad more concise (I think), altering some of the 
> language:
> 
> -
> There can be inherent damage to the ability to use certain SMTP-based systems 
> in conjunction with a policy of quarantine or reject.  These could include, 
> though are not limited to, mailing lists, forwarding services, and other 
> types of indirect mail flows.  Especially in situations where the sending 
> domain is SPF-only, or the intermediary is known to alter messages.  If the 
> users of the domain may utilize these types of systems, the domain 
> administrator MUST NOT deploy a policy of quarantine or reject without 
> serious considerations to the impact to interoperability.  These 
> considerations will be informed by careful analysis of DMARC aggregate 
> reports prior to deploying such a policy.  Some third-party systems may be 
> willing to create a workaround for these situations, though it cannot be 
> guaranteed.  Domain owners MAY choose to create a sub-domain 
> (listmail.example.org) or cousin domain (listmail-example.org) which uses a 
> different policy for users wishing to utilize those services.
> -

I like this, and it gives room for best common practices to evolve that don't 
necessarily conflict.

s/
Especially in situations where the sending domain is SPF-only, or the 
intermediary is known to alter messages.  If the users of the domain may 
utilize these types of systems, the domain administrator MUST NOT deploy
/
For situations where the sending domain is not DKIM signing all of its 
traffic in an aligned fashion or there is legitimate use of an intermediary 
known to alter messages, the domain administrator MUST NOT deploy
/x

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

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Jesse Thompson]

On Wed, Apr 26, 2023, at 5:47 PM, Scott Kitterman wrote:
> On April 26, 2023 9:39:08 PM UTC, Jesse Thompson  wrote:
> >On Wed, Apr 26, 2023, at 11:06 AM, John Levine wrote:
> >> It appears that Scott Kitterman   said:
> >> >>Domains owners who have users who individually request 3rd parties to 
> >> >>emit mail as an address within the domain MUST NOT publish a
> >> >restrictive DMARC policy if they wish to support their users' usage of 
> >> >any potential 3rd party. Examples of 3rd parties include
> >> >mailing lists and email service providers. These 3rd parties are not 
> >> >always aware of, or willing to work around, DMARC. Domain owners
> >> >implementing DMARC as a means for governance by restricting the 
> >> >unauthorized usage of the domain MUST be aware that not all of the
> >> >3rd parties will make changes to work around DMARC, resulting in 
> >> >interoperability issues for their users' usage of the 3rd parties.
> >> >Domain owners SHOULD provide an alternative address for these users 
> >> >within a cousin domain or subdomain that is not directly
> >> >associated with the organization's brand-associated domain that is used 
> >> >for marketing and transactional email that needs the security
> >> >benefits of DMARC. These users MUST use an address within a domain that 
> >> >does not have a restrictive DMARC policy.
> >> >>
> >> >>(Not a troll. Not directly aware of humming (sorry, it's on my bucket 
> >> >>list). Hopefully, didn't touch the 3rd rail. Honestly, in good
> >> >faith, representing the perspective of an extremely large domain owner, 
> >> >users within said policy-restricted domain, and as a 3rd
> >> >party commonly used by these, and similar, users.)
> >> > ...
> >> >I can see what you're attempting here and I see the logic.  I think the 
> >> >normative part would need to be about 90% shorter.
> >> 
> >> I was going to say the same thing.
> >
> >I agree it is too lengthy, but wished to convey the logic.
> >
> >
> >> 
> >> >I think it misses the impact on innocent bystanders.
> >> 
> >> It seems to me there are two somewhat different kinds of DMARC damange
> >> that we might separate. One is what happens on discussion lists, where
> >> messages get lost and in the process unrelated recipients get
> >> unsubscribed. The other is simple forwarding and send-to-a-friend
> >> which gets lost but is less likely to cause problems for the
> >> recipients beyond not getting the mail they want.
> >
> >I know you don't like talking about ESP concerns, but for the sake of 
> >fitting into the categorizations you state, I think that usage of ESPs falls 
> >into the send-to-a-friend category. Is there a better term than 
> >"send-to-a-friend" that is more aligned to the vast variety of use cases and 
> >types of customers that ESPs have grown to support? The term sounds a bit 
> >pejorative. Think about use cases like: digital receipts sent from point of 
> >sale systems via an ESP on behalf of small businesses who don't have the 
> >ability to delegate authorization to the entire domain (e.g. 
> >local-flower-s...@yahoo.com)
> >
> >And for the record, the ESP can either have unhappy customers due to 
> >rejected email, or they can do something like this (but not call it 
> >"rewriting") 
> >https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one
> >
> 
> I don't think the categorization is specific to ESPs.
> 
> Broadly, I think the failure modes are:
> 
> 1.  Starts authorized, breaks in transit (e.g. mailing lists)
> 
> 2.  Starts as unauthorized 3rd party and stays that way (e.g. send to a 
> friend)
> 
> I don't think there is anything ESP specific in the failure modes.

That assumes every mailing list authenticates its rfc5322.from authors and that 
every send-to-a-friend-er does not authenticate its rfc5322.from authors. This 
list does not. The send-to-a-friend-er I work for does. Maybe we don't want to 
trust the method the send-to-a-friend-er uses to authenticate its authors, and 
give a pass to the mailing list's method at the same time, but none of it 
matters since there's no way a mail receiving organization can determine if the 
message originated in an authorized context in either situation.

To be clear, I am not laying down on the tracks on the MUST NOT issue. Consider 
me "humming".

Yes, I'd prefer something less

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Jesse Thompson]

On Wed, Apr 26, 2023, at 6:21 AM, Scott Kitterman wrote:
> 
> 
> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely  wrote:
> >On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote:
> >> My recollection is that a general formulation that I proposed had at least
> >> some traction out of both groups:
> >> 
> >>> [some appropriate description] domains MUST NOT publish restrictive DMARC
> >>> policies due to interoperability issues
> >> 
> >> Leaving aside (for now) the question of what goes into [some appropriate
> >> description] and with the assumption that there will be some non-normative
> >> discussion to amplify whatever that is and probably give some indication 
> >> about
> >> what domains might do to not be one of those domains, is there anyone who 
> >> just
> >> can't live with that formulation of the situation?
> >
> >
> >Me, for one.  Because more than 98% of domains are going to fall into the 
> >description, however we word it, that statement makes the whole I-D 
> >nonsensical.  Cannot we just tell the problem without MUSTard?
> >
> >In any case, using the complement of [some appropriate description] is 
> >certainly easier.  For example:
> >
> >Forcing authentication into Internet mail by publishing restrictive DMARC
> >policies breaks some well established patterns of usage.  Publishing such
> >policies is thus RECOMMENDED only for domains [in this other appropriate
> >description].
> >
> Thanks.
> 
> I understand your objection to be that the proposed description of the 
> interoperability problems would apply to too many domains, regardless of the 
> modifier we might use.  Is that correct?

I have a similar concern. Any domain owner with size or complexity or users 
(who will do what they wanna do) will easily find their domain in a mixed-use 
state, and (ironically) the only management/governance tool at the domain 
owner's disposal to prevent future unintended use of the domain, in favor of 
subdomains, is to publish p=quarantine|reject (throwing the baby out with the 
bathwater)

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

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Jesse Thompson]

On Wed, Apr 26, 2023, at 11:06 AM, John Levine wrote:
> It appears that Scott Kitterman   said:
> >>Domains owners who have users who individually request 3rd parties to emit 
> >>mail as an address within the domain MUST NOT publish a
> >restrictive DMARC policy if they wish to support their users' usage of any 
> >potential 3rd party. Examples of 3rd parties include
> >mailing lists and email service providers. These 3rd parties are not always 
> >aware of, or willing to work around, DMARC. Domain owners
> >implementing DMARC as a means for governance by restricting the unauthorized 
> >usage of the domain MUST be aware that not all of the
> >3rd parties will make changes to work around DMARC, resulting in 
> >interoperability issues for their users' usage of the 3rd parties.
> >Domain owners SHOULD provide an alternative address for these users within a 
> >cousin domain or subdomain that is not directly
> >associated with the organization's brand-associated domain that is used for 
> >marketing and transactional email that needs the security
> >benefits of DMARC. These users MUST use an address within a domain that does 
> >not have a restrictive DMARC policy.
> >>
> >>(Not a troll. Not directly aware of humming (sorry, it's on my bucket 
> >>list). Hopefully, didn't touch the 3rd rail. Honestly, in good
> >faith, representing the perspective of an extremely large domain owner, 
> >users within said policy-restricted domain, and as a 3rd
> >party commonly used by these, and similar, users.)
> > ...
> >I can see what you're attempting here and I see the logic.  I think the 
> >normative part would need to be about 90% shorter.
> 
> I was going to say the same thing.

I agree it is too lengthy, but wished to convey the logic.


> 
> >I think it misses the impact on innocent bystanders.
> 
> It seems to me there are two somewhat different kinds of DMARC damange
> that we might separate. One is what happens on discussion lists, where
> messages get lost and in the process unrelated recipients get
> unsubscribed. The other is simple forwarding and send-to-a-friend
> which gets lost but is less likely to cause problems for the
> recipients beyond not getting the mail they want.

I know you don't like talking about ESP concerns, but for the sake of fitting 
into the categorizations you state, I think that usage of ESPs falls into the 
send-to-a-friend category. Is there a better term than "send-to-a-friend" that 
is more aligned to the vast variety of use cases and types of customers that 
ESPs have grown to support? The term sounds a bit pejorative. Think about use 
cases like: digital receipts sent from point of sale systems via an ESP on 
behalf of small businesses who don't have the ability to delegate authorization 
to the entire domain (e.g. local-flower-s...@yahoo.com)

And for the record, the ESP can either have unhappy customers due to rejected 
email, or they can do something like this (but not call it "rewriting") 
https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one

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

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Jesse Thompson]

On Tue, Apr 25, 2023, at 8:06 PM, John Levine wrote:
> It appears that Scott Kitterman   said:
> >My recollection is that a general formulation that I proposed had at least 
> >some traction out of both groups:
> >
> >> [some appropriate description] domains MUST NOT publish restrictive DMARC
> >> policies due to interoperability issues
> 
> This seems like a reasonable approach. As a purely practical point, I
> cannot imagine this document getting through the IESG without some
> clear guidance about DMARC's interop issues.
> 
> R's,
> John
> 
> PS: If anyone was going to suggest we just tell people how to change
> their mailing lists to work around DMARC, don't go there.

How about:

Domains owners who have users who individually request 3rd parties to emit mail 
as an address within the domain MUST NOT publish a restrictive DMARC policy if 
they wish to support their users' usage of any potential 3rd party. Examples of 
3rd parties include mailing lists and email service providers. These 3rd 
parties are not always aware of, or willing to work around, DMARC. Domain 
owners implementing DMARC as a means for governance by restricting the 
unauthorized usage of the domain MUST be aware that not all of the 3rd parties 
will make changes to work around DMARC, resulting in interoperability issues 
for their users' usage of the 3rd parties. Domain owners SHOULD provide an 
alternative address for these users within a cousin domain or subdomain that is 
not directly associated with the organization's brand-associated domain that is 
used for marketing and transactional email that needs the security benefits of 
DMARC. These users MUST use an address within a domain that does not have a 
restrictive DMARC policy.

(Not a troll. Not directly aware of humming (sorry, it's on my bucket list). 
Hopefully, didn't touch the 3rd rail. Honestly, in good faith, representing the 
perspective of an extremely large domain owner, users within said 
policy-restricted domain, and as a 3rd party commonly used by these, and 
similar, users.)

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

Re: [dmarc-ietf] Delegated authentication for Gmail

[Jesse Thompson]

On 4/22/2023 6:20 AM, Alessandro Vesely wrote:
> Those kinds of sender-side authorization schemes seem to be designed for 
> ESP-like businesses, where a domain owner delegates Domain2 to send messages 
> on its behalf.  Using such schemes for mailing lists, thereby going down to 
> per-user records sounds improper and bloats the amount of DNS stuff.
Does it bloat DNS more than DNSBLs do? Would it make more sense if it were done 
via HTTPS?

Here's what I see in the real world:
* Organization's policy dictates "use a subdomain" for non-general-purpose use 
cases. 
* Legacy non-general-purpose use of the org domain is tolerated because there 
is no easy migration path. 
* People within the organization instinctively want to use the org domain.
* They're very confused how it works technically, they try to pull strings to 
get what they want.
* Eventually a person high enough in the organization intervenes.
* So, the domain owner has no choice but to authorize the ESP to use the entire 
org domain, yet again.

Why is it improper for a domain owner to have an ability to delegate per-user? 
I understand that it may be technically infeasible, but why is it improper?

I'm still not certain why ESPs are fundamentally different than mailing lists.
ESP: A message author confirms their identity with the ESP and asks the ESP to 
emit mail with their rfc5322.From address
MLM: A message author confirms their identity with the MLM and asks the MLM to 
emit mail with their rfc5322.From address



> To address mailing list and forwarding for address portability, I'd rather 
> devise receiver-side schemes, whereby the final receiver acknowledges that 
> the email address of a user of its has been written to a file that produces 
> mailing list of forwarding effects, while the author domain is not involved 
> at all.  A very rough idea here:
> https://datatracker.ietf.org/doc/draft-vesely-email-agreement/

A scheme like this seems just as applicable to ESPs as it does mailing lists, 
insofar as mutual consensus of confirmed opt-in can be achieved between all 3 
parties.


> "Upon user confirmation, that MTA itself confirms the subscription to the 
> MLM."

Since you mentioned this enables address portability: If the user changes 
mailbox providers, how do they communicate all of their prior confirmed 
subscriptions to the MTA? How does the MLM know if the confirmed subscriptions 
have not been back-filled?

Jesse

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

Re: [dmarc-ietf] Delegated authentication for Gmail

[Jesse Thompson]

A DNS-based lookup, perhaps in the style of ATSP as this thread is describing, 
to query for not just domain-level authorization, but also potentially 
user-level authorization, I think is compelling because it can:

* Give domain owners a mechanism to achieve least-privilege authorization of 
3rd parties; limiting blast radius

* Enable delegated authorization of all sending streams within mixed-use 
domains; not just telling the mixed-use domain owners they are "doing things 
wrong" and they can't use DMARC as a result

* Make it clear to intermediaries that they do not need to reject or rewrite, 
assuming they know if the receiver understands they are authorized (but then 
again, they may not need to care either way, if they are still living in a 
mindset where DMARC doesn't exist)


On Fri, Apr 21, 2023, at 6:15 AM, Douglas Foster wrote:
> Thinking on this some more, there are some tricky design risks:

I appreciate the thoughts you have put on this topic. It may not be feasible, 
but I think it's worth exploring user-level authorization.


> If the user-to-domain delegation scheme exposes an email address to the 
> world, that information may be used for unwanted purposes, particularly 
> increased spam volumes.   Hashing provides part of that solution.   The ATSP 
> document solves this problem by using a mix of hash and cleartext domain 
> name, but we should not expose a cleartext username.

Perhaps a query to a domain-level salt would help limit rainbow tables 
reversing the hashed usernames. If it's only worth creating rainbow tables for 
mega-domains, which already have a saturated namespace, I assume the spammers 
see less value in knowing if any address within the namespace is valid.

Reversible hashed usernames do present an opportunity for domain owners to 
publish false ATSP records for spam trap purposes. win-win?

The privacy risk is less of a concern if the address is no-reply@. But the 
privacy risk is real for normal users authorizing mailing lists.


> Hash algorithms are intended to create enough collisions so that reversing 
> the hash is not practical, but the lookup process needs to ensure uniqueness 
> so that a delegation record does not create unauthorized secondary 
> delegations.

But domain-level delegation creates infinite user-level delegations today. I 
don't think this is worth obsessing about if people think domain-level 
delegation is secure enough.


> Similarly, the domain owner needs a way to clean up his DNS when an account 
> is terminated.   This includes removing delegations for the terminated 
> account without causing mistakes caused by hash collisions.   So some form of 
> tiebreaker will be needed to ensure uniqueness.

I was thinking the larger issue is that DNS administrators would have a hard 
time keeping track of which user address is associated with each hash. 
Especially if their DNS software/provider doesn't offer an internal 
comment/tagging capability. They'll have to maintain an internal lookup table.

What are the chances that because userA is authorized to use a mail-provider, 
that userB (who is a hash collision, whatever the long odds) begins to start 
using the same mail-provider, and then the DNS admin cleans up the userA 
authorization and accidentally breaks userB? It seems unlikely.


> Mitigation ideas:

> A user-to-domain delegation always uses plus addressing.  This increases 
> randomness of the hash process and adds complexity to hash-reversal attacks.  
>  It also simplifies privacy recovery if the plus address is compromised.

This seems challenging for the mailing list use case. I don't think most users 
have an easy way to send from a plussed address.


> The delegation record lookup uses a hash key based on the authorizing user 
> and the signing domain concatenated together, and a secondary key based on 
> the signing domain alone.   I don't know whether it will be better to look up 
> the signing domain using hash or cleartext.

I think rainbow tables could still be created based on common usernames and 
common signing domains. Why not require the domain owner to use and publish a 
salt instead? Or maybe both?


> To handle the hopefully rare case where a hash collision still occurs, the 
> domain owner creates multiple delegation records and assigns them a record 
> number which is used internally to associate a specific record with a 
> specific user account.

They would still need a lookup table of some sort.


> Doug
> 
> On Thu, Apr 20, 2023 at 6:24 PM Douglas Foster 
>  wrote:
>> Murray's ATSP proposal (https://www.ietf.org/rfc/rfc6541.txt) and Hector's 
>> DSAP proposal 
>> (https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00) have a 
>> similar goal:   Allow "Domain2" to send authenticated messages for "Domain1".
>> This is authorized when
>>  • the message is signed by "Domain2" and
>>  • a DNS entry in "Domain1" is configured to authorizes "Domain2" as a 
>> delegated signer.
>> (I will use RFC6541 as my 

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Jesse Thompson]

On Wed, Apr 19, 2023, at 12:35 PM, Alessandro Vesely wrote:
> On Wed 19/Apr/2023 15:37:25 +0200 Laura Atkins wrote:
> > To me it’s not so much the company can’t delegate authentication - it’s how 
> > many SaaS providers (some of which are ESPs and some of which are 3rd 
> > parties 
> > that send through ESPs) are incapable of supporting DMARC alignment. Not 
> > it’s 
> > hard, not it’s challenging, but simply … can’t. They cannot sign with 
> > foreign 
> > DKIM domains, and they cannot support different domains for SPF 
> > authentication.
> >
> > Should DMARCbis make the recommendation that if you are providing mail 
> > services 
> > that you SHOULD be able to support corporate customers using DMARC?
> 
> 
> IMHO at least an appendix should say that if you can't do anything better you 
> have to rewrite From: with examples of legitimate display-phrase, expanding a 
> bit the first bullet in Section 11.4.  That can also be a good place to 
> explain 
> the kind of damage DMARC causes.

That's what I'm getting at. I don't really see any difference between a mailing 
list and someone providing mail services (I won't use the word ESP since that 
seems to be a loaded term) for corporate customers (I would also add government 
customers, who are adhering to BOD 18-01 in droves and they are also adopting 
said companies providing mail services)

The choice for both the mailing list and mail-service company is to:

1) ignore DMARC and continue to emit mail as the original author intended (the 
author might be ignorant of DMARC too) and assume the mailbox providers are 
smart enough to understand that, like mailing lists, mail-service companies and 
their mail emitting authors shouldn't be caught up by a DMARC misdeployment by 
the domain owner

2) be cognisant of DMARC's effects, and in the interest of keeping the author's 
mail flowing, use a different domain and put the author's address in the 
friendly from or similar, or just refuse to accept the messages, until 
delegation can be set up.

I can say, anecdotally, that people really really want #1 to be true, but they 
eventually learn #2 leads to a better long term outcome. I'd like that 
"learning" to be less painful by having something unambiguous to point at in 
DMARCbis.

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

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Jesse Thompson]

On Mon, Apr 17, 2023, at 8:37 AM, Laura Atkins wrote:
> Should the IETF make the interoperability recommendation that SaaS providers 
> who send mail on behalf of companies support aligned authentication? That 
> means custom SPF domains and custom DKIM signatures. 
> 
> And if they can’t, then do we make a different recommendation regarding 
> spoofed mail that evades a company’s DMARC policy?

+1 to this question. It's entirely unclear to ESPs whether they're allowed to 
spoof a domain that has no DMARC policy. ESPs can furthermore conclude that 
Domain Owners who publish p=reject|quarantine are violating DMARCbis, and 
subsequentlly the domain's policy declaration is invalid, and can be ignored.

Jesse___
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] 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
> > <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 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 custome

Re: [dmarc-ietf] Signaling MLMs

[Jesse Thompson]

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.

Jesse___
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

[Jesse Thompson]

On Sat, Apr 8, 2023, at 8:17 PM, Mark Alley wrote:
> Personally, I prefer the latter of the two, quoted below.
> 
> "to preserve interoperability, domains SHOULD NOT publish p=reject unless 
> they are [not general purpose]* domains"
> 
> "Publishing DMARC records with restrictive policies does cause 
> interoperability problems for some normal email usage patterns. Potential 
> impacts MUST be considered before any domain publishes a restrictive policy."

I like the latter, as well. I was going to suggest something similar.

As Todd previously stated, my preference is for language that acknowledges the 
primacy of the domain owner over interoperability. CISOs have been sold 
(arguably, by the DMARC deployment companies' marketing) on the idea that there 
are security benefits. Maybe oversold, but there are benefits and the 
motivation will not change. Let's not also overlook the primary benefit of _the 
process of deploying DMARC_ gives to an organization: increased management and 
governance (enabled by the observability from the reports). In any case, the 
domain owner is motivated to deploy DMARC and gain the perceived benefits. If 
we are going to tell these motivated domain owners to MUST do something, at 
least make it something they might consider doing.

"Before a general purpose domain publishes p=reject|quarantine, the domain 
owner MUST emit mail from, or provide to their stakeholders/end-users, an 
alternative domain or subdomain with a p=none policy for any email that needs 
to traverse a non-DMARC-mitigating MLM or (more generally) from any 3rd party 
that cannot be authorized by SPF or DKIM alignment."

That, combined with Mark's language, I think would resonate with domain owners 
more than MUST NOT p=reject.

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

Re: [dmarc-ietf] AOL-compatible mailing lists

[Jesse Thompson]

On Sat, Apr 8, 2023, at 4:12 AM, Douglas Foster wrote:
> It is pretty clear how an AOL-compatible mailing list can be configured:
> 
>  • All messages come from the list domain
>  • Plus addressing is used to give each subscriber a unique From address..
>  • To be standards-compliant the plus address still needs to fit within the 
> 64-character limit, so the suffix is a code, not the full email address.  
> "John.Doe@subscriberdomain" is translated to "ListName+17@listdomain"
>  • The Friendly Name is used to identify the subscriber, his email address, 
> and optionally the list itself.  "John Doe John.Doe@subscriberdomain via 
> Listname"
>  • Reply-To is set to the list address
> This approach:
>  • Eliminates impersonation of other domains
>  • Eliminates subscriber specific message blocking based on
>• Subscriber domain has DMARC enforcement
>• Subscriber domain matches recipient domain
>• Subscriber domain is included in a geo-blocking rule
>  • Allows the list to be protected from impersonation using DMARC
>  • Allows list authentication to survive downstream forwarding.
> I suspect that this configuration is within the capabilities of existing 
> products, but maybe some software changes would be needed.
> 
> It becomes a simple choice:   Lists can adapt to operate the way AOL and 
> others want them to work, or they can keep to the old ways and live with the 
> consequences.When the old ways cause damage, I don't think the damage is 
> any longer a DMARC problem.   We should formally document how to implement a 
> DMARC-compatible mailing list, and then stop worrying about those who don't 
> want to be DMARC-compatible.
> 
> Doug Foster

I can say from experience, being responsible to retire and replace an aging EDU 
mailing list platform hosting thousands of lists, the choice was simple. The 
DMARC-incompatible options were immediately ruled out. 

An academic who happens to reside on a DMARC enabled domain should not have 
their thoughts quarantined or rejected. That would conflict with the mission of 
any university.

It's been a few years, but I just checked one of the old EDU email admin 
chatter, and it appears that even more of of them are moving towards DMARC 
policies, or at least talking about it more than I remember. This trend appears 
to be encouraged by the dominant MBP and a new bundled service from a major 
DMARC deployment company.

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?

[Jesse Thompson]

On Thu, Apr 6, 2023, at 11:43 AM, Murray S. Kucherawy wrote:
> 
> 
> On Sat, Apr 1, 2023 at 3:13 PM Jesse Thompson  wrote:
>> __
>> I just read https://datatracker.ietf.org/doc/rfc6541/ (or, re-read, I can't 
>> remember)
>> 
>> I'm struggling to understand how ATPS is significantly better than 
>> delegation via DKIM CNAME records. I can see that it's simpler for a domain 
>> owner because they need only set 1 ATPS record vs. sometimes 3 CNAME records 
>> (for key rotation). But that's not enough to justify adoption.
> 
> ATPS is Experimental.  I don't think it's a serious candidate for solving the 
> DMARC problem.  There's also a "conditional signatures" draft floating around 
> someplace.

I'm just spit balling experimental ideas, of course, under the assumption of my 
prior statement, which was something along the lines of: equipping domain 
owners with more fine-grained delegation capabilities would reduce the amount 
of p=reject breakage for perpetual mixed-use domains.


> To answer your question, ATPS was among other things a substitute for 
> delegation via CNAME when the author domain doesn't want to give some other 
> party the ability to generate its own signatures as the author domain.  There 
> was never, at the time it was written, a demand for doing this at a user 
> level.  Also, DKIM has never been tied to specific individual email addresses 
> because there's no reliable way for an external entity to verify that the 
> email address is even real, much less meaningful within the domain.  This was 
> ultimately why use of "i=" in the DKIM signature never really took off.

If my understanding is correct, the "i=" in the signature can be arbitrarily 
set by the signer, which already has delegated authority of the entire domain, 
so what's the purpose of setting it? That [lack of purpose] seems like a more 
likely reason it never took off (if I had to make a wild guess)

I don't think that particular usage of "i=" is an apt comparison to a domain 
owner delegating [via some DNS record] signing authority for a single address. 

The DNS entry could reference any 'non-real' address, of course... until it is 
seen in the rfc5322.from and the receiver finds the DNS entry, at which point 
it becomes as real as the domain owner intended it to be used by the signer for 
that purpose.

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

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] Solving DMARC damage with User quarantine and Steram-Info tag

[Jesse Thompson]

On Mon, Apr 3, 2023, at 8:30 PM, Douglas Foster wrote:
> I described my algorithm because I am surprised that some of these 
> sub-optimal filtering problems exist.

I would have thought the DKIM domain to be a better authenticated identifier 
than MailFrom domain; messages from ESPs are typically double-signed with DKIM 
(giving the evaluator the choice/multiple signals), but can have only one 
MailFrom and that can be either the ESP's domain or the customer's (depending 
on their ability to delegate via DNS). 

Let's not cast judgement. It's an issue of lack of mutual understanding.


> As a corollary:  In an American bar, the bouncer checks I.Ds. on the way in, 
> so that the bartender does not have to check IDs on every drink.  Similarly, 
> I assume that a major ESP has compelling business practices to ensure that 
> the From address on an outbound message matches the account used to domain 
> used to sign up for service.Therefore, I don't have to recheck identity 
> because the identity has been (or should have been) checked by the ESP.  I 
> have opted to delegate authentication trust to the ESP, until they betray me. 
>   We can't put that approach in an IETF standard, but we could put it into a 
> Best Practices document.   But I am surprised that we would need to do so.   
> I expect anyone that is trying to filter traffic correctly to come to a 
> similar conclusion, because the volume of unsigned mail from ESPs is 
> enormous.  You cannot justify blocking it all and you cannot investigate 
> every one.

A better analogy is if the bouncers were not employed by the same organization 
as the bartenders. What kind of contract between the bouncer firms and the bar 
owner is required?  


> Yes, for most ESP traffic, the ESP is in the MailFrom domain and passes SPF, 
> usually on against server with the same domain that passes fcDNS.   So ESP 
> identification is not a concern for me.   

I'm not seeing how you identify an ESP from not an ESP


> I only use DKIM to assess the From address.

Assuming you are talking about DMARC logic here. 

If the message isn't DKIM aligned or SPF aligned, yet came from an ESP, what do 
you conclude with your assessment?


> Your "intent" parameters and my "operating practices" seem to be pursuing the 
> same goal:  establishing trust by defining metrics that can be verified over 
> time.

++

Jesse


> 
> Doug
> 
> 
> 
> On Mon, Apr 3, 2023 at 7:00 PM Jesse Thompson  wrote:
>> __
>> On Sat, Apr 1, 2023, at 9:41 PM, Douglas Foster wrote:
>>> My approach to ESP traffic is simple.  I assume that the ESP has authorized 
>>> the account indicated by the From address, so I don't worry about Sender 
>>> Authentication as long as the message passes SPF based on the ESP domain.   
>>> DMARC is about identity verification, and I am counting on the ESP to 
>>> ensure that identity verification.
>> 
>> What you're describing looks like a black box (e.g. should I assume that you 
>> don't use DKIM, only SPF, to identify the ESP?).
>> 
>> So, you might resolve the identity to the message's author (despite there 
>> being no authentication mechanism to do so), or you might not. And every 
>> other receiver has their own logic (if any).
>> 
>> 
>>> ESPs develop a reputation with me based on their ability to vet their 
>>> clients appropriately.   
>> 
>> Do we need a set of best practices for ESPs to appropriately vet clients 
>> before emitting email that otherwise carries no authenticated identifier 
>> aligned to the rfc5322.From? 
>> 
>> Are we conflating "predicting whether their intentions are good and will not 
>> stray" with "verifying they are otherwise capable of sending authenticated 
>> mail from the address"? I'm not sure it's fair to insist that trust is a 
>> prerequisite just for communicating authenticated identifiers. The ESP (or 
>> intermediary) mostly needs to know if sending unaligned email is going to 
>> cause a problem; not that they are trying to absolve itself from other 
>> problems.
>> 
>> 
>>> (Right now my biggest spam problem comes from Gmail.com accounts that are 
>>> verifiably identified but being misused.   Identity verification is not the 
>>> solution to all spam problems, it is just the one that is easiest to 
>>> address with standards.)
>> 
>> The abuse might be coming via Gmail's authenticated identifiers, or it might 
>> be coming from an ESP's authenticated identifiers. It's still the same 
>> spammer (or compromised account) in both cases. Why would we not want a 
>> standard that can attribute the abuse to the gmail.com identity? Just 

Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag

[Jesse Thompson]

On Sat, Apr 1, 2023, at 9:41 PM, Douglas Foster wrote:
> My approach to ESP traffic is simple.  I assume that the ESP has authorized 
> the account indicated by the From address, so I don't worry about Sender 
> Authentication as long as the message passes SPF based on the ESP domain.   
> DMARC is about identity verification, and I am counting on the ESP to ensure 
> that identity verification.

What you're describing looks like a black box (e.g. should I assume that you 
don't use DKIM, only SPF, to identify the ESP?). 

So, you might resolve the identity to the message's author (despite there being 
no authentication mechanism to do so), or you might not. And every other 
receiver has their own logic (if any).


> ESPs develop a reputation with me based on their ability to vet their clients 
> appropriately.   

Do we need a set of best practices for ESPs to appropriately vet clients before 
emitting email that otherwise carries no authenticated identifier aligned to 
the rfc5322.From? 

Are we conflating "predicting whether their intentions are good and will not 
stray" with "verifying they are otherwise capable of sending authenticated mail 
from the address"? I'm not sure it's fair to insist that trust is a 
prerequisite just for communicating authenticated identifiers. The ESP (or 
intermediary) mostly needs to know if sending unaligned email is going to cause 
a problem; not that they are trying to absolve itself from other problems.


> (Right now my biggest spam problem comes from Gmail.com accounts that are 
> verifiably identified but being misused.   Identity verification is not the 
> solution to all spam problems, it is just the one that is easiest to address 
> with standards.)

The abuse might be coming via Gmail's authenticated identifiers, or it might be 
coming from an ESP's authenticated identifiers. It's still the same spammer (or 
compromised account) in both cases. Why would we not want a standard that can 
attribute the abuse to the gmail.com identity? Just because the domain is used 
by normal users?


> On the specifics of  your proposal, I am unclear what types of "intent" you 
> would put into a client profile.

Something along the lines of: This is the rfc5322.from, verified by X, expected 
volume/patterns, expected nature/category(ies) of content, recipients are 
confirmed opt-in, supported feedback mechanisms, has one-click-unsubscribe, 
etc. Basically all of the things that are discussed when giving deliverability 
guidance to someone building a new email program, but more tangible and useful 
for all parties.

But it might depend on the use case. Such as indirect mail, which is what 
you're getting at with Stream-Info, I think.

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

Re: [dmarc-ietf] Namespace delegation limits

[Jesse Thompson]

On Sun, Apr 2, 2023, at 9:25 AM, Jim Fenton wrote:
> On 2 Apr 2023, at 4:19, Douglas Foster wrote:
> 
> > Jesse observed that ESPs sometimes have difficulty getting a delegated DKIM
> > scope, because it delegates authority an entire namespace:
> >
> > With an assist from the DKIM group, we could specify that a DKIM signature
> > without a "d=" term is valid.   The "i=" term would have to be a full email
> > address and the key lookup would be done by parsing the domain portion of
> > the "i=" term.   Then the DKIM signature becomes valid for DMARC only when
> > the entire "i=" address matches the full RFC5322.From address.
> 
> Regardless of whether that’s a good idea, that would be an enormous change in 
> the way DKIM works and would not happen given the scale of existing 
> deployment.

I was discussing implementing using an ATPS lookup, not changing DKIM


> Besides, what’s the difference between this and just including the From 
> address in the DKIM signature?

It's not about whether the address can be authenticated. It's about whether the 
delegated DKIM signer should be able to have signing authority of the entire 
address space when the domain owner has a least-privilege approach to security 
matters.


> I think what you are looking for is a way to delegate a key that is valid for 
> only a specific address, rather than the whole domain. 

Or valid for multiple addresses, yes. I'm thinking: change ATPS to include the 
hashed local-part of the 5322.From when constructing the "._atps." DNS query. 

.._atps.

The signer only needs a single key (for their own domain, no need for DKIM DNS 
delegation) and the domain owner only needs to publish a TXT record for each of 
the localparts within the rfc5322.From domain they choose to delegate to the 
signer's domain.

Otherwise, as I mentioned, I don't see what ATPS brings to the table which 
isn't already possible with DKIM via CNAME record delegation.


> Why not just create a subdomain for the ESP to use like marketing.example.com 
> and publish keys there?

I think I said that. That is ideal.

In the world of enterprise IT, starting a suggestion with "why not just..." is 
good way to learn how complex an organization really is (after the sarcastic 
griping). Sometimes organizations insist on using their organization domain for 
mixed-use purposes, or have been doing so for a long time and don't want to 
change, people pull rank and refuse to change, the person who can make the 
change is long gone, some legacy monolith needs to be upgraded first, or 
whatever happens inside a complex organization. The domain owners (email/dns 
administrators) aren't going to it find very helpful to point at the RFC where 
it says "MUST NOT do the thing that we and our peers have been doing and things 
seem ok anyway". 

The discussion has been circling around this idea that domain owners are doing 
a wrong/naive thing by publishing p=reject on their mixed-use domains. But they 
are doing it anyway. Don't real-world implementations carry weight? Why are 
they doing it? They are doing it because they think they value the perceived 
security benefit. People who value security value least-privileged delegation 
of authority. 

If such a mechanism existed, the domain owner might choose to use it to 
delegate the ability for random employees to use the few remaining 
non-rewriting mailing lists without having to sacrifice the perceived security 
benefits for their entire domain/user-base.

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

Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag

[Jesse Thompson]

On Sat, Apr 1, 2023, at 8:04 AM, Douglas Foster wrote:
> For purposes of the following discussion, assume that messages from known-bad 
> senders and messages with unacceptable content have already been blocked.  
> The question at hand is how to handle Sender Authentication failure when a 
> message has no other objectionable characteristics.
> 
> There are three possible states for a message that is unauthenticated but 
> otherwise unobjectionable:
> 
> 1) Authorized by domain owner but not verifiable due to configuration errors 
> or omissions by the sender.
> 
> 2) Authorized (implicitly or explicitly) by a single domain member, or sent 
> for their benefit.   Inherently not verifiable with domain-level validation.  
> Mailing List messages are one example in this category.
> 
> 3) Not authorized by anyone and therefore illegitimate.
> 
> This framework applies to any unauthenticated message, including DMARC FAIL 
> or NO POLICY, as well as SPF FAIL, SOFTFAIL, PERMERROR, NEUTRAL or NOPOLICY.
> 
> Category 1 and 2 are (by assumption) legitimate messages, but without 
> authentication they are indistinguishable from Category 3 illegitimate 
> messages.
> 
> A DMARC policy of p=reject says that there will be no Category 1 messages.   
> Even when true, it does not resolve the ambiguity between Category 2 and 
> Category 3.  The only way to resolve ambiguity is with more information.  One 
> important aspect of this question is whether the user wants the message.
> 
> I have two approaches for handling these unauthenticated messages.  
> - Relaxed mode:  Deliver the message to the user, then perform an in-depth 
> review after the fact.
> - Strict mode:  Deliver the message to system quarantine, then review before 
> releasing to the user.
> 
> System quarantine is used because:
> - I understand how to view and interpret the message headers.
> - The quarantine review tool can present the message in a safe-mode view
> - My user-mode quarantine review tools do not provide the user with enough 
> information to make an intelligent decision.
> 
> This approach works well for me, but it does not work for Big Tech because it 
> requires too much labor.   Instead, the work needs to be distributed by 
> sending "Strict Mode" messages to user quarantine.   This requires a creation 
> of user quarantine wizards that help the user make an intelligent decision 
> and automate the creation of disposition rules to affect future messages.
> 
> With any review, the goal is to characterize a message stream of which the 
> current message is an example.   In some cases, it may be unclear how to 
> convert individually approved messages into a message stream definition.   
> Big Tech is likely to be pretty good at this, but their inference engines 
> could be assisted by information provided from the message source, using a 
> URI header like this

I have been thinking lately of an intent-based model that seems similar to what 
you describe. What I am referring to as intents are what you are referring to 
as operating policies.

The customer of an ESP (the author) wants to do X, Y, Z. That is their intent, 
expressed in good faith. Presumably. The ESP offers guidance on deliverability 
practices to help the customer be successful with their objectives. A common 
agreement between the customer and the ESP can be established. The ESP wants to 
enable the customer to do what they stated, but cannot guarantee that the 
customer might stray from their intent or be lying. What actually happens in 
practice can be validated. Stray from intent can be measured. In theory.

Ultimately, the ISP decides whether to trust the mail. Currently, the customer 
needs to warm up their reputation because the ISP has no idea who the customer 
is and what their intent is. They are protecting themselves from the risk that 
the customer might suddenly stray from their predictable flow of harmless mail. 
If the customer does something the ISP does not like, the ISP might decide to 
block the ESP's shared IP space, affecting other customers of the ESP (causing 
those other customers to seek solace on the ever-depleting IPv4 dedicated IP 
address space)

So, I was thinking of a mechanism where the customer (indexed by their 
authenticated identifier) could publish their intent, the ESP can publish what 
it thinks the customer's intent is, and maybe also publish its measurement 
about the customer's adherence to/deviance from their stated intent (which I 
acknowledge is a potential privacy issue). The ISP can do their own 
measurements of the inbound mail against the intents that have been published, 
and make a determination based on that.

Ideally, this transparent model would reduce the need for the ISP to punish the 
ESP for assuming [incorrectly] the good faith (or adherence to best practices) 
of a customer, while also giving the ISP information it needs to react quickly 
when bad things happen. Customers may rely less on warming up their 

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

[Jesse Thompson]

I'm looking at this through the lens of formerly being a domain owner for a 
complex organization doing a successful DMARC deployment which ended at 
p=quarantine for the organization domain primarily housing user-generated 
email. A subdomain strategy is employed for most other non-user generated mail. 
I have not worked there for 2+ years.

I now work for a much much larger organization which has the same 
organizational complexities, but much much more complex. It also houses user 
traffic on the organization domain, and it's more mixed-use. It is also at 
p=quarantine currently. 

My organization also happens to be a large ESP (and as of a few months ago my 
primary hat is as a sender). Often, it is the authors within a domain who are 
the primary customer instead of the domain owner; DNS records are sometimes 
hard to get in place, sometimes impossible. Other times it is the domain owner 
who is the primary customer and they express a need to govern the use of our 
ESP (and every other ESP) being used by authors within their domains. We also 
happen to be in the receiver role for many of our customers, and sometimes 
received mail needs to be emitted back outbound. 

I wanted to jump in on this thread at some point to stick my foot in my mouth. 
I'm not sure which hat I'm wearing. All opinions expressed are my own.

On Fri, Mar 31, 2023, at 10:49 AM, Hector Santos wrote:
> 
> On 3/29/2023 9:16 PM, John Levine wrote:
> > It appears that Murray S. Kucherawy   said:
> >>
> >> This is laid out in RFC 6377, Section 5.2, if it would be helpful to have
> >> something published to reference.  Indeed, ADSP threatened the same damage
> >> that DMARC "p=reject" causes, which I think was one of the reasons it never
> >> got adopted.
> > It wasn't just a threat -- someone got bounced off an IETF list shortly
> > after the ADSP draft came out when some eager beaver implemented it.
> >
> 
> I was the one who first reported the problem of what will happen when 
> the SSP (DKIM Policy) was split from DKIM.  I was able to show this 
> when the IETF was not yet supporting DKIM.
> 
> With the split, DKIM became DKIM-BASE and SSP became ADSP with all the 
> 3rd party (re)signer concepts from SSP removed.   It went from SSP 
> policy which considered 3rd party signers:
> 
> o=?  WEAK (signature optional, no third party)
> o=~  NEUTRAL (signature optional, 3rd party allowed)
> o=-  STRONG  (signature required, 3rd party allowed)
> o=!  EXCLUSIVE (signature required, no 3rd party)
> o=.  NEVER  (no mail expected)
> o=^  USER
> 
> to a very limited 1st party only policy.
> 
> DKIM=DISCARDalways expect to be signed by the Author Domain
> DKIM=ALL  always expect to be signed but by who?
> 
> The only flexibility was DKIM=ALL.   We presumed it could allow for a 
> 3rd party signer and it would be useful by mailing list servers. 
> Unfortunately, we could not resolve how to authorize the 3rd party 
> signers and ATPS was said not to scale.
> 
> So in my view, its not ADSP, DMARC as the problem -- its a lack of a 
> 3rd Party Authorization model in the protocol.
> 
> I see more domains are being "dmarca-tized" without their domain owner 
> knowledge of what the hosting system is doing nor how the MDA hosting 
> will handle mail.   This is causing major problems that requires 
> drastic mail handling actions.
> 
> I now have forwarding mail logic that determine the sender's DMARC 
> policy.   If weak or none it can be forwarded. If strong, it stays for 
> mail pickup.
> 
> I long had mailing list subscripting logic to stop a subscriber with a 
> strong DMARC policy.
> 
> I will probably begin to add a From Rewrite but I would prefer if the 
> DMARC record has a domain authorization to do so, with perhaps a 
> `-rewrite` tag to signify any form of rewriting allowed.
> 
> I think we need to focus more on DMARC having extended tags that 
> address many of the issues and ideas we have encountered. Receivers 
> want to honor the author domain wishes for handling failure when 
> various parts fail to meet their protocol-defined expectations.  But 
> if honoring going to cause more problems, then we either abandon DMARC 
> like we did with ADSP or we add 3rd party domain considerations.
> 
> Reject domain polices should support these ideas for handling outbound 
> and inbound mail handling.
> 
> -p=reject -rewrite -atps
> 
> -rewrite
> 
> says if the first initiate signer succeeded and you need to resign, 
> then you are allowed to rewrite the ADID.  This handles list 
> distribution problems.If a domain does not have -rewrite, a 
> subscriber and list submission MUST be denied.

-rewrite would send a clear signal to the intermediary that the domain owner 
wishes for mail to be handled the same way most intermediaries have already 
been doing for p=reject|quarantine domains that do not have -rewrite. I don't 
think this adds much value for domains that are already p=reject, and it would 
cause 

Re: [dmarc-ietf] Treewalk causing changes

[Jesse Thompson]

On 3/1/2023 6:12 AM, Douglas Foster wrote:

> A sub-issue to consider:   Should we do a Tree Walk on the authenticating 
> domain?
> For example, assume that "virgina.gov " and 
> "dmas.virginia.gov " both have DMARC policies with 
> relaxed alignment.   Should "dmas.virginia.gov " be 
> prohibited from authenticating "virginia.gov "?
> My gut says yes, but it adds some overhead to enforce that rule.

My gut says that might break ESPs who are using subdomains for SPF relaxed 
alignment. Unless you are saying that it's safe for treewalk changes to break 
MAILFROM=bounces.dmas.virginia.gov rfc5322.From=virginia.gov, then maybe there 
is some data to suggest that it is rare.

Dare I suggest that virginia.gov be able to define the subdomains to which SPF 
relaxed alignment should apply? As a domain owner, I might be inclined to 
reserve something like bounces.virginia.gov for all MAIL FROM sub-sub-domains 
that are used for delegating ESP traffic and manage it similar to DKIM 
selectors. aspf=s for any subdomains that aren't otherwise defined.

In my experience talking to state governments (as well as reflecting back on my 
own time in state government), domain owners are seeing a lot of ESP usage 
sprawl among their sub-domains/agencies/departments and they are frustrated 
that they can't manage or govern it effectively. In this late stage of the 
game, they won't be able to publish aspf=s to keep agencies from delegating ESP 
usage of virginia.gov when the domain owner would otherwise not want them to.

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

Re: [dmarc-ietf] Minutes from IETF 112

[Jesse Thompson]

On 11/18/2021 1:44 PM, John Levine wrote:
> It appears that Todd Herr   said:
>> It seems to me that DMARC already provides the ability for
>> security.example.edu to ensure that no other part of example.edu can send
>> mail on their behalf. To accomplish this, security.example.edu can today:
>>
>>   - Publish an SPF record listing only hosts under its direct control, a
>>   record which ends with "-all"
>>   - Ensure that only hosts under its control can DKIM sign messages using "
>>   security.example.edu" as the signing domain, by making sure that its
>>   private DKIM signing key is only deployed to hosts under its control
>>   - Publish a DMARC policy record that includes the following three tags
>>   and values:
>>  - p=reject
>>  - adkim=s
>>  - aspf=s
> 
> Agreed.  That would work fine.
> 
> An sp=reject in both security.example.edu and its org domain would also be a 
> good idea.

(Sorry, AWOL due to new employment, only tertiary involved in matters relevant 
to this discussion these days. Also haven't read this list for about a year.) 

Here's my best recollection of the issue:

p=(quarantine|reject) isn't the real issue for example.edu; just tell 
departments to use their sub.example.edu domains (localized control/branding 
makes people happy, more or less.) [1]  p=(quarantine|reject) for 
sub.example.edu isn't really an issue either; just a microcosm.

The problem is when there are departments with lots of systems all sending from 
hostname.sub.example.edu. So, sub.example.edu needs time to reconcile (or 
doesn't care to), wants to publish sp=none for sub.example.edu; but can't 
because the org domain's sp policy is the only one that matters, since there is 
no tree walk from hostname.sub.example.edu to sub.example.edu. Meanwhile, 
example.edu can't move beyond sp=none.

Also, the lack of control down the tree means that example.edu would never be 
able to use aspf=r, which is restricting a useful feature from organizations 
that could probably benefit the most from the flexibility it provides. I don't 
think that inability to use adkim=r is as much of an issue since individual 
CNAME records are easy to create under example.edu. This if off topic in my 
mind, but it was mentioned above.

Jesse

[1] most complex institutions probably aren't so willing to hand out subdomains 
like candy


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

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

[Jesse Thompson]

On 12/11/20 7:48 AM, Alessandro Vesely wrote:
> On Thu 10/Dec/2020 17:59:54 +0100 Jesse Thompson wrote:
>> On 12/9/20 10:28 PM, seth wrote:
>>> As an individual, I feel extremely strongly that failure reports should go 
>>> away in their entirety. Although Jesse Thompson has outlined a use case 
>>> that really has no other good solution, and is equally true in other large 
>>> complicated organizations.
>>
>> To be clear, I'm not advocating for this From/To use case, but I know of 
>> universities who would.  There's at least one who cleverly flattened their 
>> SPF record to include every known sender specifically because they had no 
>> mission to change the way their institution distributively sends email.  
>> That is the type of organization who *may* want From/To data, assuming they 
>> want to do more validation before adding yet another IP to their SPF.  It's 
>> a stretch in my mind.
> 
> 
> I'm not clear whether you're talking about sending or receiving reports.  
> Received: chains are key for evaluating addresses to add to SPF records.  I 
> don't think it makes sense to specify their omission from 

Only the last hop from the receiver's viewpoint is really needed for a domain 
owner to assess gaps in SPF.  That's already addressed with aggregate reports.  
What's missing is the additional context that the failure reports are intended 
to provide, to help domain owners determine if the IP address which sent the 
message was legitimate.  Of course, received chains are helpful for 
troubleshooting.  There's no "right" answer regarding the balance of useful 
information vs privacy, so I'm suggesting that we put things like this on a 
spectrum of usefulness/privacy-concerning. 


> My guess at why an organization may want to send only From/To rather than a 
> possibly redacted text/rfc822-headers are as follows:
> 
> * It is too hard for them to asses the risk of including unknown header 
> fields, yet they must do it before enabling ruf,
> 
> * the software they use doesn't have an option to redact PII, or (unlikely)
> 
> * they try to save bandwidth and disk space by reducing that ghastly pile of 
> freaky fields that infest message headers these days.

If sending only a limited amount of information is considered an acceptable 
alternative to full/unredacted information, it might help encourage these 
organizations to send failure reports, perhaps?


>> I would only strongly advocate for seeing the unredacted From header, since 
>> my primary concern was with identifying a little bit more information about 
>> who was using the domain and why (i.e. who is using random ESP).
> 
> 
> Agreed.
> 
> 
>> The stated purpose of Failure Reports is "for quickly notifying the Domain 
>> Owners when there is an authentication failure ... also provide more 
>> information about the failed message than is available in an aggregate 
>> report".  Since the focus of DMARC is to authorize the use of the domain 
>> used in the From header, then the logical next incremental levels of "more 
>> information" should be:
>>
>> 1) From header domain (already known)
>> 2) local part of From address
>> 3) Friendly From
>> 4) Subject
>> 5) other parts of the message containing identifiable information
>>
>> 1->5 decreases in usefulness/relevancy to DMARC
>> 1->5 increases in unnecessary information disclosure
> 
> 
> The mail filter I do sends aggregate reports but not failure reports.  Should 
> I add it?  I'm thinking I could frame it like so:
> 
> * Have a global flag to enable or disable ruf's, which can be overridden on a 
> per-domain basis.  Default to disabled.
> 
> * The flag can specify three confidentiality levels:
>   - full message
>   - header only
>   - header only + redact.
> 
> * Redacting the header would work as follows:
>   1. Collect recipients addresses in To:, Cc:, and envelope,
>   2. compute the rfc6590-redacted version of each address,
>   3. for all fields, replace any occurrence with the redacted version.
> 
> * Reports are left in a user-configured directory, assuming that a user 
> supplied script deals with them.
> 
> Does that make sense?
> 
> Should dmarc-failure-reporting include text with practical suggestions along 
> those lines?

Does this redaction logic apply to the From header too?  If so, I would 
recommend adding a fourth confidentiality flag for reporters who want to redact 
recipient information but leave the From header unredacted to better aid the 
domain owner in tracking down the sender.

Jesse

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

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

[Jesse Thompson]

On 12/9/20 10:28 PM, seth=40valimail@dmarc.ietf.org wrote:
> As an individual, I feel extremely strongly that failure reports should go 
> away in their entirety. Although Jesse Thompson has outlined a use case that 
> really has no other good solution, and is equally true in other large 
> complicated organizations. However, this problem is mitigated with a tree 
> walk, where you can get the reports to the appropriately localized part of 
> the organization (like, math.wisc.edu <http://math.wisc.edu>, instead of to 
> Jesse at wisc.edu <http://wisc.edu> who'd need to hunt things down).

To be clear, I'm not advocating for this From/To use case, but I know of 
universities who would.  There's at least one who cleverly flattened their SPF 
record to include every known sender specifically because they had no mission 
to change the way their institution distributively sends email.  That is the 
type of organization who *may* want From/To data, assuming they want to do more 
validation before adding yet another IP to their SPF.  It's a stretch in my 
mind.

I would only strongly advocate for seeing the unredacted From header, since my 
primary concern was with identifying a little bit more information about who 
was using the domain and why (i.e. who is using random ESP). 

The stated purpose of Failure Reports is "for quickly notifying the Domain 
Owners when there is an authentication failure ... also provide more 
information about the failed message than is available in an aggregate report". 
 Since the focus of DMARC is to authorize the use of the domain used in the 
From header, then the logical next incremental levels of "more information" 
should be:

1) From header domain (already known)
2) local part of From address
3) Friendly From
4) Subject
5) other parts of the message containing identifiable information

1->5 decreases in usefulness/relevancy to DMARC
1->5 increases in unnecessary information disclosure

Jesse

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

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

[Jesse Thompson]

On 12/9/20 6:12 PM, Brandon Long wrote:
> At best, we considered allowing RUF reports for cases where the dmarc domain 
> was the receiver, ie if someone had a message that failed dmarc while sending 
> to the same domain, then presumably the domain admin already has the power to 
> view the message.
> 
> But, if you limit it to that level, then the domain admin could already 
> theoretically do this themselves by having those messages delivered to some 
> destination to look at them, or setting
> up their own forwarding rule to their dmarc analysts.

I agree with this.  With senders that have a relatively large volume, there is 
a very high probability that at least one of the recipients is local.  Most of 
the necessary information is probably already available in logs.

Jesse

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

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

[Jesse Thompson]

On 12/9/20 11:07 AM, Alessandro Vesely wrote:
> We would like to close this ticket by Dec 23, two weeks from now, so please 
> get on it.
> 
> The ticket text is:
> 
>     It has been asked for a new report type (perhaps a subset of failure
>     reports) that provides minimal data from the email (specifically, the
>     initial ask is for the to: and from: email addresses only) in order to aid
>     identification of the email's destination (and hence, the owner who can
>     help with getting it authenticated) without providing other PII.
> 
>     This is a significant use case for large organizations, where the
>     departments or other sub-organizations run their own emailing
>     infrastructure. This has been specifically requested by multiple
>     universities.
> 
> 
> DMARC failure reporting is based on Authentication Failure Reporting Using 
> the Abuse Reporting Format (RFC 6591), which in turn is based on An 
> Extensible Format for Email Feedback Reports (RFC 5965).  DMARC adds five 
> fields for the second MIME part of the report.  The third part can be either 
> the full message of just the rfc822-headers.  The latter is defined in The 
> Multipart/Report Media Type for the Reporting of Mail System Administrative 
> Messages (RFC 6522), which mentions that Received: fields can also be useful 
> for diagnosing failures.  In any case, private data such as the local part of 
> email addresses can be redacted according to Redaction of Potentially 
> Sensitive Data from Mail Abuse Reports (RFC 6590).
> 
> In order to be useful, reports should contain enough data to discern whether 
> the failed message was abusive, and what stream does it belong to if it 
> wasn't.  Should DMARC Failure Reporting (our document) include some guidance 
> about what parts of the failed message to include and which ones to redact?

During our DMARC deployment (and even today) I was frustrated that I could see 
from aggregate reports that an ESP (or some other type of hosting provider 
whereby the IP address alone wasn't identifiable enough) was using our domain, 
but I didn't know who within our organization was a customer of the ESP.  
Ultimately, I wanted to reach out to the customer and set them up with a 
subdomain to use with the ESP so they could send branded and DMARC 
SPF email.  Asking the ESP who they're allowing to use our domain 
was a dead-end because they considered that private customer information 
(irony!) and they're naturally inclined to make their customers happy by 
tolerating the use of the domain without complicating matters that may result 
in possibly losing the customer.

Forensic reports are a useful mechanism to find examples of these messages and 
subsequently track down the customer on our end.  Usually, seeing the local 
part of the address used in the From header (maybe coupled with the Subject) 
was enough information.  I did struggle with the needle-haystack problem with 
these reports.  It was challenging to find what I was looking for, and it was 
challenging to create a process for going through all of the reports in any 
meaningful way.  Perhaps I didn't really find the right tool for the job, or 
perhaps the problem wasn't large enough for me to justify finding/developing 
the right tool.

Alternatives:

- Assuming that all ESPs were cooperative to inquiries from domain owners, and 
there was a consistently-used internal identifier that could be referenced that 
doesn't directly disclose publicly identifiable information about the customer, 
then that might be all of the forensic information that I would need.  But fall 
back to From/Subject, otherwise.  

- SPF macros can be constructed such that the envelope information is sent back 
to the domain owner via DNS queries.  This tactic is handy only if there is 
something identifiable in the local part of the return path.  The downside to 
this tactic is that you're spraying unencrypted identifiable information across 
the internet.

I guess that I'm leaning towards encouraging redacted reports with some 
minimally identifiable information.  The reporters still have the option to not 
send reports (or redact however they see fit), and domain owners have the 
option to not request reports if they are concerned about privacy.  

The potential downside to not having failure reports at all is that potentially 
less secure/private mechanisms may be adopted due to demand (such as SPF 
macros, sketchy data warehousers, etc). 

I did purposefully ignore the use case for using DMARC failure reports to track 
direct domain abuse, which I assume is a valid use case and should be 
considered in more depth.  I just don't have a direct experience using that 
data in any meaningful way.  Perhaps it could be used in a way that articulates 
the *actual* amount of direct domain spoofing being used by malicious actors, 
as opposed to aggregate reports which only gives you IP addresses (which may be 
enough if cross referenced with reputation 

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Jesse Thompson]

On 12/3/20 8:21 AM, Todd Herr wrote:
> On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins  > wrote:
> 
> 
> 
>> On 3 Dec 2020, at 06:03, Jim Fenton > > wrote:
>>
>> On 2 Dec 2020, at 1:47, Laura Atkins wrote:
>>
>>> p=quarantine is quite useful, particularly for those folks who are 
>>> trying to get to a p=reject state.
>>>
>>> In practice, senders who publish p=none don’t find all of the indirect 
>>> mail flows as some mailing lists do nothing to transform the 5322.from 
>>> address for a p=none policy. Senders have found that when they switch from 
>>> p=none to p=quarantine pct=0 they regularly find mail that was not failing 
>>> for a p=none.
>>
>> I’m really confused by this. It sounds like the 5322.from address 
>> rewriting is creating additional errors that didn’t exist beforehand, and 
>> that’s the opposite of the intended purpose. Isn’t the purpose of rewriting 
>> the 5322.from address to change the domain to that of the mediator, which 
>> should redirect reporting to the mediator rather than the original sender?
> 
> What I am trying to say is that as I understand it from the folks who 
> professionally deploy DMARC, they regularly use p=quarantine pct=0 as part of 
> the deployment process. There are DMARC failures that go undetected in a 
> p=none situation but that is detected in a p=quarantine  pct=0 situation.  My 
> understanding was this was related to indirect flows through mailing lists 
> and how mailing lists are handling the header transformation but it’s 
> possible I got that piece incorrect. 
> 
> 
> Time was (and may still be) that there was a very specific type of mailing 
> list for which p=quarantine, pct=0 was required to get accurate DMARC 
> reporting, and that was for mail that transited Google groups. There've been 
> a couple of public discussions of the topic over on mailop, including a 
> thread from April 2018 with the subject of "DMARC p=quarantine pct=0". 

p=quarantine pct=0 is a very useful strategy

1) It allowed us to find the mailing lists that don't munge from the From 
header - which would subsequently be problematic once we moved to pct=100

2) It allowed us to segregate the user complaints.  With a large change 
initiative you need to reduce the number of uncontrolled variables at any one 
time.  If we went straight to pct=100 then there would be a mix of people 
complaining about from munging mixed in with complaints about delivery.  
Confusion would ensue and the entire premise of DMARC would have been called 
into question.  By using an incremental process it's easier to deflect people 
complaining about the Stage 1 problems after moving to Stage 2.

3) It allowed us to discover email receivers who ignore pct.  It was annoying, 
but also a convenient gift in disguise, since it allowed us to innocently blame 
the receiver when non-compliant senders objected to the necessary DMARC 
adaptations.

Jesse

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

Re: [dmarc-ietf] Domains and tree walk

[Jesse Thompson]

On 12/1/20 8:50 PM, John Levine wrote:
> On the other hand, I observe that Brown, Cornell, Dartmouth, U Penn,
> and Yale, whose situations are not altogether unlike Columbia's, all
> publish DMARC records. Closer to home so do NYU and CUNY. They all say
> p=none with rua= to collect reports. You might give them a buzz to see
> how it works for them.

The fact that Joseph is here raising valid deployment concerns shouldn't be 
overshadowed by an assumption that these other universities are ahead of the 
game.

I participated in a hi-ed cybersecurity committee to create an "email security 
maturity" rubric - basically just something that CISOs can use to 
reflect/compare to each other.  I advocated that publishing p=none and 
consuming the reports is a good first step, but just maturity level 1 (of 5).  

Some university cybersecurity organizations feel like publishing p=none (and, 
perhaps, not actually looking at the reports) puts them into "compliance" with 
this DMARC thing that only their email admins really grok. 

I would hesitate to assume that seeing p=none on a domain as an indicator that 
they are serious about deploying DMARC and reconciling their own Holy Roman 
Empire conundrums; rather it's there just to not be seen as lagging behind 
their peers, justifying funding for more SOC staff and perhaps buying some 
tools (*some* of which, hopefully, may be deployed to actually solve the issues 
identified in the DMARC reports).

For better or worse, DHS BOD 18-01 mandated that all federal agencies publish 
p=reject on their domains.  Now, *that* must have forced each agency to figure 
out how to actually deploy DMARC and deal with the implications.  I applaud the 
tenacity.


On 12/2/20 10:21 AM, Todd Herr wrote:
> This is, I think, one of the most underappreciated features of DMARC. With 
> p=none, a proper rua= value, and enough time, one can collect all the 
> information needed to address any authentication shortcomings within a 
> designated portion of the DNS namespace before moving forward to p=reject, 
> assuming that that is one's goal with a DMARC implementation. Even for less 
> lofty goals such as ensuring that all mail is properly DKIM signed, or that 
> the SPF record properly enumerates all mail sources, I can't think of a 
> better tool than DMARC aggregate reports for ferreting out that third party 
> that the Marketing department hired to send mail on the company's behalf, or 
> locating that one mail stream emanating from the "server" sitting at the side 
> of Eddie the Engineer's desk.

I agree with all of this.  As I mentioned above, I just question the assumption 
that seeing p=none in a DMARC record is a good indicator that the organization 
is actually doing all of the things you enumerate.

It's also pretty clear from my own experience that it's impossible for complex 
organizations to address all of their non-compliant sources of mail flow.  
Eventually, you just need to draw a line in the sand and cause the mail from 
random campus servers and ESPs who use domains without authorization to be 
rejected (or quarantined, in our case).  


On 12/2/20 1:48 PM, superu...@gmail.com wrote:
> If DMARC is thus constrained and you have a "p=reject" on "columbia.edu" 
> only, then nothing stops me from generating unauthenticated email with a From 
> field indicating "foobar.columbia.edu" for any subdomain "foobar", whether or 
> not it actually exists in the DNS.

I also advocated that sp=reject would be a sign of a high level of maturity.  I 
was in the minority and criticized for complicating the situation (only the 
flagship domain needs protection - said some).  Win some battles, lose some 
battles.

Regardless, I still feel like the tree walk is better than the org domain model 
since it would actually allow us to get to sp=reject.  With the org domain 
model, we'll probably be stuck at sp=none indefinitely.

Jesse

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

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

[Jesse Thompson]

On 11/25/20 11:30 AM, Alessandro Vesely wrote:
> Without resorting to ARC, it is still possible to validate author domain's 
> signatures directly if the MLM just adds a subject tag and a footer, like, 
> for example, this list does.   While ARC solves "deep" forwarding problems, 
> which may arise in the context of email address portability, MLM 
> transformation reversion solves the simpler mailing list problem, including 
> reverting munged From:'s.

I agree that ARC isn't really needed to do this (trust the last hop from the 
MLM and determine the original authenticity from the MLM's perspective), 
although I think that ARC somewhat standardizes what headers/value to look for 
(I may be wrong).  Plus, if it eventually solves the "deep" forwarding issue, 
then ARC is certainly better than trying to follow received header chains, etc.

Anecdotally, after much debate, our team is leaning more towards *not* 
reverting munged From:'s from our own MLM

1. Until ARC has a reputation model that is commonly adopted, header munging 
isn't going to subside.  I still find MLM operators who are just now realizing 
that they have to munge messages.  We need to tell users that this is the new, 
growing, reality.

2. If we only unmunge for our own domains' users' authoring messages to our own 
MLM, it has limited overall effect, and it distorts the user-reality story from 
point #1.  We would have to unmunge for all domains' authors sending to all 
"trusted" MLMs in order to give the users what they expect from their prior 
reality.

3. Since we can only unmunge for our own recipients, it just creates an 
inconsistent experience on top of the already inconsistent experience of the 
conditional munging most MLMs do based on the authors' DMARC policies.  

We would rather see:

3a) MLMs that munge for all messages regardless of the author's domain's DMARC 
policy 

3b) MLMs that allow operators to configure recipient destinations that they 
know are going to trust non-munged messages (via ARC or whatever)

Jesse

P.S. If anyone knows how to trick Google Groups into doing 3a and/or 3b, please 
ping me (off list is OK)

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Jesse Thompson]

On 11/24/20 9:52 AM, todd.herr=40valimail@dmarc.ietf.org wrote:
> On Tue, Nov 24, 2020 at 10:37 AM Dave Crocker  > wrote:
> 
> Just to be clear, I'm not challenging the need.  Rather I'm just looking 
> for text that explains the need.  And I'm not finding it...
> 
> On 11/24/2020 7:28 AM, Todd Herr wrote:
>> There are two reasons (at least) for needing the Organizational Domain, 
>> and they are discussed in RFC 7489:
>>
>>  1. DMARC also allows for the explicit or implicit expression of policy 
>> for sub-domains at the Organizational Domain level. This matters for those 
>> times when _dmarc.RFC5322.From.domain is non-existent and 
>> RFC5322.From.domain is a sub-domain of the Organizational Domain.
>>  2. The default mode for authenticated identifier alignment, relaxed, 
>> requires only that the Organizational Domains for both identifiers are the 
>> same, and so the Organizational Domain must be known in order for relaxed 
>> alignment to be ascertained.
>>
> Except that I do not find either of these points provided in the document.
> 
> For point 1, this is from Section 6.6.3, Policy Discovery:
> 
>1.  Mail Receivers MUST query the DNS for a DMARC TXT record at the
>DNS domain matching the one found in the RFC5322 
> .From domain in
>the message.  A possibly empty set of records is returned.
> 
>2.  Records that do not start with a "v=" tag that identifies the
>current version of DMARC are discarded.
> 
>3.  If the set is now empty, the Mail Receiver MUST query the DNS for
>a DMARC TXT record at the DNS domain matching the Organizational
>Domain in place of the RFC5322 
> .From domain in the message (if
>different).  This record can contain policy to be asserted for
>subdomains of the Organizational Domain.  A possibly empty set of
>records is returned.
> 
> 
> 
> For point 2, this is from Section 3.1.1, DKIM-Authenticated Identifiers:
> 
>In relaxed mode, the Organizational Domains of both the [DKIM 
> ]-
>authenticated signing domain (taken from the value of the "d=" tag in
>the signature) and that of the RFC5322 
> .From domain must be equal if
>the identifiers are to be considered aligned.  In strict mode, only
>an exact match between both of the Fully Qualified Domain Names
>(FQDNs) is considered to produce Identifier Alignment.

The end of Section 3.1 might need to be clarified:

"Relaxed mode can be used when the operator also wishes to affect message flows 
bearing subdomains of the verified domains."

* I assume that relaxed mode can be set in the DMARC policy of a subdomain even 
if the Organizational Domain doesn't have (or want) that in its policy

* The subdomains in this context are the subdomains of the Organizational 
Domain, rather than the subdomains of the domain that published the relaxed 
mode in its policy

So if acme.example publishes aspf=s adkim=s 
It does not prevent finance.acme.example from publishing aspf=r adkim=r
Which would align widgets.acme.example with finance.acme.example even if the 
intent was to only align delegated-esp.finance.acme.example with 
finance.foo.example

Suggested better wording:

"Relaxed mode is determined from the policy of the RFC5322.From domain or from 
the Organizational Domain policy if the RFC5322.From domain has no policy.  It 
can be used when the operator also wishes to affect message flows bearing 
subdomains of the Organizational Domain."

If "walking the tree" is viable, then perhaps it should be:

"Relaxed mode is determined from the policy of the RFC5322.From domain or from 
[something about walking the tree to determine the policy].  It can be used 
when the operator also wishes to affect message flows bearing subdomains of the 
domain that published the relaxed mode policy."

Jesse

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Jesse Thompson]

On 11/23/20 1:00 PM, Dave Crocker wrote:
> On 11/23/2020 10:50 AM, Jesse Thompson wrote:
>> Would it help if there was a new DMARC policy tag to trigger the tree walk?
> 
> 
> policy tags are useful when one has a dmarc record that might contain it.  
> the challenge here is to find that record.

I meant to suggest that the requirement for a tree walk would be that the 
Organizational Domain would need to have that in its policy.  It seems like a 
decent compromise for the people worried about unnecessary DNS lookup overhead.

Jesse

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

Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup

[Jesse Thompson]

On 11/20/20 6:02 PM, John R Levine wrote:
> Here's a draft about how DMARC might do a tree walk rather than look up an 
> organizational domain in the PSL.
> 
> https://datatracker.ietf.org/doc/draft-levine-dmarcwalk/

Would it help if there was a new DMARC policy tag to trigger the tree walk?  
It's still the same number of DNS lookups, but changes the order and doesn't 
happen unless the organization wants it, so (aside from potential abuse) it 
should minimize the overall DNS lookup overhead.

Look up _dmarc.sales.east.widgets.bigcorp.com - find no policy
Look up _dmarc.bigcorp.com - finds a policy with a tw=1 tag
Look up _dmarc.east.widgets.bigcorp.com - find no policy
Look up _dmarc.widgets.bigcorp.com - finds a valid sp tag

Is it also worth considering changing the direction of the lookups under the 
assumption that the consistency of/control over the sub-organization's sending 
practices increases with each branch?  This would potentially reduce the number 
of DNS lookups.

Look up _dmarc.sales.east.widgets.bigcorp.com - find no policy
Look up _dmarc.bigcorp.com - finds a policy with a valid tw=true tag
Look up _dmarc.widgets.bigcorp.com - finds a valid sp tag and no additional 
tw=1 tag

Jesse

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

Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd

[Jesse Thompson]

On 11/23/20 8:28 AM, eric.b.chudow.civ=40mail@dmarc.ietf.org wrote:
> Even for .mil, the vast majority of email domains are fairly short with four 
> or fewer labels. Most of the other ones tend to be individual servers that 
> send automatic performance emails, and I think should be considered more of 
> an edge case and less of our concern. 

This is the case for us as well (e.g. our comp sci high throughput compute 
cluster servers send automatic emails to both internal and external research 
collaborators).  I suppose universities are different than the military since 
the military probably doesn't want their servers to be sending email 
externally, whereby with a research university cross-institutional 
collaboration is inherent.

I suppose I consider it an edge case too (a large edge case - I see over 200 of 
these 4th level domains in or DMARC aggregate reports for the example cluster I 
cite), but the long tail of servers also aren't likely to change the way they 
are sending email nor will sysadmins implement SPF/DKIM for every server 
hostname, etc, so these subdomains are a blocker for publishing sp=reject at 
the org domain (hence a concern within the context of tree walking).

While I understand that there are implementation challenges that may make this 
infeasible, what I would *like* to do is ask each of these departments/research 
teams to publish sp=none at their 3rd level domains (and take over DMARC 
responsibilities for their parts of the tree) so that we can publish sp=reject 
at the org domain to protect/manage the rest of the university.

Jesse

P.S. Here are some stats.  Unique domains used in the RFC5322.From resulting 
from mail sent externally to DMARC reporting organizations in the past 2 weeks:
23 2nd level (org domains)
464 3rd level (359 are subdomains of wisc.edu)
522 4th level (all are subdomains of wisc.edu)
13 5th level
2 6th level

> 
>  
> 
> Thanks,
> 
>  
> 
> Eric Chudow
> 
> DoD Cybersecurity Mitigations
> 
>  
> 
> --
> *From:* Laura Atkins [la...@wordtothewise.com]
> *Sent:* Monday, November 23, 2020 8:19 AM
> *To:* Murray S. Kucherawy
> *Cc:* IETF DMARC WG
> *Subject:* Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for 
> draft-ietf-dmarc-psd
> 
> 
> 
>> On 22 Nov 2020, at 06:06, Murray S. Kucherawy > > wrote:
>>
>> On Sat, Nov 21, 2020 at 6:23 PM John Levine > > wrote:
>>
>> It is my impression that most real From: domains are pretty short. I
>> don't think I've ever seen one more than four labels long that wasn't
>> deliberately contrived. Anyone got data on that?
>>
>>
>> I'd bet there are some in .gov or .mil, especially the latter, but otherwise 
>> I think the longest one I've seen is five, and that was not a host that 
>> receives mail.
>>
>> I'm sure we can all scrape our own mail logs for evidence either way.
> 
> This might be a place where one (or more) of the big ESPs can help. They’re 
> going to have billions of email addresses and know which ones have MXs. I’m 
> happy to ask for that data if it would be of use. 
> 
> laura 
> 
> -- 
> Having an Email Crisis?  We can help! 800 823-9674 
> 
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com 
> (650) 437-0741
> 
> Email Delivery Blog: https://wordtothewise.com/blog 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Jesse Thompson]

On 11/13/20 9:03 AM, dotz...@gmail.com wrote:
> 
> 
> On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan  > wrote:
> 
> 
> 
> As another case, would people be surprised that email for the 
> medical center cumc.columbia.edu  is a separate 
> system managed by a separate IT group from columbia.edu 
> , and that any authentication for one should not be 
> applied to the other?  I don't think this is unique in large decentralized 
> universities. The real email world is a complicated place.
> 
> 
> The simple solution is for  cumc.columbia.edu 
> to publish its own record. Done.
> 
> Michael Hammer
> 
> 
> I don't think I have the right to force the owner of another domain to 
> publish dmarc. The owner of the other domain may want to allow users in their 
> domain to contribute to lists and groups without having their messages 
> rejected, or mangled by well-intentioned workarounds. This is not simple. 
> This is a real-world case with the domains ending columbia.edu 
> . 
> 
> 
> If CUMC publishes a DMARC record for cumc.columbia.edu 
> , how is it forcing another domain to do anything? 
> As far as "owner of a domain", If Columbia University registered the domain 
> columbia.edu , then CUMC is using the subdomain because 
> Columbia University is allowing it to, presumably through some sort of 
> written agreement. A technical standards body cannot address business and 
> contractual arrangement in the manner you appear to be asking. If Columbia 
> University stopped delegating the subdomain cumc.columbia.edu 
> , would you turn to the IETF for redress?  

You can't think of universities as single entities with central management 
authority.  For the longest time our CS department owned wisc.edu and central 
IT had to ask them for permission to use it for campus-wide email.

Yes, 3rd level domains should be encouraged to publish DMARC records for their 
domains to reflect how they are being used, and putting p=none not a big ask of 
them.  

The departmental IT who understand DMARC immediately ask: "How do I publish a 
subdomain policy?  Oh, I can't?  Well, you better not ever change sp=none at 
the org domain."

Jesse

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

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

[Jesse Thompson]

On 11/12/20 5:06 PM, Kurt Andersen (b) wrote:
> On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson 
> mailto:40wisc@dmarc.ietf.org>> 
> wrote:
> 
> On 11/12/20 3:23 PM, John Levine wrote:
> > You now can put a DMARC
> > record on a name below the org domain to shadow a subtree, but I don't
> > think that is a problem that needs to be solved.
> 
> I'm confused by this statement.  Are you saying that you can "now" do 
> subtree shadowing with sp?  as in the following language is being changed 
> "now"?
> 
> 
> I think that John was referring the potential future state where tree-walks 
> were being done, but even then I don't think it would work quite that easily. 
> A record at "a.b.example" would not shadow "x.y.a.b.example" if "x" or "y" 
> chose to express some policy.

Yes, that makes sense for a defined policy to override any inherited subdomain 
policy. 

Jesse

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

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

[Jesse Thompson]

On 11/12/20 3:23 PM, John Levine wrote:
> You now can put a DMARC
> record on a name below the org domain to shadow a subtree, but I don't
> think that is a problem that needs to be solved.

I'm confused by this statement.  Are you saying that you can "now" do subtree 
shadowing with sp?  as in the following language is being changed "now"?

"Note that "sp" will be ignored for DMARC records published on subdomains of 
Organizational Domains due to the effect of the DMARC policy discovery 
mechanism described in Section 6.6.3."

Or that you meant to say "not" instead of "now" - which is more accurate to 
current state, I think.

I would assert that for "sp" to be realistically achievable (i.e. the policy 
coverage for the non-existant and long tail of domain/host names that 
*shouldn't* be sending unauthenticated email) for a complex organization this 
is a problem that needs to be solved.  

To further clarify the use case for walking the tree: it allows us to put 
sp=reject on the org domain (backstopping the problem) and contain legacy 
environments to solve through reconfiguration/attrition by setting sp=none on 
the applicable 3rd/4th-level domains.

Jesse

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

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

[Jesse Thompson]

On 11/12/20 10:30 AM, John Levine wrote:
> In article 
>  you 
> write:
>> As another case, would people be surprised that email for the medical
>> center cumc.columbia.edu is a separate system managed by a separate IT
>> group from columbia.edu, and that any authentication for one should not be
>> applied to the other?  I don't think this is unique in large decentralized
>> universities. The real email world is a complicated place.
> 
> Good point, and those aren't boundaries that the PSL et al will show.
> On the other hand, if you don't want your nominal parent organization
> stealing your reports, you can fix that by publishing your own dmarc
> record regardless of how we find the org domain.

Assuming this is obvious - it's also a challenge for sp.  It would be nice to 
get to the point that we could publish more than sp=none at our organizational 
domain.  Without tree walking, or some other ability to define sp for 3rd-level 
domains (such as the one that is the parent of our high throughput compute 
cluster of 4th level domain named machines that send email - shocker, I know), 
we'll never achieve any meaningful org-level sp due to the complexity of our 
organization.

If tree walking is a thing that comes to fruition, what does it mean for a 
domain to be an organizational domain (in reference to the idea that the DMARC 
spec will just point to another doc to determine the org domain)?  Aren't all 
parent domains org domains of their children?  Or is there something special 
about the "top" org domain that I'm not understanding?

Jesse
UW-Madison

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

Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

[Jesse Thompson]

On 10/19/20 7:17 AM, Brotman, Alex wrote:
> Sure, I think Masaki Kase is suggesting roughly the same thing (along with IP 
> address).  Tell the domain who is the entity responsible for attempting this 
> delivery?  This might need to be a hash of some sort.

> I think this sort of data would benefit both the domain holder, but as you 
> suggested, also the ESP.  They could aggregate their own data to show 
> drift/misconfiguration.  And yes, as you also suggest, sometimes the DNS guys 
> change things that the MarComm team doesn't know about, believing they're 
> doing the proper thing.

ESPs who hash/obscure the customer ID may want to consider a special support 
portal for mailop->ESP questions.  It would be frustrating to be sent to 
front-line agents and given the stiff arm.


>> 3) Domains that don't have a DMARC record
> [Brotman, Alexander]
> 
> It might be possible, depending how this were created, to have a "Senders 
> DMARC" Policy, without a proper DMARC policy.  Perhaps marginally useful to 
> the domain.

Sent to where, postmaster?

Jesse

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

Re: [dmarc-ietf] ARC usage, was Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Jesse Thompson]

On 10/6/20 10:20 AM, John Levine wrote:
> In article <1265372281.9984.1601969016...@appsuite-gw1.open-xchange.com> you 
> write:
>> It would be much better if there were a few professional/community efforts 
>> to build reliable and complete lists of good
>> and bad ARC intermediaries, like for spam.
> 
> Having tried and failed to build a whitelist for Spamhaus, I can tell
> you that it's hopeless.
> 
> The bar for ARC to be usable is pretty low. It's not "doesn't send
> spam" or even "knows who its users are." It's only "doesn't lie about
> where mail came from."  I expect that in practice the usual DNSBLs
> will be good enough.

Is the assumption with ARC, when it reaches some point of "production" status, 
that intermediaries will be able to look themselves up in the usual DNSBLs to 
see if they are trusted so they know that they don't need to rewrite the From?  
Sorry, that's going down the rabbit hole...

I only brought up ARC as one example of local policy overrides that an 
ISP-hosted receiver might want to have mechanics to control.  Even with ARC 
being adequately managed by the usual DNSBLs, I could imagine that I would want 
to have some control over the edge cases.

Surely there are other examples...

* This is probably the most common one, based on personal experience: Allowing 
a 3rd party to send inbound mail to your organization "From" your own domain, 
but not allowing that 3rd party to use your domain to send outside of your 
organization (hence, not authorized by DMARC).  Ideally I would want a solution 
that keys off of multiple signals (SPF result, DKIM result, DKIM 
domain/selector, etc) rather than something crude, like "trust all mail from 
these IPs".

Again, my larger point is that if we want "filtering signal" to be the primary 
value-add for DMARC, then I'm suggesting that we may need to ensure that 
receivers actually have the ability to invent filtering signal mechanics in 
order to be "using DMARC".  If the receiver's ISP is preventing that, then 
perhaps there needs to be a way for ISPs' customers' to measure their ISP's 
DMARC capabilities/maturity in this regard.

> I am told that Office365 allows clients to place their own email filter in 
> front of the one provided by Microsoft.  I don't know whether that solves the 
> black box problem that Jesse raises. 

Yes, this is what we do, but it's not common.  Microsoft occasionally tries to 
convince us to point MX at them, and I sympathize with their motivation to put 
all of their customers in a consistent configuration.  On the other hand, there 
are some local policy mechanics that we currently rely on which they don't 
provide.

Jesse

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Jesse Thompson]

On 9/28/20 10:35 AM, Kurt Andersen (b) wrote:
> On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman  > wrote:
> 
> On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote:
> 
> Agreed.  Maybe it would help if someone who takes the latter view would
> explain what they think RFC 7489, Section 6.6.2, Step 6 is for:
> 
> >    6.  Apply policy.  Emails that fail the DMARC mechanism check are
> >        disposed of in accordance with the discovered DMARC policy of the
> >        Domain Owner.  See Section 6.3 for details.
> 
> I don't think that says "then toss the results into your classifier".
> 
> 
> You completely ignored section 6.7 (Policy Enforcement Considerations) which 
> states:
> 
>> Final disposition of a message is always a matter of local policy.
> 
> Local policy could be considered "the output of some classifier" or other 
> mechanics left to the invention of the receiver.
> 
> This is a part of the documented DMARC spec, not a change.

Reading this thread, it comes to my mind that the "fundamental disconnect" that 
John raises is partly caused by an externalized factor: the shift to cloud 
mailbox hosting.  The roles, responsibilities, and assumptions have changed.

The receiver, who is now a customer of an ISP, does not have the ability to 
"invent mechanics" because the tools aren't provided by the ISP.  The ISP, of 
course, has a good reason to K.I.S.S. for support.  

It means that the ISP takes over responsibility for local policy mechanics to a 
greater extent.  Falling short of providing their customers a platform to 
invent mechanics the ISP will just implement the none|reject|quarantine 
mechanics and say they "support DMARC".

Even if the ISP has proprietary local policy mechanics that they apply to all 
of their customers' inbound mail, they aren't likely to document it in great 
detail or offer many exemptions.  It's a black box.

e.g. I find it hard to imagine that an ISP would have the willingness to exempt 
a boutique MLM for all of their customers, so ARC, in and of itself, doesn't 
really help MLMs move away from From munging.  Does it make sense to suggest 
that in order for ARC to succeed, then ISPs need to offer a way for their 
customers to define their trusted intermediaries?  What if the ISP chooses not 
to offer that?  Do they "support ARC" in a meaningful way?

For the "filtering signal" viewpoint to succeed, I would ask: is there a need 
to define some local policy mechanics into the spec so that the ISP can be held 
to account by customers to "fully support DMARC".  If the ISP offers no 
adequate mechanics to do signal filtering, then that ISP's hosted receivers 
cannot realistically support DMARC based on the assumption baked into DMARC 
that receivers can and will implement override mechanics.

The roles have changed, which has diluted the "filtering signal's" value mostly 
to the ISPs, and the benefit to receivers is metered by the extent to which the 
ISPs are willing to build a platform for their customers to invent mechanics.  

If the shift to cloud is incompatible with "filtering signal" mechanics for 
local policy overrides, is DMARC's only value left to receivers "what users 
see" and the simplistic none|quarantine|fail mechanics, as defined?

Jesse

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

Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Sep 20 06:00:05 2020

[Jesse Thompson]

On 9/20/20 4:59 AM, jo...@taugh.com wrote:
>Count|  Bytes |  Who
> ++---
>   4 (19.0%) |  59259 (32.1%) | Douglas E. Foster 
> 
>   4 (19.0%) |  34450 (18.7%) | Joseph Brennan 
>   2 ( 9.5%) |  20361 (11.0%) | Jesse Thompson 

Allegedly! says jesse.thompson=40wisc@dmarc.ietf.org :-)

>   2 ( 9.5%) |  12570 ( 6.8%) | Kurt Andersen (b) 
>   2 ( 9.5%) |  11447 ( 6.2%) | Sabahattin Gucukoglu 
>   2 ( 9.5%) |   9262 ( 5.0%) | Alessandro Vesely 
>   2 ( 9.5%) |   7723 ( 4.2%) | John Levine 
>   1 ( 4.8%) |  15078 ( 8.2%) | Ken O'Driscoll 
>   1 ( 4.8%) |   9022 ( 4.9%) | Dotzero 
>   1 ( 4.8%) |   5498 ( 3.0%) | Kurt Andersen (IETF) 

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

Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)

[Jesse Thompson]

On 9/17/20 5:09 PM, Sabahattin Gucukoglu wrote:
> On 17 Sep 2020, at 20:59, Jesse Thompson 
>  wrote:
>> On 9/17/20 2:11 PM, Sabahattin Gucukoglu wrote:
>>> Wouldn’t it be nice if you could ask for MLMs to transform, just using a 
>>> DMARC policy, even p=none,
>>
>> It is possible via p=quarantine pct=0.  
>>
>> I think it makes sense to consider codifying beyond this defacto standard 
>> hack.  Isn't this part of DMARCbis?  It was discussed, anyway.  Which ones 
>> are active?  https://trac.ietf.org/trac/dmarc/report/1
> 
> These tickets seem to be relevant:
> #22 (Perverse incentives to use p!=none & pct=0): 
> https://trac.ietf.org/trac/dmarc/ticket/22
> #73 (Need decision on importance of From domain): 
> https://trac.ietf.org/trac/dmarc/ticket/73
> #63 (Make p=none with no reporting URI invalid—Closed): 
> https://trac.ietf.org/trac/dmarc/ticket/63
> 
> I did not realise that this “hack” had become widespread. I agree that it 
> should be codified, or else p=none explicitly needs to support it (and in 
> that case reporting must remain optional). I can’t speak to the pct 
> parameter, because my sites are too small to really benefit from it.

I can't say how widespread it is in practice, but the concept has been 
discussed occasionally in various contexts.  Those of us who choose to 
[mis]deploy DMARC for user domains may find it useful.  The tactic was helpful 
to identify some of the DMARC-unaware MLMs in use.  

...

I don't want to overlook your other idea about advertising the ask for *no* 
transform.  

Is the idea that the domain owner can decide when they feel like there is 
adequate adoption of ARC, and a suitable reputation system, so that the 
intermediaries aren't saddled with that uncertainty into eternity?  

On one hand, I worry that domain owners will never actually know that ARC is 
ready until they actually ask intermediaries to stop transforming (and observe 
what breaks).  

On the other hand, it puts control for ARC adoption into the hands of the 
community.  It also gives us something to measure ARC adoption in a more 
meaningful way.

Jesse

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

Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not)

[Jesse Thompson]

On 9/17/20 2:11 PM, Sabahattin Gucukoglu wrote:
> Wouldn’t it be nice if you could ask for MLMs to transform, just using a 
> DMARC policy, even p=none,

It is possible via p=quarantine pct=0.  

I think it makes sense to consider codifying beyond this defacto standard hack. 
 Isn't this part of DMARCbis?  It was discussed, anyway.  Which ones are 
active?  https://trac.ietf.org/trac/dmarc/report/1

This trick also helps you find all of the receivers that ignore pct (treating 
your policy as p=quarantine pct=100)  This was annoyingly unexpected for us, 
but it happened to be an accidental graceful rollout mechanism that, I feel, 
worked better than ramping up the pct as designed.

Jesse

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

Re: [dmarc-ietf] AutoForward problems

[Jesse Thompson]

stem communicate to the 
user that some new policy is in effect short of sending an email or stopping 
the mail flow and hoping they notice and call for support?  

With the fetch model, at least there are more opportunities to interact with 
the user where they are (i.e. during the authorization flow during 
re-authentication after a session timeout).  Of course, all of that depends on 
the fetching side's UI for handling re-authentication, so it's not a slam dunk 
alternative to SMTP forwarding.

Jesse

> 
> Doug Foster
> 
> 
> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Jesse Thompson
> Sent: Thursday, September 03, 2020 8:42 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] AutoForward problems
> 
> On 9/2/20 6:33 AM, Douglas E. Foster wrote:
>> For mailing lists, we have pushed the limits of authorization.   But there
> is another class of problems where sender authorization is not feasible:  
> mail which is auto-forwarded after a spam-filter has made content-altering
> changes.
> 
> Yes, this is an increasing problem, as exemplified by the number of
> enterprises that have started tagging subjects and bodies with [External]
> warnings.  Coupled with DMARC adoption, the ability for users to
> auto-forward successfully is shrinking.  
> 
> I realize that John's message in the other thread probably wasn't
> referencing auto-forwarding, but I think his point dovetails to the
> auto-forwarding issue:
> 
>> As always, as I hope we all remember DMARC alignment doesn't mean not 
>> spam, and you still do all of the stuff you do to sort your mail.  
>> This scheme depends on the forwarders you authorize being 
>> well-behaved.  That's why I am concerned that senders need to be 
>> selective about who they allow to forward.
> 
> I am concerned with:
> 
> a) It assumes that the domain owner has the ability and desire to authorize
> every potential forwarder, even though auto-forwarding is a user-level
> decision.
> 
> b) It assumes that all potential forwarders check for authorization before
> forwarding -- essentially the same problem with the way most ESPs will use a
> domain in the From header without checking for authorization via DMARC.
> 
> c) Selectively allowing forwarding at the user level is difficult because
> users are gonna do what they wanna do (you try telling faculty they can't
> forward).  It's not the case that all enterprises want to prohibit all of
> their users from auto-forwarding (even though that's the answer you may get
> if you survey the CISO community)
>  
> d) Selectively forwarding based on the knowledge of whether the forwarded
> message will reach the destination is challenging because the intermediary
> doesn't really know if it will succeed, and selectively forwarding in this
> way will lead to the user only seeing a subset of their messages being
> forwarded.  This is essentially what's happening today (see my first
> sentence in this message), and I know users who are still bound and
> determined to auto-forward and they have just resigned themselves to the
> fact that they have to periodically check the intermediary mailbox for all
> of the messages that didn't survive the forward.
> 
> 
>> In the absence of such techniques, the forwarding system (or the outbound
> gateway) needs to be aware that a message has been forwarded after
> content-altering changes.   When this is the case, the message either
> requires a known exception at the receiving system or a From address rewrite
> so the message will pass DMARC.   At minimum, our DMARC specification should
> make this clear.
> 
> I agree with this, however, I'm increasingly of the mindset that since this
> is a user-level issue, we should be thinking about solving it via OAuth
> mechanisms.  Modern email services do support the ability to fetch from a
> mailbox, authorized via OAuth, so it might be easier to convince the
> downstream mailbox providers to enhance their fetching mechanisms to support
> the features that people expect of inbound mail (i.e. apply inbound
> filtering rules).  The mailbox provider would still need a way to determine
> the original DMARC results, spam analysis, etc, but wouldn't that be easier
> to implement since the message is "frozen in time" and wasn't subjected to
> the altering changes implied by forwarding?
> 
> Jesse
> 
> ___
> 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
> 

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

Re: [dmarc-ietf] AutoForward problems

[Jesse Thompson]

On 9/2/20 6:33 AM, Douglas E. Foster wrote:
> For mailing lists, we have pushed the limits of authorization.   But there is 
> another class of problems where sender authorization is not feasible:   mail 
> which is auto-forwarded after a spam-filter has made content-altering changes.

Yes, this is an increasing problem, as exemplified by the number of enterprises 
that have started tagging subjects and bodies with [External] warnings.  
Coupled with DMARC adoption, the ability for users to auto-forward successfully 
is shrinking.  

I realize that John's message in the other thread probably wasn't referencing 
auto-forwarding, but I think his point dovetails to the auto-forwarding issue:

> As always, as I hope we all remember DMARC alignment doesn't mean not spam,
> and you still do all of the stuff you do to sort your mail.  This scheme
> depends on the forwarders you authorize being well-behaved.  That's why I
> am concerned that senders need to be selective about who they allow to
> forward.

I am concerned with:

a) It assumes that the domain owner has the ability and desire to authorize 
every potential forwarder, even though auto-forwarding is a user-level decision.

b) It assumes that all potential forwarders check for authorization before 
forwarding -- essentially the same problem with the way most ESPs will use a 
domain in the From header without checking for authorization via DMARC.

c) Selectively allowing forwarding at the user level is difficult because users 
are gonna do what they wanna do (you try telling faculty they can't forward).  
It's not the case that all enterprises want to prohibit all of their users from 
auto-forwarding (even though that's the answer you may get if you survey the 
CISO community)
 
d) Selectively forwarding based on the knowledge of whether the forwarded 
message will reach the destination is challenging because the intermediary 
doesn't really know if it will succeed, and selectively forwarding in this way 
will lead to the user only seeing a subset of their messages being forwarded.  
This is essentially what's happening today (see my first sentence in this 
message), and I know users who are still bound and determined to auto-forward 
and they have just resigned themselves to the fact that they have to 
periodically check the intermediary mailbox for all of the messages that didn't 
survive the forward.


> In the absence of such techniques, the forwarding system (or the outbound 
> gateway) needs to be aware that a message has been forwarded after 
> content-altering changes.   When this is the case, the message either 
> requires a known exception at the receiving system or a From address rewrite 
> so the message will pass DMARC.   At minimum, our DMARC specification should 
> make this clear.

I agree with this, however, I'm increasingly of the mindset that since this is 
a user-level issue, we should be thinking about solving it via OAuth 
mechanisms.  Modern email services do support the ability to fetch from a 
mailbox, authorized via OAuth, so it might be easier to convince the downstream 
mailbox providers to enhance their fetching mechanisms to support the features 
that people expect of inbound mail (i.e. apply inbound filtering rules).  The 
mailbox provider would still need a way to determine the original DMARC 
results, spam analysis, etc, but wouldn't that be easier to implement since the 
message is "frozen in time" and wasn't subjected to the altering changes 
implied by forwarding?

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/21/20 4:05 PM, Brandon Long wrote:
> 
> 
> On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton  <mailto:fen...@bluepopcorn.net>> wrote:
> 
> On 8/17/20 3:52 PM, Jesse Thompson wrote:
> > With a complex organization the only way to get people to change is to 
> publish a restrictive DMARC policy and then see who comes out of the woodwork 
> sheepishly admitting that they've been ignoring us for years. 
> >
> > Normal people sending email (especially those who are working with an 
> ESP, most of which happily send email without any DMARC alignment) do not 
> comprehend the notion that they should be using a subdomain for their 
> transactional messages; even when we directly communicate this fact to them 
> repeatedly.  They just don't understand the nuances of email.
> >
> I thought the DMARC reporting mechanism was there to allow such
> organizations to detect those behaviors and get them corrected without
> actually causing the damage of a restrictive policy.
> 
> 
> One thing we've found useful in this case is controlling the organization 
> from spamming.
> 
> Which is to say that the org has a policy on approvals and what is allowed to 
> be sent marketing wise, in some parts of the world to comply with laws on 
> such topics,
> or to be sure the entire org follows the principles and someone new doesn't 
> just poison the pool for everyone else.
> 
> There are always people who route around restrictions or sometimes don't even 
> bother to look for anything, they'll just hire a third party ESP and spam 
> away.
> 
> DMARC helps in this case to reduce the success of that and force them back to 
> internal compliance, which relieves the legal burden as well as the negative 
> impacts
> on delivery and public perception.
> 
> For folks who just register a new domain name and spam anyways... yeah, well, 
> there are other consequences down the line and other anti-phishing 
> restrictions that
> kick in at least on our inbound systems..

Right.  

Moving past p=none puts somewhat of a backstop on the internal compliance 
problem, which would otherwise continue indefinitely.  I've put them into a 
state where they have to get a subdomain and learn about DMARC.  

DMARC [aggregate] reports don't tell us *who* in our organization is 
perpetuating the problem, especially if their volume is low or not visible to 
the few DMARC reporters.  At some point you need to acknowledge that you will 
never have complete visibility.

Jesse

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Jesse Thompson]

On 8/20/20 4:00 PM, blong=40google@dmarc.ietf.org wrote:
> Neither atps or spf include are really designed for large scale usage

That's my conclusion, as well.  I don't want to authorize every potential MLM 
to use all addresses in all of our domains cart blanch, even if I would 
otherwise trust them (e.g. their purported ARC results).

I *do* want to authorize our *own* MLM(s) to use our own domains for *internal* 
use... so I thought for a minute... maybe ATSP has merit for small scale usage, 
as an alternative to SPF include?  But no, I don't know if any MLM has a way to 
check to see if they are authorized via any mechanism, so they will continue to 
munge the From header for our DMARC-enabled domains anyway.  So, for this 
*internal* use case, maybe I'll just check the ARC result from the trusted MLM 
and replace the From header with the value of Reply-to/X-Original-From, and 
call it a day.

Jesse 

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Jesse Thompson]

On 8/17/20 3:00 PM, Luis E. Muñoz wrote:
> DMARC can be quite useful even with p=none.

Agreed.  People commonly request that we accept-list their IP/domain from 
inbound spam scanning.  We now tell them to send DMARC-aligned mail (SPF or 
DKIM pass, aligned with From), and we'll use that as criteria to accept mail 
from the domain, regardless of what policy they actually publish.

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/7/20 9:32 PM, John Levine wrote:
>> We need spoofing protection for all of our domains without being told we're 
>> misdeploying.
>
> I would be interested to better undertstand the meaning of "need"
> here. It is my impression that most people vastly overestimate how
> much of a phish target they are. Paypal and big banks certainly are, 
> other places, a lot less so.

(Sorry, I was on a much-needed vacation.)

Ok, that's fair, I should have realized that one was over-stated.  *Need* would 
imply that domain-spoofing is more common than it is in reality.

Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with 
spoofing (even though most phishing is spoofing the display name and message 
bodies, not the domain) and conclude that they *need* DMARC without really 
understanding the nuances.  Given the opportunity that DMARC marketing 
promises, they definitely *want* inbound DMARC enforcement for domain-spoofing 
of inbound mail (they'll defer to the email-minded folk to figure out the local 
policy exemptions, ARC, etc), as well as *want* domain policies that prevent 
the potential domain spoofing scenarios of owned domains (again, the 
email-minded folk will figure out how to actually "misdeploy" DMARC).  To them, 
it's just a checkmark towards some "maturity" benchmark that they use to 
compare to their peers.

Email-minded folk in EDU, knowing that DMARC doesn't really have much practical 
application to phishing, like having the observability that DMARC provides, as 
well as the hammer that moving past p=none provides as a way to coerce their 
complex, decentralized institution into a more sustainable operation: 

* Departments sending transactional email - move them to dedicated subdomains 
(this is where really complex institutions would benefit from walking the 
domain tree instead of always inheriting from the org domain)

* People sending user email from random places - move them to authenticated 
submission (preferably OAuth - since basic authentication is the reason why so 
many passwords are exposed)

The latter scenario is interesting because a single user sending from a random 
place doesn't really show up in DMARC aggregate reports.  It may show up in 
forensic reports, but it is easily lost in the noise.  (SPF macros might be 
another way to get fine-grained observability, but that's a privacy leakage 
IMO.)

In the end, it still results in:
* That person wouldn't end up on our radar for communication
* That person wouldn't understand what the message is about, even if we did 
communicate with them
* That person wouldn't comply, even if they understood
* Once enforcement is in place, that person will complain and leverage every 
ounce of their political influence to resist.  (It's really fun when your own 
users threaten lawsuits against you - that doesn't happen in Corporate IT.)

I'm kind of rambling now, I see.  Hope you find it enlightening, regardless!

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/13/20 10:03 AM, John R Levine wrote:
>> -Admittedly, that's where my bias comes in. My job is working with 
>> organizations that have paid my employer for me to be that outside help, so 
>> it's rare for me to see how badly it can be done by people setting 
>> restrictive DMARC policies without knowing what they're doing.
> 
> If they all talked to you first, we'd be having a very different discussion.

With a complex organization the only way to get people to change is to publish 
a restrictive DMARC policy and then see who comes out of the woodwork 
sheepishly admitting that they've been ignoring us for years.  

Normal people sending email (especially those who are working with an ESP, most 
of which happily send email without any DMARC alignment) do not comprehend the 
notion that they should be using a subdomain for their transactional messages; 
even when we directly communicate this fact to them repeatedly.  They just 
don't understand the nuances of email.

Similarly, it's only way to find all of the old DMARC-unaware MLMs, most of 
which haven't been security-patched for years.  Forcing them to upgrade to a 
MLM that can munge the From is a back-door way to get them to patch, or 
reassess their commitment to running the list in the first place.

Enterprise IT/cybersecurity actually want to get better manageability on the 
email their institution emit.  Misdeploying DMARC provides that.  Publishing 
restrictive DMARC on user domains is not always a clueless IT decision.

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/7/20 2:12 PM, John Levine wrote:
> In article 
> 
>  you write:
>> I feel like what is happening sometimes is that central university IT is 
>> trying to drag their whole institutions into a
>> more secure posture before anybody in a position to stop them fully 
>> understands what's going on lest they be told to
>> stop because it might make things a little inconvenient.
> 
> I was with you up until that sentence, since it trivializes the real
> problems that overly strict DMARC policies cause.

Maybe Autumn was reflecting the reality that the industry has already 
trivialized DMARC problems for these "misdeployments".  

 
> Just yesterday I was sorting out a problem with people trying to
> finish editing a revised IETF standard about real-time web
> applications. Some of the authors' messages were disappearing,
> apparently at random. I saw what the problem was, one of the authors
> is at a big company whose IT department insists on p=reject (and has
> blown off complaints from fairly senior people about the problems it
> causes), the other uses an MIT alumni address that recently moved its
> hosting to Microsoft without telling anyone that the new host enforces
> DMARC policy while the old one didn't.
> 
> My guess is that MIT figured Microsoft will host this for free, that's
> great, totally unaware that some of its users' mail would silently
> break.

Customers of Microsoft don't like to call things bundled in an expensive 
package "free".

My peeve in recent years is that universities were essentially coerced 
(economically) into being the customers of Microsoft/Google and then the email 
admins are told to sit down and let the adults talk about what they think 
customers need from DMARC, ARC, etc.  It's why I'm constantly sticking my foot 
in my mouth here and M3AAWG; trying to assert a voice.

We need faculty/alumni/emeriti forwarding to work without being told that 
Microsoft can't do it without breaking DMARC.

We need spoofing protection for all of our domains without being told we're 
misdeploying.

We know that we need advanced local policy controls for DMARC enforcement and 
we don't want to be blamed when the vendor doesn't give us those controls (to 
your MIT example) 


> I told them as a workaround they needed to directly cc each other when
> they send anything to the group list, but the whole thing is a
> self-inflicted wound.

Maybe it was inflicted by the domain owner onto the person maintaining the 
mailing list.  (In my experience, this is where people realize that no one has 
been maintaining/patching the mailing list, unaware of DMARC, etc.)

Again, I think MLM header munging is here to stay, and list recipients needs to 
get used to it (I'd like p=quarantine pct=0 be the default behavior so that 
domains choosing to misdeploy DMARC aren't second class).  

I'd like to see a way to un-munge mail from trusted intermediaries, but that 
sounds impractical.  

I think ARC has promise but it has some challenges that I hope can be overcome; 
notably a mechanism for the receiver to indicate trust to the intermediary (so 
that it knows it doesn't need to munge).

At that point, I can start to figure out how to deal with the mailbox-level 
forwarded mail for faculty/alumni/emeriti...

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 8/4/20 11:52 AM, Alessandro Vesely wrote:
> On 2020-08-04 6:10 p.m., Dotzero wrote:
>> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton  wrote:
>>> On 8/2/20 5:43 PM, Douglas E. Foster wrote:
 As to the transparency question, it should be clear that there will be
 no simple solution to the ML problem.
>>>
>>> Actually, there is: If your domain has users that use mailing lists,
>>> don't publish 'reject' or 'quarantine' policies. Generally this means to
>>> just use those policies for domains used for transactional email.
>>>
>>> Unfortunately we seem to be focused on very complex technical solutions
>>> to a misdeployment problem.

I've never heard this misdeployment viewpoint in the context of M3AAWG, so that 
might be a good audience to validate the viewpoint that users' domains can't 
benefit from p=quarantine|reject.  Perhaps it should be included in a BCP?  
Maybe it is, and I'm misremembering?  Granted, I've only been a member for a 
few years.  Maybe it was a common understanding years ago and no one talks 
about it anymore?

For example, when I was invited by the technical committee to present our 
strategy and challenges deploying DMARC for our institution, no one told me we 
were misdeploying.  The session was pretty well attended, and I don't think I 
put everyone to sleep.  Now I feel like my speech was counterproductive because 
I may have encouraged others to misdeploy DMARC too.


>> There is another solution. Move users to a separate domain from the domain

Long ago we put users on our org domain as a way to unify users (in a very 
decentralized institution) under a single domain identity, and that branding 
decision is not going to be undone, politically.  Any project to move users 
from one domain identity to another is a huge lift; it takes a lot of time, 
effort, and never actually completes due to stragglers with very legitimate 
reasons to not give up sending from their old address.  

I think that end-users would rather see their list mail be rewritten than be 
told to change their identity.  I know that some people on this list think that 
the domain in the from header isn't commonly visible anymore, but the domain is 
extremely important to users' sense of identity.  


>> your transactional mails are sent from. You can also put users on a
>> separate subdomain.

To the idea of clean separation:  We only encourage (without DMARC there is no 
way to enforce) subdomains for transactional email despite "brand minded" 
people insisting on using the org domain (or just using it without asking).  
Despite everyone having an address in the org domain, we still have many users 
using legacy subdomains, and some of those subdomains are mixed-use.  

DMARC is great for getting visibility on this "separation" problem.  It's not 
until we moved past p=none that we could get any sticks behind our carrots.  

What I'm saying is that mixed-use domains are common and they proliferated due 
to the lack of domain alignment enforcement prior to DMARC.  Even when there is 
intention by IT to separate the use cases, they need DMARC to get both the 
visibility and the manageability/enforcement.

I've observed other universities using their single org domain for everything, 
and they don't find out they have a problem until they try to implement DMARC.  
It's easier for them to move the transactional email to subdomains than to move 
users.  That is, unless they just give up on the idea of DMARC altogether.

This might be a stretch, but I think the "DMARC is different for user vs 
transactional domains argument" dovetails with the need for sp to walk the 
domain tree.  If the assertion is that the domain with users is fundamentally 
different than domains used for transactional email, and most institutions use 
their org domain for their users, and subdomains are a mixed bag of varying use 
cases, then the org domain's DMARC policy isn't the best candidate for 
inheritance.  


> Yet another solution would be to not use DMARC.  The status quo ante.
> 
> While p=none is a technically valid position, there seems to be a
> demand of a mail infrastructure where spoofing is not allowed.

Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-01/

I don't think DHS got the memo about misdeploying DMARC, either.  I know that 
around 2018, the person maintaining the MLM for our astrophysics center had to 
scramble to implement header munging because of all of the .gov's publishing 
p=reject

Jesse

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

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Jesse Thompson]

On 7/23/20 8:07 AM, Joseph Brennan wrote:
>> I think that we just have to agree that From-munging by MLMs is a permanent 
>> reality.  It needs to be documented more prominently (and promoted as part 
>> of the DMARC marketing) so that implementations are more consistent, so that 
>> un-munging tactics and/or MUA behavior can be consistently implemented.
>>
> I'd be happier for the proposed standard to say that DMARC policy
> "SHOULD NOT" be compromised by rewriting From lines-- and see how that
> goes over. My reasoning is that blessing the practice makes it easier
> for bad actors to craft spoofed mail and get it accepted. The opposite
> of the purpose of DMARC, isn't it?

(sorry, I forgot to reply earlier)

I realize that your worry is valid if anyone attempted to un-munge the messages 
and then use the un-munged state somehow to validate authenticity.  I assume 
that un-munging would only be attempted locally if the message passes DMARC and 
is trusted by local policy.  (Similarly, as I've suggested in other contexts, 
it would be nice if the Receiver could preemptively communicate this trust to 
the Intermediary so that the munging didn't need to occur in the first place 
and ARC could come to fuition, but I digress.)

As others have said, munged messages sent via a MLM aren't much different than 
someone posting to a web form and it then distributing the post to a set of 
email recipients.  That web form isn't expecting to be able to use the author's 
domain, and the pattern it uses in the Friendly From is somewhat arbitrary and 
could be co-opted by spammers.  

I don't think that bad actors crafting is a huge worry since I think that in 
both scenarios it would just fall back on the reputation of the domain (and 
other factors). 

(just spit balling... it's getting late on a Friday...) Perhaps an interesting 
local policy enforcement (to get at your concern) would be to require that 
messages with certain Friendly From patterns to be DMARC aligned (regardless of 
policy) since I could assume that any MLM (that I care about) that's DMARC 
aware enough to munge would also have aligned SPF and/or DKIM results.

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 7/30/20 2:47 PM, superu...@gmail.com wrote:
> Email domains that have more than a few users don't want to authorize 
> every potential 3rd party (converges quickly to all of them, for 
> large/complex organizations) to sign as every user/address in the domain.  
> Even if SPF didn't have the 10 DNS lookup limitation, I would not choose put 
> every 3rd party into our domains' SPF records.  I'd essentially be 
> authorizing most of the [legitimate] internet to use the domains.
> 
> 
> Yes, it has this scaling problem.  Had it been shown to be effective at 
> dealing with the indirect mail flows issues that DMARC forced to be 
> front-and-center a few years later, I imagine we could've revised ATPS to be 
> more scalable.

I almost suggested that an address-level authorization mechanism would be 
useful, but that seems un-scalable for manageability reasons.

Jesse

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 7/30/20 2:47 PM, superu...@gmail.com wrote:
> Translated into IETF-ese: "I have not read your document but I do have an 
> opinion about it..."   ;-)

Yeah, Dave sent me that feedback too.  I was just trying to make it clear that 
I only have $0.02 to give, rather than trying to sound like I'm an expert on 
ATSP.  I'll avoid the cliche next time.

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

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 7/29/20 12:34 PM, Hector Santos wrote:
> On 7/28/2020 1:19 PM, Doug Foster wrote:
>> Hector, I do not understand this comment:
>>
>> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party 
>> domains. DMARC did not address the problem and reason ADSP was abandoned. 
>> Hence the on-going dilemma."
>>
> 
> SSP, ADSP and DMARC are technical specs for a DKIM POLICY Model.
> 
> The problem we have with DMARC was the same with SSP which was replaced by 
> ADSP which attempted to ignore the problem. Generally, as it often done with 
> ambiguous issues in the IETF, we ignore it, we make it out of scope, we keep 
> it open ended, etc.  It just wasn't resolved and ADSP was abandoned but 
> returned as DMARC but it also kept the same 3rd party ignorance as ADSP did.  
>  If this issue is not resolved for DMARC, I see an interesting situation 
> during DMARCBis Last Call explaining how we abandoned ADSP for having problem 
> XYZ and then reintroduced "SUPER ADSP" as DMARC but it still has the problem 
> XYZ.
> 
>> Domains that participate with a mailing list have the option of including 
>> the ML servers in their SPF record, or delegating them a DKIM scope and key. 
>>    But to obtain that authorization from the sending domain, someone would 
>> have to ask for it, and might not receive the desired answer.
>>
>> The goal of this discussion is to find a way to coerce trust.   We do not 
>> lack ways to grant trust on request.
> 
> This issue is not about the known, but the unknown. We don't have an issue 
> with proactive authorization and whitelisting methods.
> 
> I've been in this DKIM project for 15+ years, and to me, the goal has also 
> been to find a reasonable, scalable deterministic protocol that will handle 
> unsolicited, unknown 3rd party domain signers. Not necessarily unknown in a 
> bad sense, unknown that you don't know anything about them. So you ask the 
> author, "Hey, is this 3rd party signer ok?"
> 
> SPF allows 3rd party IP declarations.  DKIM POLICY model does not offer this 
> capability.
> 
> We have DKIM Policy extension proposals like ATPS (RFC6541) that offers a 
> deterministic method to associate the author domain with 3rd party signer 
> domains.   This authorization is defined by the Originating, Author Domain.
> 
> Look at my DMARC record for my isdg.net domain:
> 
> v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net; 
> ruf=mailto:dmarc-...@isdg.net;
> 
> The atps=y tells an ATPS compliant receiver that if it sees a 3rd party 
> domain signature:
> 
>   Author Domain IS NOT EQUAL TO Signer Domain
> 
> Then it can do a ATPS look:
> 
>    base32(sha1(SIGNER-DOMAIN))._atps.isdg.net
> 
> So if I wanted to authorized bayviewphysicians.com to be able to sign for me, 
> I would go to the wizard https://secure.winserver.com/public/wcdmarc,  enter 
> your domain in the list of authorized signers, click Zone Record and I get a 
> record I can add to my isdg.net zone:
> 
> e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps  TXT ("v=atps01; 
> d=bayviewphysicians.com;")
> 
> So anyone out there can see that I authorized bayviewphysicians.com to sign 
> for isdg.net
> 
> It is really sample.
> 
> Whether we can "coerce" receivers to honor any of this is a different 
> situation.  In general, all you can do create a PROTOCOL that makes good 
> engineering sense and usable by the IETF community. If not, then generally 
> systems will ignore it.

I admittedly know nothing about ATPS, but I think its fundamental problem is 
that it authorizes 3rd parties at the domain level and that makes it not much 
better than SPF, just different.  

Email domains that have more than a few users don't want to authorize every 
potential 3rd party (converges quickly to all of them, for large/complex 
organizations) to sign as every user/address in the domain.  Even if SPF didn't 
have the 10 DNS lookup limitation, I would not choose put every 3rd party into 
our domains' SPF records.  I'd essentially be authorizing most of the 
[legitimate] internet to use the domains.

Ironically, you'll notice some domains actually doing this via SPF record 
flattening and macros specifically because they do not even want to attempt to 
solve the 3rd party authorization problem (look at umich.edu).

On the other hand, something like ATPS might be a partial solution for the MLM 
header munging problem, at least for intra-organizational email leveraging 3rd 
party platforms.  e.g. If I authorize only mlm.wisc.edu (and not every 
subdomain, so aspf=r is not an option) to send as wisc.edu (and potentially all 
of our ~480 domains which aren't all subdomains of wisc.edu), then the MLM 
platform should know that it doesn't need to rewrite the From header for 
messages from users in those domains.

It's kind of the inverse of the ARC dillemma.  ARC is missing a mechanism to 
tell an Intermediary if it will be safe to *not* rewrite the From header, and 
the lack of having a mechanism to convey historical or intended 

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson]

On 7/28/20 10:59 AM, Alessandro Vesely wrote:
> I understood the problem is the lack of agility.  Delegation to smaller 
> domains using local servers would solve it, wouldn't it?  Even with many 
> domains...
> 
> What am I missing?

It's assuming there are local servers in the mix, which is becoming less common 
with the shift to the cloud.  e.g, I am fairly certain that O365 doesn't have 
the DKIM flexibility you're talking about.

Jesse

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

Re: [dmarc-ietf] DMARC marketing

[Jesse Thompson]

On 7/22/20 5:55 PM, Jim Fenton wrote:
> These get to the heart of the problem: DMARC policy was designed for
> official mail that is about business transactions. If that was the way
> it is actually used, we wouldn't be having this problem. But it was
> oversold, and it is being used in use cases (like on domains that have
> mailing list users) that were not intended. 

Yes.  The cybersecurity IT community (at least, in Hi-Ed) largely don't know 
much about email's technical nuances.  But they they know that email phishing 
is a problem, and CISOs demand a solution.  They have their information sharing 
communities (ISACs), where email specialists are generally not included, to 
share knowledge and continue grasping for solutions to phishing.  Enter DMARC 
marketing: phishing is a spoofing problem and you're vulnerable unless you 
protect your domain with DMARC.  Cybersecurity IT tend to see things like DMARC 
as a checkbox towards compliance.  Once that box is checked (varying 
definitions) == job complete (email specialists are left to clean up the mess). 
 Since DMARC was ostensibly invented by the email community, there's not much 
room for local email specialists to convey that it's not a complete solution 
for phishing, and may not be worth implementing on domains used by end-users.  
Momentum suggests that it's easier to just join the bandwagon, move for
 ward with DMARC for every domain (to take advantage of the benefits it 
offers), and hope that Intermediaries can find a solution.


> I'm not convinced that this is a problem that has a satisfactory technical 
> solution.

I think there may be technical and non-technical techniques that can be pieced 
together to arrive at a satisfactory solution, depending on the 
individual/evolving circumstances.  What's lacking is clear guidance for 
Intermediaries; both for people who provide software/platforms, and for those 
installing and configuring them.  What is the best avenue for providing 
guidance?

I mean, this isn't just a problem for MLMs.  Office 365 utterly fails at 
mailbox-level forwarding in a DMARC friendly fashion.  Their latest 
announcement to tenant admins suggest that they're more likely to coerce their 
customers' end-users users to stop forwarding via SMTP altogether.  Maybe 
that's the only generic solution for that type of Intermediary (whereby ARC 
might be an alternative solution to forwarding between trusted institutions).  
Is it satisfactory?  Not to end-users who want to forward their email.  

Maybe the conclusion is that SMTP isn't even appropriate for many types of 
forwarding anymore, but rather pull-based OAuth solutions are more sustainable. 
 This solution is increasingly compatible with the mailbox hosting platforms, 
but isn't widely implemented by the receiving end of the equation.  Is there 
any point in recommending something like that as a solution as a way to move 
the industry in that direction?  

Or does something like this just tend to sort itself out?

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

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Jesse Thompson]

On 7/22/20 12:05 PM, John Levine wrote:
> I don't believe we have a charter to tell mailing list operators what
> to do, even if we believed, against all experience, that they would
> take our advice.

https://cyber.dhs.gov/bod/18-01/ references 
https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F

Who should be giving them advice?


> As may have been pointed out a few times, mailing lists had been
> serving their users perfectly well for decades before AOL and Yahoo made them
> DMARC roadkill.

Given that the email security industry's marketing now shames domain owners for 
not adopting DMARC, I think that the statute of limitations for AOL and Yahoo 
has passed.

Jesse

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

Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?

[Jesse Thompson]

On 7/21/20 6:05 AM, Douglas E. Foster wrote:
> I would like a better understanding of why MUAs are hiding or removing the 
> FROM address.
> 
> I have one mail store that formerly used hover-to-view, but recently changed 
> to always-show.   This was done in response to a client request on their 
> support forum.  I have never seen a user ask for the From address to be 
> hidden or removed.  I wonder if this trend is driven only by attempts to 
> optimize display space.   It would be a shame to weaken our protocols in 
> response to this trend, if the trend lacks a theoretical foundation.
> 
> I also wonder if the trust indicator research is being over-applied when it 
> is applied to the From Address.    From Address is a unique identifier, while 
> Friendly Name is not.   A trust indicator is like putting a green check mark 
> next to the From Address as a trust indicator.   They have different levels 
> of relevance.   
> 
> One attack method steals a contact list, then emails people in that contact 
> list using friendly names of others in that list.   Hiding the From Address 
> plays into that attack.
> 
> This trust-indicator research also promotes despair.  The conclusion is that 
> users process information poorly.   This result then becomes an excuse to 
> withhold information from those users, or to allow misleading information to 
> be presented to them.    I am not convinced that those are appropriate 
> responses.   "Never" is a hard thing to prove.  So it is risky to say users 
> "Never" use available information correctly, and "cannot be taught" to do 
> better.
> 
> Attack filtering is designed on a layered defense and a sequence of 
> probabilities:
> 
>   * What is the probability that this attack will get through my spam filter?
>   * What is the probability that the user will read the message?
>   * What is the probability that the user will click on the hostile link?
>   * What is the probability that my web filter will allow access to the 
> hostile website?
>   * What is the probability that the web filter will allow the attack to be 
> downloaded?
>   * What is the probability that my antivirus program will allow the attack 
> to proceed?
> 
> The goal is to decrease the probability of a wrong decision at each point in 
> the process.   All I need is for some people to act smarter on some occasions 
> in response to some available clue.   But this cannot happen if the clue is 
> not provided..

I like this way of thinking, and it seems like a good time to mention the 
following anecdote for the sake of the "end-users can't make security 
decisions" argument...

Specifically to address BEC we strip the friendly from (at our MTA gateways 
prior to ingestion to O365) conditionally (one example: from domains of free 
email providers) to force the MUA (Outlook and everything else) to show the 
From address.  

It works because now the victims just see "wisc.edu.provos...@gmail.com" 
instead of "Office of the Provost" and are more likely to consider the message 
hostile, less likely to click on the weird link, less likely to buy gift cards, 
and so on.  

I can count on one finger how many people have noticed that we're doing it (it 
wasn't an end-user, but it was our CRM team who uses friendly from to soft 
match on contacts) for a population of 150,000 mailboxes.  Meanwhile, we get 
very few people claiming that we aren't somewhat mitigating BEC scams.

Note that other institutions are tagging Subjects and bodies with EXTERNAL 
warnings, either to all external sourced email or based on some conditional 
rules, but they are not directly addressing the display name spoofing itself.  
I suspect that people learn to ignore those warnings over time and still fall 
victim to some well crafted scams from a spoofed VIP in their organization.  

I can't say with certainty which tactic works better (DKIM signature breakage 
is a wash), but I think forcing the MUA to reveal the sender's identity is more 
effective, less disruptive, and dovetails nicely with DMARC and the security 
marketing of the DMARC vendors.

Jesse

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

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Jesse Thompson]

On 7/20/20 7:55 AM, Douglas E. Foster wrote:
> I am advocating for MLMs to stop spoofing and make their peace with DMARC.

Maybe the recommendation should be that MLMs (or any ESP, for that matter) 
should never send as a domain they do not directly own unless it's authorized 
to send aligned mail as that domain.  (I say this as I have a distinguished PhD 
(not of CS) complaining to me that when he sends spoofed email from his Gmail 
account the messages go into spam because of DMARC.  Why do these ESPs even 
allow it in the first place, putting the domain owner's decision to adopt DMARC 
as the boogieman?)

The DMARC conditional rewriting logic that the MLM providers implement inhibits 
larger DMARC adoption because it segregates people into two camps, based solely 
on their domain owner's stance towards DMARC.  If a large enough group of 
stakeholders fall into the camp of "this domain I'm using to subscribe to lists 
isn't and should never be subjected to DMARC rewriting", they will push back on 
the domain owner's attempts to publish DMARC.

Maybe this ties back into the DMARCbis discussion about pct=0.  We use pct=0 
specifically to reduce end-user confusion about MLM rewriting behavior.  Could 
the behavior induced by pct=0 be the default, somehow, rather than p=none?

Jesse

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

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Jesse Thompson]

On 7/19/20 1:33 PM, dcroc...@gmail.com wrote:
> The essential point that needs to be made is that standards like this MUST 
> NOT be cast in terms of what end users will do.  In practical terms, this 
> work has nothing to do with end users.  Really.  Nothing.
> 
> To the extent that anyone wants to make an affirmative claim that end-users 
> /are/ relevant to this work, they need to lay that case out clearly, 
> carefully, and with material that provides objective support.(*)

I'll take a shot (admittedly, I'm having trouble keeping up with all of the 
points that have been made):

We're migrating 30,000 lists, of various types/use cases, from a MLM provider 
that is DMARC-ignorant to one that munges the From.  It rewrites the 
friendly-From in addition to the From address (this touches on Laura's point 
that even though some/most MUAs hide the domain, recipients still *see* 
something different)

We have a DMARC policy published for our 500ish domains, and an increasing 
number of the domains of our external list members are publishing DMARC.  DMARC 
enforcement (outside of our control) is also increasing - which motivates us to 
accelerate our transition to the DMARC-friendly MLM platform (one that rewrites 
the From)
 
** We have had many complaints from users about the From munging **

I could try to quantify, if that's the only way to prove the point that 
end-users matter and are relevant to this conversation.

It calls into question whether we (or any domain) should publish DMARC 
policies.  Gmail.com doesn't publish a DMARC policy, after all, and many people 
(such as some on this list) are using gmail.com to subscribe to lists, and they 
don't have to suffer the consequences of DMARC.  

Why should the rest of end-users suffer?  (some might say)

Granted, we are a university.  Maybe these are just faculty being 
hyper-sensitive to how their messages are appearing to their peers/students.  
But isn't that enough evidence that end-users *are* relevant?  With time, maybe 
we can change these end-user expectations, and From rewriting will be the new 
reality that people will accept.

The To-rewrite strategy seems interesting, in a "From-rewriting is here to 
stay" assumed world, to force MUA behavior and to help mitigate the 
auto-collecting address problem.

I think that draft-kucherawy-dkim-transform-02 is getting at what I was 
originally thinking.  In my opinion, MLMs will *always* need to munge, because 
they will never know if an arbitrary receiver will trust their non-munged mail. 
 Giving the receivers a way to un-munge (if they can and/or want and/or trust) 
would be a productive path forward out of this situation.

I think that we just have to agree that From-munging by MLMs is a permanent 
reality.  It needs to be documented more prominently (and promoted as part of 
the DMARC marketing) so that implementations are more consistent, so that 
un-munging tactics and/or MUA behavior can be consistently implemented.

Jesse

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

Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers

[Jesse Thompson]

On 6/29/20 4:18 AM, Alessandro Vesely wrote:
> Hi all,
> 
> I mentioned setting To: author instead of From: author-like, near the bottom 
> of a message[*] a week ago, but missed any WG comments on it.  That setting 
> would result if I run a mailing list "by hand", using a normal email client.  
> I'd hit reply and then add a bunch of Bcc:'s.  Of course, a suitable template 
> would insert a subject tag instead of "Re:", et cetera.
> 
> It'd be a cleaner solution than From: rewriting, inasmuch as it saves the 
> association between display names and addresses, for the sake of address 
> books consistency.  The anomaly of seeing authors in To: fields, with some 
> getting used to it, may even become a distinguished characteristic of 
> indirect mail flows.
> 
> How unbearable would that be?  And why?  Maybe some comments on this subject 
> can bring out some more details about the rightness or wrongness of the 
> various flavors of From: rewriting.

If nothing else changes; as in: MLMs have to keep promoting the use of From 
munging to their list operators, then I think it would be useful for these MLM 
to also offer (and perhaps default-to-ON if it works well in practice) your 
idea of replacing the To with the author during the munging process.

It would increase the odds that the author will be added to the recipient's 
address book, either manually, or via auto-collection by MUAs when they 
Reply-all (I believe that most MUAs will include the To in the recipient list 
if it differs from the user's own address)

Recipients (and individual list operators) may still complain about the From 
munging, but I like your line of reasoning of getting people used to 
"distinguished characteristic of indirect mail flows".  

Recipients will still be saddled with "author via listname" polluting their 
address books (via address auto-collection).  This idea doesn't solve that 
problem.

Jesse

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

Re: [dmarc-ietf] What if... Sender:

[Jesse Thompson]

On 6/23/20 1:49 PM, dcroc...@gmail.com wrote:
> So... what if DMARC's semantic were really for the Sender: field?  If a 
> message has no separate Sender: field, then of course the domain in the From: 
> field is used.

Wouldn't MUAs need to consistently display Sender?

Jesse

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jesse Thompson]

On 6/22/20 6:23 AM, Alessandro Vesely wrote:
> The fact that it cannot be set by a MUA implies Sender: already lost
> its menial meaning.  So it became a Mediator sort of thing.  This list
> sets it to "dmarc" .  Does anybody use it, or
> ever happened o take a look at it?

Yes, and I assume that's partially why the OP (who I was posting on behalf of) 
brought this Sender dilemma up in the first place.

Outlook on the Web displays:

dmarc  on behalf of dcroc...@gmail.com

and for those domains that have DMARC policies

dmarc  on behalf of 
todd.herr=40valimail@dmarc.ietf.org

Jesse

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jesse Thompson]

On 6/17/20 4:23 AM, Alessandro Vesely wrote:
> On Mon 15/Jun/2020 20:27:08 +0200 Scott Kitterman wrote:
>> On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote:
>>
>>> Even if you ignore my line of reasoning, I think that Ale made in the OP a
>>> compelling case that the practice of From rewriting is here to stay.
>>
>> As a practical matter, that's certainly true for the short to medium term, 
>> but
>> it doesn't follow that the IETF should standardize the practice.
> 
> 
> There are a few shortcomings of From: rewriting, which could be mitigated 
> adopting suitable conventions.  For example, MUAs' replying to author, or 
> storing rewritten addresses in address books.
> 
> As evidenced in the page cited[*], methods 1.* are characterized by being MLM 
> side workarounds[†].  That is, they can be applied unilaterally, without 
> collaboration nor mutual support.  A state of affairs dictated by the lack of 
> standardization.
> 
> Now, if we make a semantic effort, we must recognize that the address of 
> From: as a matter of fact refers to the "managing editor" of the 
> corresponding mail flow, whereas the display name may indicate the actual 
> author.  To say nothing of the Sender: field, which wasn't designed for that 
> role anyway.  That's how email has evolved after introducing authentication.  
> I'd hope rfc5322bis will recognize those changes.  Meanwhile, if we gather 
> consensus on how to do it better, it'd be fair to write it down, no?

There at least needs to be a consensus and an official-looking place that we 
can point intermediaries when they're getting hit by the DMARC train; as policy 
publication and enforcement accelerates.  A M3AAWG BCP, perhaps?

Some MLM operators think that setting the Sender header is recommended/good 
enough.  Some MUAs display the Sender instead of the From if it's set, which is 
why I think some people think it's equivalent to changing the From header.  
That wiki[*] doesn't even mention the Sender header, so it doesn't really serve 
as a mechanism to dissuade the notion.

If there is no consensus on a single recommendation, then perhaps there needs 
to be more than one recommendation articulated in a preferential, guided, 
fashion:
1) If 100% of receivers will trust ARC from the intermediary - do X
2) If DKIM signing and intermediary survival is 100% - do Y
3) Else, do Z
etc...
Along with recommendations for each party regarding what they should do in each 
situation. 

Those of us who are opinionated about this topic can focus our arguments on the 
order/criteria/nuances of the recommendations rather than trying to agree on a 
single one.

The main benefit to making the recommendation(s) more standard is that it will 
serve to help intermediaries configure things in a "DMARC compatible" fashion 
and justify any change as necessary to skeptical stakeholders.  It will also 
serve as a way for IT staff to evaluate alternative software/services if they 
are considering upgrades vs. replacement.


> [†] Hm... except for 1.9 TPA.  It should be moved downward, methinks. 

Seems in the Cooperative category.  Maybe there needs to be a distinction 
between Sending (user/MSA vs domain owner?) vs Intermediary solutions?  Or a 
matrix to capture different qualities.  I don't know, there's a lot about that 
doc that makes it hard for an average person even know where to start tackling 
the problem.  Most people don't have years of experience in the email domain to 
understand all of the nuances.

Jesse

[*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jesse Thompson]

On 6/15/20 12:44 PM, John Levine wrote:
> In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write:
> They both claim they're working on ARC.
> 
>> So, solution 1.3 has been naturally selected.  Does it need to be 
>> standardized, or is a BCP good enough? 
>> I'd still like to see a solution for receivers to "un-munge" trustworthy 
>> messages in a safe and
>> consistent way.  Is that where ARC comes in?
> 
> No.  ARC lets mail systems accept list mail without munging.

How will a random intermediary know if random destination has implemented ARC 
and will trust their claim?  Even domains hosted by SaaS providers will have 
their own ARC reputation to manage, and might have to do things like configure 
munging on a per-recipient/domain basis, assuming the SaaS provider grants that 
level of control.  It's safer and easier to munge everything.  

Even if you ignore my line of reasoning, I think that Ale made in the OP a 
compelling case that the practice of From rewriting is here to stay.

Jesse

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jesse Thompson]

On 6/15/20 2:33 AM, Alessandro Vesely wrote:
> Let me quote a list of nineteen usable solutions:
> 
>     1 Sending side workarounds
>     1.1 Exclude domains that require alignment
>     1.2 Turn off all message modifications
>     1.3 Replace address with a generic one
>     1.4 Add fixed string such as .invalid to addresses
>     1.5 Rewrite addresses to forwarding addresses
>     1.6 Message wrapping
>     1.7 Mandatory digests
>     1.8 Ignore DMARC bounces
>     1.9 Third Party Authorization
>     2 Recipient workarounds
>     2.1 Forwarder whitelist
>     3 Cooperative solutions
>     3.1 Shared whitelist
>     3.2 Per sender whitelist
>     3.3 Original-Authentication-Results header
>     3.4 Forwarding token
>     4 Authorization approaches
>     4.1 Authenticated Received Chain (ARC)
>     4.2 Signing key delegation
>     4.3 Relay through author domain server
>     4.4 Relay one copy through author domain server
>     4.5 Have author domains sign camera-ready posts
>     [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail]
> 
> That page hasn't been updated since 2016.  I don't think we can devise any 
> new solution now.  There's been a natural selection.  Solution 1.3 prevailed, 
> with a minority of lists opting for 1.2.  Let's face facts.

Precisely.  Let's work from a basis of reality.

I'm representing an EDU here.  Mailing lists are still heavily used in EDU for 
cross-institution and cross-sector collaboration.  They aren't going to be 
replaced by web forums or Yammer (or whatever corporate enterprise aspire to 
do) because faculty are open and collaborative by their nature.

We have over $1bn in research expenditures, most of which are funded by federal 
grants, and so we need to receive mail (sometimes indirectly) from federal 
agencies who are adhering to BOD 18-01.  A growing number of universities are 
publishing DMARC policies, and an unknown but presumably growing number of 
universities and agencies are enforcing DMARC policies for other domains.  It's 
becoming increasingly difficult to ignore DMARC.

Given that Microsoft and Google have essentially soaked up the entire EDU email 
market (hey, the price is right), let's say for sake of argument[*] that most 
EDUs are faced with 2 choices for their MLM:  Google Groups and Microsoft 365 
Groups.

Microsoft's solution: 1.2 (conditionally, based on some logic, it seems)
Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or p=reject)

We can delve into *why*, but the reality is that we have failed with using 
Microsoft 365 Groups with external collaborators from domains that have adopted 
DMARC *even though* we use Microsoft 365 for mailbox hosting, and we heavily 
use Microsoft 365 Groups for internal collaboration.  

Given that choice in this context, I believe that Google Groups will be chosen 
as their MLM by anyone taking DMARC into consideration.  I would not be 
surprised if Microsoft falls in line with solution 1.3.

So, solution 1.3 has been naturally selected.  Does it need to be standardized, 
or is a BCP good enough?  I'd still like to see a solution for receivers to 
"un-munge" trustworthy messages in a safe and consistent way.  Is that where 
ARC comes in?

Thanks,
Jesse

[*] Glossing over the fact that a university is not a single entity.  There are 
hundreds of entities within a university that all may individually choose their 
own solution.

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

[dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

[Jesse Thompson]

I'm relaying these DMARC questions/concerns on behalf of an email admin at 
another university.  I quickly searched this list's archives for the Sender 
header vs DMARC alignment issue and don't see much aside from a conversation in 
May 2015.  Is it worth further discussion and/or an issue in Trac?  I think I 
know the answer to the second concern, but I'll defer to people more adept at 
explaining the nuance.

See below...

Thanks,
Jesse Thompson
UW-Madison

"
I don't see on the list of issues the most fundamental problem of DMARC, namely 
that it conflicts with RFC 5322 on the use of the From and Sender header fields 
[1] and possibly with RFC 6326 as to the significance of DKIM fail [2].  The 
former is the more serious problem. Making DMARC alignment part of a standard 
for Internet messages requires a revision of RFC 5322. I'd love to see this 
resolved.

[1]
The "From:" field specifies the author(s) of the message,
   that is, the mailbox(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message.

[2]
signature verification failure does not force rejection of the message;
"
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc