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

[Douglas Foster]

Thank you Jesse for your comments.   You are focusing on the ESP problem,
which I had not given much thought.

ESP messages

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.

ESPs develop a reputation with me based on their ability to vet their
clients appropriately.   ConstantContact seems to be mostly free of
malicious content, so previously-unseen domains are delivered as long as
they pass content filtering.   SendGrid has not done so well.
 Previously-unseen domains are delivered to quarantine until I can vet them
individually.   One ESP has such a high rate of garbage that I have blocked
them completely, but that is rare.  Hopefully your organization is one that
vets its clients pretty well.

I tend to assume that the most sophisticated evaluators are doing something
similar, but apparently not, or your organization would not be stressing
over how to handle the DMARC-affected clients.

(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.)

Mailbox provider accounts and ESP accounts are reminders how overwhelming
it is to attempt a reputation system based on every sender.   The set of
all identifiers is nearly infinite.  But I am trying nonetheless.

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


Forwarded Messages

I differ from most of the group because I believe the problem with
forwarded messages needs to be handled between the forwarder and the
evaluator, not the originator.   The solution also needs to be based on
message stream characteristics.  It is inefficient to evaluate every
message individually as if similar ones had never been seen before.

My Stream-Info idea is most directly comparable to (or competitive with)
ARC.   ARC is a way for the forwarder to provide information that it hopes
the evaluator will use to ignore sender authentication failures caused by
changes in transit.The right to forward-with-changes is essentially a
privilege escalation, and privilege escalation needs a well-delimited scope
(which messages are included) and justification (why are we doing this) as
well as trust (I believe you will not abuse your privilege.)   The
privilege also needs to be granted by the party most likely to reject the
message, and that is of course the evaluator, not the originator.

The stream and its identifier characteristics are intended to create a
mutually-agreed scope.  The "operating principles" section is part of the
justification for the request:   "You can trust me, because I am doing
these good things"   Those things cannot be verified on a single message,
but they can be inferentially validated when all messages in the message
stream are consistent with the asserted principles.

I don't think ARC provides enough scope definition, does not provide enough
justification, and it does not define a message stream.   Finally, it lacks
a feedback mechanism so it cannot solve the From-munging problem.

The Stream-Info data could reasonably include a feedback address, which
would also have a formal structure for automated processing.   For
forwarded traffic, the two feedback types that immediately come to mind are:
- Trust granted:   You do not need to Mung addresses for this message
stream.
- Cease and Desist:   Our account user2@domain1 does not want messages to
be forwarded from your account user1@domain1.
Both types of messages would be sent only a few times, and intermittently,
not on every message.

Doug Foster

On Sat, Apr 1, 2023 at 9:04 PM Jesse Thompson  wrote:

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

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 
relatio

Re: [dmarc-ietf] 5322.From Header Rewrite specification

[John Levine]

It appears that Todd Herr   said:
>RFC 7960 isn't a specification for rewriting 5322.From per se, but section
>4.1.3.1 discusses the topic of rewriting that header, including this text:
>
>   Another option for ReSenders is to rewrite the RFC5322
>.From header
>   field address to a locally controlled address that will be forwarded
>   back to the original sender (subject to its own ReSender forwarding
>   mitigations).

This is my rewrite hack which approximately nobody does. I do it on my
handful of lists, the IETF does with custom code, and commercial
LISTSERV has an option to rewrite the address into @list.domain.
To do so, the list software has to be able to futz with the
configuration of the underlying MTA to manage the forwarding, and
places running list software like Mailman and Sympa on top of postfix
can't do that. (I think LISTSERV has a built in MTA but it is quite
expensive.)

What it does *not* say is to put the list address in the From header
which is the ugly hack that list software has resorted to.  See endless
prior discussions of why that makes lists worse.

Barry is right. If you don't care about interoperability, you can and
will do whatever you want, but if you do, you don't set a DMARC policy
on domains that send mail from people.

R's,
John

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

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 issue

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

[Barry Leiba]

We simply fundamentally disagree here.

Barry

On Sun, Apr 2, 2023 at 12:33 AM Dotzero  wrote:
>
>
>
> On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba  wrote:
>>
>> > If we use SHOULD NOT, as you suggest, there's an implication that there 
>> > might be a valid reason for
>> > non-transactional mail to use "p=reject".  Are we okay with that?
>>
>> When do folks get to line up so they can plead the case for their reason?
>>
>> I, for one, am not.  We often use "SHOULD NOT" incorrectly to mean
>> "MUST NOT, but we know it will be widely violated so we're saying
>> SHOULD NOT".  We need to stop doing that.
>
>
> A "standard" which is widely violated is not a standard. To publish a 
> standard one knows is and will be widely violated is a bit of a fool's 
> errand, n'est-ce pas? We need to stop doing that.
>
> Michael Hammer

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

[Douglas Foster]

It has been hard to miss the fact of near-zero participation from mailbox
providers, cloud-based email filtering services, and filtering software
vendors -- essentially everyone involved in 90+ percent of all email
filtering.   We do better at acquiring DNS statistics than at acquiring
inbound mail statistics.

If we are writing instructions on how to filter email well, do any of these
experts want our help?   If we ever finish this process, will it matter to
the entities who we presume will value our advice?

DF

On Sat, Apr 1, 2023, 11:33 AM Dotzero  wrote:

>
>
> On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba 
> wrote:
>
>> > If we use SHOULD NOT, as you suggest, there's an implication that there
>> might be a valid reason for
>> > non-transactional mail to use "p=reject".  Are we okay with that?
>>
>> When do folks get to line up so they can plead the case for their reason?
>>
>> I, for one, am not.  We often use "SHOULD NOT" incorrectly to mean
>> "MUST NOT, but we know it will be widely violated so we're saying
>> SHOULD NOT".  We need to stop doing that.
>>
>
> A "standard" which is widely violated is not a standard. To publish a
> standard one knows is and will be widely violated is a bit of a fool's
> errand, n'est-ce pas? We need to stop doing that.
>
> Michael Hammer
>
___
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?

[Hector Santos]

> On Apr 1, 2023, at 6:29 AM, Scott Kitterman  wrote:
> 
> I think that's not quite it.  
> 
> There is clearly a valid reason.  There are domains that value the security 
> properties of p=reject more highly than the negative effects to 
> interoperability.

For many years we knew this would happen and it took Yahoo.com 
 to wake everyone up on this.  Obviously they didn’t ’t care 
and for good reasons — receivers were beginning to flat-out block all yahoo.com 
as one of the spam pollutions around.  Same with aol.com , 
same with hotmail.com , etc.  Flat out just block them.

So yahoo going hard with SPF and ADSP and then DMARC was a good thing.  I began 
to tell old folks still using yahoo it is now safe to use yahoo.com for high 
value services (banking, etc).

But Yahoo needs to look at the ATPS resigners to support other domains in the 
market.


—
HLS___
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?

[Hector Santos]

> On Apr 1, 2023, at 11:33 AM, Dotzero  wrote:
> 
> 
> 
> On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba  > wrote:
>> > If we use SHOULD NOT, as you suggest, there's an implication that there 
>> > might be a valid reason for
>> > non-transactional mail to use "p=reject".  Are we okay with that?
>> 
>> When do folks get to line up so they can plead the case for their reason?
>> 
>> I, for one, am not.  We often use "SHOULD NOT" incorrectly to mean
>> "MUST NOT, but we know it will be widely violated so we're saying
>> SHOULD NOT".  We need to stop doing that.
> 
> A "standard" which is widely violated is not a standard. To publish a 
> standard one knows is and will be widely violated is a bit of a fool's 
> errand, n'est-ce pas? We need to stop doing that.


Maybe because DMARC is not a standard.  Never was one. It is violated because 
it is protocol incomplete. It was not ready for prime time.  It’s an 
informational status document for reporting.  No reporting. No adoption. I 
would have a hard time supporting DMARCbis as a standard track item with it 
huge email problems and lacking an ATPS concept. (See ADSP)

Any node in the community can completely ignore SPF, DKIM, etc and survive.  If 
DMARC is trying to change that, I do not believe this is good with an ATPS 
concept.

What we need to drive home is the fact this is not a plug and play protocol.  
You can rest assured to have problems when using a strong 1st party only policy 
in public and now increasily, in private too when the ESP is not capable of 
supporting an authorized MTA forwarder.   It lacks the tools,  It needs ATPS.

DMARC firms need to do better job of making sure their customer’s domain are 
clean before using p=reject. The reporting will help determine if moving from 
p=none to p=reject/quarantine will not produce false positives, but even if the 
reporting is capable of exposing a false positive reject friendly resigner,  it 
is not capable of authorizing the friendly resigners. DMARC lacks ATPS support 
for ESPs to leverage.

—
HLS___
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?

[Hector Santos]

> On Apr 1, 2023, at 11:25 AM, Dotzero  wrote:

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


I would venture that many domain owners (including a few of customers) do not 
know anything about DMARC (despite the advanced marketing hype) and their mail 
host are increasingly providing DMARC services on their behalf.

—
HLS

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

[Hector Santos]

> On Apr 1, 2023, at 7:17 AM, Jim Fenton  wrote:
> 
> Not picking on Murray here, but his message was the most recent that talked 
> about p=reject with respect to non-transactional email:
> 
> On 1 Apr 2023, at 15:53, Murray S. Kucherawy wrote:
> 
>> If we use SHOULD NOT, as you suggest, there's an implication that there
>> might be a valid reason for non-transactional mail to use "p=reject".  Are
>> we okay with that?
> 
> We shouldn’t be assuming that mailing lists are the only cause of breakage 
> for DMARC, and that transactional email is unimpacted by a p=reject policy.
> 
> Some people use email forwarders so that they can have an email address 
> that’s consistent if they change the email provider where their email is 
> actually received. Sometimes they do this for “branding” reasons as well, 
> such as to indicate their association with an organization or alumni 
> association. Some of these email providers break DKIM signatures along the 
> way.

+1

> 
> I have several such forwarding addresses, one of which is @alum.mit.edu, 
> which breaks my DKIM signatures when I send a message to myself. If I used 
> that address to receive transactional email from a domain with p=reject, and 
> if my actual email provider enforced DMARC, I might not receive transactional 
> email.
> 

How many reader/writers (MUAs) do you use?  

I have almost scenario possible. With hosted domains, the owners like to use 
the MUA of an ESPi.e. gmail to consolidate their MUA activity under one 
reader/writer.  This means forwarding mail to the ESP for most immediate 
notification.   This was fine until the ESP began to honor DMARC restrictive 
policies and the forwarded mail is either rejected or put into a spam box.  The 
domain authorized MTA is now penalized with dubious and false positive/negative 
reputation blacklisting creating an increase cost on support and cleanup.  

Among solutions, advising a customer to move their domain hosting to their MUA 
ESP hosting services is an anti-trust, anti-competition non-starter.  Advising 
them to use their ESP mail pickup facility, i.e. pop3, is the solution — 
delayed delivery but it solves the problem for restrictive DMARC domains.

Among the top ESP domain policies:

hotmail.com p=none
yahoo.com   p=reject
gmail.com   p=none sp=quarantine
aol.com p=reject
outlook.com p=none sp=quarantine
msn.com p=none sp=quarantine
bellsouth.net   p=none sp=quarantine
verizon.net p=reject

Verizon.net, aol, bellsouth.net  are hosted by yahoo.com 
 as an MX and HTML MUA. 


—
HLS



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

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

[Scott Kitterman]

On Saturday, April 1, 2023 11:08:00 AM EDT Dotzero wrote:
...
> If you feel this strongly, where is the record of your advocating for "MUST
> NOT" for domains with end users implementing an SPF policy ending in
> "-all"? That certainly breaks interoperability through mailing lists and
> various forwarders if honored by validators.
...

Since I was arguing elsewhere in the thread about being the pedantic nerd who 
won't shut about stuff everyone else it sick of hearing about ...

I don't believe this is accurate.  SPF as defined by the IETF (experimentally 
in RFC 4408 and standards track in RFC 7208) focuses entirely on sender policy 
(thus the name, though I still prefer the original Sender Permitted From).  
Nowhere does it specify receiver actions (I personally thought this was a bad 
idea in 2007, but I see the wisdom of it now).  DMARC made a different choice, 
so it has to live with the implications of that decision.

Every mailing list I recall using has set it's own Mail From, so the SPF of 
the originator doesn't come into play.  The issue with SPF and mailing lists 
only arises when using SPF results as an input to DMARC.  That's a DMARC 
issue, not an SPF issue.

Mis-configuration of SPF can (and certainly has) caused problems with 
forwarders.  I think that RFC 7208 is reasonably clear about where in the 
architecture it is appropriate to check SPF results.  While this was a 
significant issue early in SPF's deployment, I think it's reasonably well 
understood now.  This is also not like DMARC.  The mitigation for SPF issues 
due to receiver configured forwarding can and should be addressed by how 
receivers check SPF.  There are no issues that can only be solved by changes 
the disturb long established practice (SRS is an option that mediators can 
use, but IMO that's a work-around for receivers with architectural issues).  
The only way to address similar issues with DMARC is with substantial, 
disruptive changes.

Your "if honored by validators" is the key point architecturally.  RFC 7208 is 
pretty clear about where in the architecture the honoring needs to be done and 
if that guidance is followed, there aren't significant issues for forwarders.

I've published an SPF record with -all in my domains since 2004.  I get 
rejection notifications once every several years, so it's not problem free, but 
it's not nearly the issue that people were worried about a decade and a half 
ago.  While there are superficial similarities between the interoperability 
concerns for SPF and DMARC, I think the are entirely that, superficial.

Scott K


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

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

[Benny Pedersen]

Dotzero skrev den 2023-04-01 17:25:


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


turn client domains into diggest mode on maillist if dmarc policy from 
sender is reject, this will not break anything in dmarc, or even dkim


ps i sav ietf had removed dkim selector in dmarc reporting, on 
consistens or just error ?


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

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

[Dotzero]

Yours is the most reasoned argument in support of "MUST NOT" vs "SHOULD
NOT", even if I disagree with you. You recognize the issues involved with
going the "MUST NOT" path even though you ultimately support it.

Michael Hammer


On Sat, Apr 1, 2023 at 6:30 AM Scott Kitterman  wrote:

>
>
> On April 1, 2023 6:53:13 AM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> >On Fri, Mar 31, 2023 at 5:48 PM Dotzero  wrote:
> >
> >>
> >>
> >>
> >>>
> >>>
> >>> But when you deploy DMARC and force lists to change the way they work,
> >>> the experience is altered in a way users perceive as a degradation.
> We're
> >>> taking something significant away, and the benefit is not perceived to
> be
> >>> worthwhile.
> >>>
> >>
> >> It may or may not be true for any given situation. You are assuming
> facts
> >> not in evidence. There are end users who do not subscribe to email
> lists.
> >> My wife is one such person. If users overall were truly upset as you
> >> indicated, we would have expected users to flee en masse from the large
> >> free webmail providers after they switched to p=reject. And yet they are
> >> still around providing email services to millions and millions of users.
> >>
> >
> >Oh, the facts are very much in evidence.  There's no need to assume
> >anything.
> >
> >Hang around any IETF meeting for a few hours.  It may not take even that
> >long for someone to ask when the  DMARC problem is going to be
> >fixed.
> >
> >I guess the point that I'm trying to make is that reality is nowhere near
> >> as neat and simple as some might make things out to be.
> >>
> >> I would support SHOULD NOT but I think MUST NOT is a bridge too far. It
> >> falls into the category of King Canute commanding the waters to retreat.
> >> Publishing a standard (MUST NOT) which you know  will ignore
> >> reduces the credibility of a standards organization which does so.
> SHOULD
> >> NOT with an admonishment and explanation as to potential consequences
> makes
> >> more sense to me.
> >>
> >
> >Quoting from RFC 2119 which defines the all-caps key words we've come to
> >know and love:
> >
> >4 . SHOULD NOT
> >This phrase, or the phrase "NOT RECOMMENDED" mean that
> >   there may exist valid reasons in particular circumstances when the
> >   particular behavior is acceptable or even useful, but the full
> >   implications should be understood and the case carefully weighed
> >   before implementing any behavior described with this label.
> >
> >If we use SHOULD NOT, as you suggest, there's an implication that there
> >might be a valid reason for non-transactional mail to use "p=reject".  Are
> >we okay with that?
> >
> I think that's not quite it.
>
> There is clearly a valid reason.  There are domains that value the
> security properties of p=reject more highly than the negative effects to
> interoperability.
>
> The challenge for DMARC is that the understanding the "full implications"
> of such a choice is infeasible as the implications are not limited to the
> domain in question.  The choice to deploy p=reject for domains with users
> that use email in varied ways impacts the entire email ecosystem, not just
> the domain making the decision.
>
> Technically I don't think there's any question about the negative
> interoperability implications so MUST NOT [because there will be
> interoperability problems] is clearly accurate.  It's equally true that
> approximately no one is going to change their minds about publishing
> p=reject if the IETF puts MUST NOT in the DMARCbis RFC.  If we do it there
> will be, once again, people who point and laugh about how out of touch the
> IETF is with reality.
>
> As the meme says, technically correct is the best kind of correct.  I
> think it's the IETF's job to be the pedantic nerd who won't let go of an
> issue that everyone else is sick of hearing about, so we should stick with
> MUST NOT.  I also understand why that's profoundly unsatisfying for many.
>
> Scott K
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba  wrote:

> > If we use SHOULD NOT, as you suggest, there's an implication that there
> might be a valid reason for
> > non-transactional mail to use "p=reject".  Are we okay with that?
>
> When do folks get to line up so they can plead the case for their reason?
>
> I, for one, am not.  We often use "SHOULD NOT" incorrectly to mean
> "MUST NOT, but we know it will be widely violated so we're saying
> SHOULD NOT".  We need to stop doing that.
>

A "standard" which is widely violated is not a standard. To publish a
standard one knows is and will be widely violated is a bit of a fool's
errand, n'est-ce pas? We need to stop doing that.

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

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

[Dotzero]

On Fri, Mar 31, 2023 at 8:00 AM Barry Leiba  wrote:

> > Compare that with the move to https everywhere.  Having to get
> certificates and
> > encrypting and decrypting all stuff is certainly not an interoperability
> > improvement.
>
> Say WHAT?  There's no interoperability issue there.
>
> There's some effort involved in doing it, and one has to weigh that
> effort against what one gets out of it.  But it interoperates just
> fine once you make the effort.  It's not the same thing at all.
>
> Barry
>

 Hmm, let's apply this to DMARC.

" But it interoperates just fine once you make the effort."

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

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

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

[Dotzero]

On Sat, Apr 1, 2023 at 2:53 AM Murray S. Kucherawy 
wrote:

> On Fri, Mar 31, 2023 at 5:48 PM Dotzero  wrote:
>
>>
>>
>>
>>>
>>>
>>> But when you deploy DMARC and force lists to change the way they work,
>>> the experience is altered in a way users perceive as a degradation.  We're
>>> taking something significant away, and the benefit is not perceived to be
>>> worthwhile.
>>>
>>
You invoked "end user experience" in your post I responded to.

" When you change the URI scheme you're using from "http" to "https",
there's some complexity introduced in the implementations, but your
experience as a consumer is largely the same"

The end user experience wasn't exactly the same. In many cases end users
couldn't access websites or couldn't visit them without clicking through
warning screens that the website is insecure and/or forced to explicitly
"approve" those sites. That is hardly "largely the same" experience. Sure,
years after that time frame things have settled down. It is convenient to
ignore or minimize what end users experienced during that transition. I'm
not a fan of domains with lots of end user accounts implementing p=reject
but I also recognize that in the real world things evolve.

>
>> It may or may not be true for any given situation. You are assuming facts
>> not in evidence. There are end users who do not subscribe to email lists.
>> My wife is one such person. If users overall were truly upset as you
>> indicated, we would have expected users to flee en masse from the large
>> free webmail providers after they switched to p=reject. And yet they are
>> still around providing email services to millions and millions of users.
>>
>
> Oh, the facts are very much in evidence.  There's no need to assume
> anything.
>
> Hang around any IETF meeting for a few hours.  It may not take even that
> long for someone to ask when the  DMARC problem is going to be
> fixed.
>

And presumably you'll also find people asking when the  placing
of all that crap in TXT records is going to be fixed.


>
> I guess the point that I'm trying to make is that reality is nowhere near
>> as neat and simple as some might make things out to be.
>>
>> I would support SHOULD NOT but I think MUST NOT is a bridge too far. It
>> falls into the category of King Canute commanding the waters to retreat.
>> Publishing a standard (MUST NOT) which you know  will ignore
>> reduces the credibility of a standards organization which does so. SHOULD
>> NOT with an admonishment and explanation as to potential consequences makes
>> more sense to me.
>>
>
> Quoting from RFC 2119 which defines the all-caps key words we've come to
> know and love:
>
> 4 . SHOULD NOT   This 
> phrase, or the phrase "NOT RECOMMENDED" mean that
>there may exist valid reasons in particular circumstances when the
>particular behavior is acceptable or even useful, but the full
>implications should be understood and the case carefully weighed
>before implementing any behavior described with this label.
>
> If we use SHOULD NOT, as you suggest, there's an implication that there
> might be a valid reason for non-transactional mail to use "p=reject".  Are
> we okay with that?
>

Looking at the real world, I'm ok with that rather than splitting hairs. If
a domain sends a million transactional emails a day, has 5 end user
accounts which are subscribed to a handful of maillists which all accept
their mail and which starts experiencing significant direct domain abuse,
are you seriously suggesting they MUST NOT implement a p=reject policy?
Would you stand in front of them, wag your finger and say to their face,
"Thou must not!"? What alternate solutions would you offer them? Are you
planning on being the "standards police"? If not, whom do you propose
should be the "standards police"? Will offenders be banished from the
Internet? If there is little or no consequence for violating (a generic,
not you specifically Murray) YOUR mandate, what does it actually mean?
Perhaps maillists SHOULD reject mail from ALL domains with end users and
which publish a policy of p=reject. Why hasn't that been incorporated into
DMARCbis? If working group participants truly believe this to be anathema
to interoperability then they should be clamoring for incorporating such a
requirement.

If you feel this strongly, where is the record of your advocating for "MUST
NOT" for domains with end users implementing an SPF policy ending in
"-all"? That certainly breaks interoperability through mailing lists and
various forwarders if honored by validators. DMARC allows for a PASS if
either aligned DKIM or SPF validates, yet it does not require that a
sending domain implement both. Where is the hue and cry? Or is that hue and
cry only selective in what it targets? Are you going to propose that they
should be put on block lists if they aren't going to comply? How about ewe
include "Receivers and Validators MUST block Sending Domains which have end

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

[Douglas Foster]

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

Stream-Info: http://dmarc.listpracties.ietf.org.

Below are two examples of what information could be provided in a stream
info declaration.   A formal specification would be needed but is not
provided.

For the IETF Mailing List stream, those characteristics are:
- The message stream type is: Mailing List
- Identifier information:
   - SMTP MailFrom is always dmarc-boun...@ietf.org and produces SPF PASS
   - Messages are signed by ietf.org
   - HELO domain is ietf.org and can be forward-confirmed
   - Reverse DNS domain is ietf.org and can be forward-confirmed
   - ARC Sets are not added to forwarded messages.
- Operating Policies:
   - Every post is verified to the subscriber with DMARC or
challenge-response verification
   - From header is rewritten for messages with DMARC p=reject
   - Incoming messages are converted to text mode, and a footer is added,
so prior signatures are invalidated

For a simple user-to-user forward, the characteristics could be:
- The message stream type is: User Forward
- Identifier information:
   - Previous TO domain was example.com
   - SMTP MailFrom is SRS encoded version of the original sender
   - ARC Sets are added to forwarded messages
- Operating policies:
   - Messages are scanned for malware on a best-effort basis.
   - Content is not modified, so prior signatures are preserved, but not
all messages will have prior signatures


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

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

[Jim Fenton]

Not picking on Murray here, but his message was the most recent that talked 
about p=reject with respect to non-transactional email:

On 1 Apr 2023, at 15:53, Murray S. Kucherawy wrote:

> If we use SHOULD NOT, as you suggest, there's an implication that there
> might be a valid reason for non-transactional mail to use "p=reject".  Are
> we okay with that?

We shouldn’t be assuming that mailing lists are the only cause of breakage for 
DMARC, and that transactional email is unimpacted by a p=reject policy.

Some people use email forwarders so that they can have an email address that’s 
consistent if they change the email provider where their email is actually 
received. Sometimes they do this for “branding” reasons as well, such as to 
indicate their association with an organization or alumni association. Some of 
these email providers break DKIM signatures along the way.

I have several such forwarding addresses, one of which is @alum.mit.edu, which 
breaks my DKIM signatures when I send a message to myself. If I used that 
address to receive transactional email from a domain with p=reject, and if my 
actual email provider enforced DMARC, I might not receive transactional email.

-Jim

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

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

[Scott Kitterman]

On April 1, 2023 6:53:13 AM UTC, "Murray S. Kucherawy"  
wrote:
>On Fri, Mar 31, 2023 at 5:48 PM Dotzero  wrote:
>
>>
>>
>>
>>>
>>>
>>> But when you deploy DMARC and force lists to change the way they work,
>>> the experience is altered in a way users perceive as a degradation.  We're
>>> taking something significant away, and the benefit is not perceived to be
>>> worthwhile.
>>>
>>
>> It may or may not be true for any given situation. You are assuming facts
>> not in evidence. There are end users who do not subscribe to email lists.
>> My wife is one such person. If users overall were truly upset as you
>> indicated, we would have expected users to flee en masse from the large
>> free webmail providers after they switched to p=reject. And yet they are
>> still around providing email services to millions and millions of users.
>>
>
>Oh, the facts are very much in evidence.  There's no need to assume
>anything.
>
>Hang around any IETF meeting for a few hours.  It may not take even that
>long for someone to ask when the  DMARC problem is going to be
>fixed.
>
>I guess the point that I'm trying to make is that reality is nowhere near
>> as neat and simple as some might make things out to be.
>>
>> I would support SHOULD NOT but I think MUST NOT is a bridge too far. It
>> falls into the category of King Canute commanding the waters to retreat.
>> Publishing a standard (MUST NOT) which you know  will ignore
>> reduces the credibility of a standards organization which does so. SHOULD
>> NOT with an admonishment and explanation as to potential consequences makes
>> more sense to me.
>>
>
>Quoting from RFC 2119 which defines the all-caps key words we've come to
>know and love:
>
>4 . SHOULD NOT
>This phrase, or the phrase "NOT RECOMMENDED" mean that
>   there may exist valid reasons in particular circumstances when the
>   particular behavior is acceptable or even useful, but the full
>   implications should be understood and the case carefully weighed
>   before implementing any behavior described with this label.
>
>If we use SHOULD NOT, as you suggest, there's an implication that there
>might be a valid reason for non-transactional mail to use "p=reject".  Are
>we okay with that?
>
I think that's not quite it.  

There is clearly a valid reason.  There are domains that value the security 
properties of p=reject more highly than the negative effects to 
interoperability.  

The challenge for DMARC is that the understanding the "full implications" of 
such a choice is infeasible as the implications are not limited to the domain 
in question.  The choice to deploy p=reject for domains with users that use 
email in varied ways impacts the entire email ecosystem, not just the domain 
making the decision.

Technically I don't think there's any question about the negative 
interoperability implications so MUST NOT [because there will be 
interoperability problems] is clearly accurate.  It's equally true that 
approximately no one is going to change their minds about publishing p=reject 
if the IETF puts MUST NOT in the DMARCbis RFC.  If we do it there will be, once 
again, people who point and laugh about how out of touch the IETF is with 
reality.

As the meme says, technically correct is the best kind of correct.  I think 
it's the IETF's job to be the pedantic nerd who won't let go of an issue that 
everyone else is sick of hearing about, so we should stick with MUST NOT.  I 
also understand why that's profoundly unsatisfying for many.

Scott K

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

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

[Alessandro Vesely]

On Fri 31/Mar/2023 13:59:40 +0200 Barry Leiba wrote:

Compare that with the move to https everywhere.  Having to get certificates and
encrypting and decrypting all stuff is certainly not an interoperability
improvement.


Say WHAT?  There's no interoperability issue there.



Oldish software didn't have SSL support, or was unable to upgrade to the latest 
version of TLS, a moving target in that respect.


For publishers, getting a certificate implied expenses and getting into 
commercial agreement with a set of recognized providers.




There's some effort involved in doing it, and one has to weigh that
effort against what one gets out of it.  But it interoperates just
fine once you make the effort.  It's not the same thing at all.



There are experimental protocols and proposals.  If there is no recognized 
reputation providers, there are lots of DNSxLs.  If MLMs adopt the necessary 
changes and receivers set up whitelisting-after-subscription everything 
interoperates just fine.


Indeed, DMARC has been causing that disruption for several years now.  MLMs 
have adapted.  Useless to close the stable door after the horse has bolted.



Best
Ale
--






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

[Mark Alley]

Depending on the definition of "valid reason", is not "An organization
wants unauthenticated mail to be rejected" a valid reason? Although, with
the noted interoperability issues, I'm not sure if it qualifies.


On Sat, Apr 1, 2023, 1:53 AM Murray S. Kucherawy 
wrote:

> On Fri, Mar 31, 2023 at 5:48 PM Dotzero  wrote:
>
>>
>>
>>
>>>
>>>
>>> But when you deploy DMARC and force lists to change the way they work,
>>> the experience is altered in a way users perceive as a degradation.  We're
>>> taking something significant away, and the benefit is not perceived to be
>>> worthwhile.
>>>
>>
>> It may or may not be true for any given situation. You are assuming facts
>> not in evidence. There are end users who do not subscribe to email lists.
>> My wife is one such person. If users overall were truly upset as you
>> indicated, we would have expected users to flee en masse from the large
>> free webmail providers after they switched to p=reject. And yet they are
>> still around providing email services to millions and millions of users.
>>
>
> Oh, the facts are very much in evidence.  There's no need to assume
> anything.
>
> Hang around any IETF meeting for a few hours.  It may not take even that
> long for someone to ask when the  DMARC problem is going to be
> fixed.
>
> I guess the point that I'm trying to make is that reality is nowhere near
>> as neat and simple as some might make things out to be.
>>
>> I would support SHOULD NOT but I think MUST NOT is a bridge too far. It
>> falls into the category of King Canute commanding the waters to retreat.
>> Publishing a standard (MUST NOT) which you know  will ignore
>> reduces the credibility of a standards organization which does so. SHOULD
>> NOT with an admonishment and explanation as to potential consequences makes
>> more sense to me.
>>
>
> Quoting from RFC 2119 which defines the all-caps key words we've come to
> know and love:
>
> 4 . SHOULD NOT   This 
> phrase, or the phrase "NOT RECOMMENDED" mean that
>there may exist valid reasons in particular circumstances when the
>particular behavior is acceptable or even useful, but the full
>implications should be understood and the case carefully weighed
>before implementing any behavior described with this label.
>
> If we use SHOULD NOT, as you suggest, there's an implication that there
> might be a valid reason for non-transactional mail to use "p=reject".  Are
> we okay with that?
>
> -MSK, participating
>
> ___
> 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] Example of Indirect Mail Flow Breakage with p=reject?

[Barry Leiba]

> If we use SHOULD NOT, as you suggest, there's an implication that there might 
> be a valid reason for
> non-transactional mail to use "p=reject".  Are we okay with that?

I, for one, am not.  We often use "SHOULD NOT" incorrectly to mean
"MUST NOT, but we know it will be widely violated so we're saying
SHOULD NOT".  We need to stop doing that.

Barry

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