Re: [dmarc-ietf] Signaling MLMs

[Alessandro Vesely]

On Wed 19/Apr/2023 15:50:54 +0200 Benny Pedersen wrote:

Alessandro Vesely skrev den 2023-04-19 11:09:

if all maillist did arc on incoming mails before mailman scraped dkim then 
all will be good, only left is dmarc is not in all places tests arc results


It is all too easy to spoof an ARC chain offering false authentication
results.


ARC chains is untrusted by default, where is the problem ?



Just pointing out that "if all maillist did arc on incoming mails before 
mailman scraped dkim" then that is not enough.




Allowing ARC to override DMARC result requires the ARC
signer to be whitelisted.


whitelisted is not right word for it, its either trusted or untrusted



Yes, I meant to say a site can make a list of all the ARC-sealers they trust 
and call it a whitelist.




Now, one can object that whitelisting could be done by DKIM, by SPF,
by DNSWL, without the need to introduce a new, long-winded protocol.
However, ARC brings a couple of advantages:

1) In case of multiple forwarding steps, ARC delivers an ordered and
cohesive chain which is easier to verify than a messy mass of DKIM
signatures.


recipients should only care of dmarc, not dkim/arc/spf fails

to make this work dmarc must trust arc



Here a lost you.  DMARC is a protocol.  It cannot give credence or believe.  It 
can pass or fail.  It is receivers who can trust an ARC chain and override 
DMARC results; that is, allow the message even if dmarc=fail and p=reject.



Best
Ale
--



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

Re: [dmarc-ietf] Signaling MLMs

[Benny Pedersen]

Alessandro Vesely skrev den 2023-04-19 11:09:

Benny is telling the world “ietf.org [1] is authorize to resign on my 
behalf” via DNS.  No headers required.  No delayed learning 
necessary.

How would I get a clue of that?


reading books ?

if all maillist did arc on incomming mails before mailman scrapled 
dkim then all will be good, only left is dmarc is not in all places 
tests arc results

It is all too easy to spoof an ARC chain offering false authentication
results.


ARC chains is untrusted by defaullt, where is the problem ?


Allowing ARC to override DMARC result requires the ARC
signer to be whitelisted.


whitelisted is not right word for it, its either trusted or untrusted


Now, one can object that whitelisting could be done by DKIM, by SPF,
by DNSWL, without the need to introduce a new, long-winded protocol.
However, ARC brings a couple of advantages:

1) In case of multiple forwarding steps, ARC delivers an ordered and
cohesive chain which is easier to verify than a messy mass of DKIM
signatures.


recipients should only care of dmarc, not dkim/arc/spf fails

to make this work dmarc must trust arc


2) Authentication results, which normally are deleted or renamed on
crossing ADMD barriers, can be exported.


well it scramples dkim, no go


As they can sometimes be
checked against message transformation, fraudsters can in the long run
be debunked.


if we keep the problem on maillist we lost all the goods dkim protect, i 
dont want this


i still wonder what errors done in rspamd now :/

my dmarc policy is none, but rspamd says its reject, hmm

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

Re: [dmarc-ietf] Signaling MLMs

[Alessandro Vesely]

On Wed 19/Apr/2023 01:13:48 +0200 Benny Pedersen wrote:

Hector Santos skrev den 2023-04-18 20:47:


So your verifier see Benny’s as suspicious because of arc=fail?


it does imho not fail on my own arc ?



My filter attempts to recover DKIM signatures after MLM transformation, but not 
ARC chains.  Currently, ARC is evaluated but its result don't modify message 
worthiness.



Benny is telling the world “ietf.org [1] is authorize to resign on 
my behalf” via DNS.  No headers required.  No delayed learning 
necessary.



How would I get a clue of that?


if all maillist did arc on incomming mails before mailman scrapled dkim then 
all will be good, only left is dmarc is not in all places tests arc results



It is all too easy to spoof an ARC chain offering false authentication results. 
 Allowing ARC to override DMARC result requires the ARC signer to be whitelisted.


Now, one can object that whitelisting could be done by DKIM, by SPF, by DNSWL, 
without the need to introduce a new, long-winded protocol.  However, ARC brings 
a couple of advantages:


1) In case of multiple forwarding steps, ARC delivers an ordered and cohesive 
chain which is easier to verify than a messy mass of DKIM signatures.


2) Authentication results, which normally are deleted or renamed on crossing 
ADMD barriers, can be exported.  As they can sometimes be checked against 
message transformation, fraudsters can in the long run be debunked.



Best
Ale
--






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

Re: [dmarc-ietf] Signaling MLMs

[Benny Pedersen]

Hector Santos skrev den 2023-04-18 20:47:


So your verifier see Benny’s as suspicious because of arc=fail?


it does imho not fail on my own arc ?


Benny is telling the world “ietf.org [1] is authorize to resign on
my behalf” via DNS.  No headers required.  No delayed learning
necessary.


if all maillist did arc on incomming mails before mailman scrapled dkim 
then all will be good, only left is dmarc is not in all places tests arc 
results


its more waste that ietf add one more dkim signed keys, its not used at 
all in spamassassin unless one do welcomelist_from_dkim *@* ietf.org



What more is needed?


more dokument on dkim fails, basicly dkim should not defined any reject 
reasons, eg it should not be possible to reject in opendkim at all, this 
should be in opendmarc policy, not just random chain rejects


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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 18, 2023, at 12:24 PM, Alessandro Vesely  wrote:
> 
> What's the point of wearing an atps record if it's not called out in a DKIM 
> signature?  (I wouldn't have tested it anyway).


Alessandro, you are already doing the DNS call for DMARC.  Hitch a ride!! You 
can check for atps=y or asl= for 3rd party authorization. 

> What's the point of ARC-sealing a message which is not arrived from an 
> external ADMD?

I have no idea and I think ARC is a waste of time. Way too much overhead.  Not 
a good idea to pursue this has a long term solution.  I rather not.

> I'm rather happy with the amount of gibberish I currently get.  For this 
> Benny's message it was:
> 
> Authentication-Results: wmail.tana.it;
>  spf=pass smtp.mailfrom=ietf.org;
>  dkim=pass reason="transformed" header.d=junc.eu;
>  dkim=pass (whitelisted) header.d=ietf.org
>header.b=yiVUz1hG (ietf1);
>  dkim=pass (whitelisted) header.d=ietf.org
>header.b=yiVUz1hG (ietf1);
>  arc=fail (1 set(s)) smtp.remote-ip=50.223.129.194
> 

So your verifier see Benny’s as suspicious because of arc=fail? 

Benny is telling the world “ietf.org  is authorize to resign 
on my behalf” via DNS.  No headers required.  No delayed learning necessary.

What more is needed?



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

Re: [dmarc-ietf] Signaling MLMs

[Alessandro Vesely]

On Tue 18/Apr/2023 00:48:30 +0200 Benny Pedersen wrote:

Hector Santos skrev den 2023-04-17 20:55:


One solution is for the junc.eu domain to add an ATPS authorization
record for ietf.org [1] to the junc.eu [2] zone:

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")


retest



What's the point of wearing an atps record if it's not called out in a DKIM 
signature?  (I wouldn't have tested it anyway).

What's the point of ARC-sealing a message which is not arrived from an external 
ADMD?


I'm rather happy with the amount of gibberish I currently get.  For this 
Benny's message it was:

Authentication-Results: wmail.tana.it;
  spf=pass smtp.mailfrom=ietf.org;
  dkim=pass reason="transformed" header.d=junc.eu;
  dkim=pass (whitelisted) header.d=ietf.org
header.b=yiVUz1hG (ietf1);
  dkim=pass (whitelisted) header.d=ietf.org
header.b=yiVUz1hG (ietf1);
  arc=fail (1 set(s)) smtp.remote-ip=50.223.129.194
Received-SPF: none (Address does not pass the Sender Policy Framework)
  SPF=HELO;
  sender=mail.ietf.org;
  remoteip=50.223.129.194;
  remotehost=mail.ietf.org;
  helo=mail.ietf.org;
  receiver=wmail.tana.it;
Received-SPF: pass (Address passes the Sender Policy Framework)
  SPF=MAILFROM;
  sender=dmarc-boun...@ietf.org;
  remoteip=50.223.129.194;
  remotehost=mail.ietf.org;
  helo=mail.ietf.org;
  receiver=wmail.tana.it;
Received: from mail.ietf.org (mail.ietf.org [50.223.129.194])
  (TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
  by wmail.tana.it with ESMTPS
  id 005DC0F0.643DCCEC.4A7D; Tue, 18 Apr 2023 00:49:15 +0200
Authentication-Results: wmail.tana.it;
dnswl=pass dns.zone=list.dnswl.org
policy.ip=127.0.9.2
policy.txt="ietf.org https://dnswl.org/s/?s=1703";
Received: from ietfa.amsl.com (localhost [IPv6:::1])
by ietfa.amsl.com (Postfix) with ESMTP id 7B53AC17B344
for ; Mon, 17 Apr 2023 15:49:04 -0700 (PDT)


Best
Ale
--




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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/17/2023 6:48 PM, Benny Pedersen wrote:

Hector Santos skrev den 2023-04-17 20:55:


One solution is for the junc.eu domain to add an ATPS authorization
record for ietf.org [1] to the junc.eu [2] zone:

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")


retest


[3] https://winserver.com/public/wcDmarc




Hi Benny,

Thanks for testing!!  The verification on your message showed dmarc=fail.

Apparently, I couldn't completely turn off the ADSP/ATPS logic when I 
added the DMARC/ATPS to the wcDKIM Policy verifier. Once I re-enabled 
ADSP/ATPS, it worked with the expected responses by running the code 
on the saved original inbound message. The Author Domain policy, if 
any, in this case ADSP and DMARC, ares applied to each signature found.


*Authentication-Results: dkim.winserver.com;**
** dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;**
** adsp=none author.d=junc.eu signer.d=ietf.org;**
**dmarc=pass policy=none author.d=junc.eu asl.d=ietf.org (asl signer);**
** dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;**
** adsp=none author.d=junc.eu signer.d=ietf.org;**
**dmarc=pass policy=none author.d=junc.eu asl.d=ietf.org (asl signer);**
**dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=junc.eu 
header.s=default header.i=@junc.eu;**

** adsp=dkim-fail author.d=junc.eu signer.d=junc.eu;**
** dmarc=dkim-fail policy=none author.d=junc.eu signer.d=junc.eu 
(originating signer);*



Description.  The DMARC record for junc.eu was updated with two new tags:

*atps=y;asl=ietf.org*

No ADSP record was found.  No ADSP+ATPS policy logic applied. The 
DMARC+ATPS verifier found the asl= signer condition to be true.  If 
asl= was false, the atps=y tag enables an ATPS record lookup for the 
signer domain ietf.org.


Time to update this 2011 code to allow ADSP to be disabled and the new 
DMARCBis new lookup algorithm considerations.


Thanks for exploring this DKIM Policy Model solution with 3rd party 
signer support using DMARC+ATPS.



--
Hector Santos,
https://winserver.com/public/wcADSP
https://winserver.com/public/wcDMARC


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

Re: [dmarc-ietf] Signaling MLMs

[Benny Pedersen]

Hector Santos skrev den 2023-04-17 20:55:


One solution is for the junc.eu domain to add an ATPS authorization
record for ietf.org [1] to the junc.eu [2] zone:

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")


retest


[3] https://winserver.com/public/wcDmarc


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

Re: [dmarc-ietf] Signaling MLMs

[Benny Pedersen]

Hector Santos skrev den 2023-04-17 20:55:


Just consider your message source. The header overhead is massively
complex to read. It is really a waste on receivers.


Apr 17 22:53:28.015 [22350] dbg: authres: parsing 
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass 
(1024-bit key) header.d=isdg.net header.b="LJSFN/J6"; dkim=pass 
(1024-bit key) header.d=beta.winserver.com header.b="x/bRVx9h"
Apr 17 22:53:28.015 [22350] dbg: authres: parsing 
Authentication-Results: dkim.winserver.com; dkim=pass 
header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  
dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com 
(atps signer);
Apr 17 22:53:28.016 [22350] dbg: authres: skipping header, missing 
property: =reject author.d=isdg.net signer.d=beta.winserver.com (atps 
signer);

Apr 17 22:53:28.016 [22350] dbg: authres: results: dkim=pass


pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")


added and thanks if succces :)


[3] https://winserver.com/public/wcDmarc


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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 16, 2023, at 11:31 PM, Benny Pedersen  wrote:
> 
> Hector Santos skrev den 2023-04-17 05:06:
> 
>> Anyway, there are far too much waste in electronic mail, ADSP/DMARC
>> and this quest to resolve its issues, creating more junk, ARC, is not
>> getting anywhere.
> 
> ?, spamassassin 4, do something, i use fuglu in prequeue smtpd postfix, works 
> for me atleast, it sometimes helps to be a gentoo ebuild maintainer, i still 
> like to find proxy maintainers helping me
> 
> with arc its sadly appled AFTER mailman have scrampled dkim :/
> 
> arc sign/seal should be done on incomming mails, not on outgoing


Thanks for the information.

Just consider your message source. The header overhead is massively complex to 
read. It is really a waste on receivers.

The final Auth-Result for your message:


Authentication-Results: dkim.winserver.com;
 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 dmarc=fail policy=none author.d=junc.eu signer.d=ietf.org 
(unauthorized signer);
 dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
 dmarc=fail policy=none author.d=junc.eu signer.d=ietf.org 
(unauthorized signer);
 dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=junc.eu header.s=default 
header.i=@junc.eu;
 dmarc=dkim-fail policy=none author.d=junc.eu signer.d=junc.eu 
(originating signer);


One solution is for the junc.eu domain to add an ATPS authorization record for 
ietf.org  to the junc.eu  zone:

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")
to authorize the signer domain ietf.org:

See the wcDMARC wizard:


https://winserver.com/public/wcDmarc


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

Re: [dmarc-ietf] Signaling MLMs

[Benny Pedersen]

Hector Santos skrev den 2023-04-17 05:06:


Anyway, there are far too much waste in electronic mail, ADSP/DMARC
and this quest to resolve its issues, creating more junk, ARC, is not
getting anywhere.


?, spamassassin 4, do something, i use fuglu in prequeue smtpd postfix, 
works for me atleast, it sometimes helps to be a gentoo ebuild 
maintainer, i still like to find proxy maintainers helping me


with arc its sadly appled AFTER mailman have scrampled dkim :/

arc sign/seal should be done on incomming mails, not on outgoing

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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/16/2023 8:43 PM, Neil Anuskiewicz wrote:


Hector, respecfully, I disagree with several of your points.

* You seemes to be saying that when spf fails then usually dkim 
fails, too. I’ve seen first hand that’s nit true.


Yes, most of the times.  The exceptions are the true forwards. It's 
easily resolved.  Have the user prepare to pick up the mail.


* you seemed to be placing too much weight on the value of spf 
hardfail. Even 10 years ago, few receivers rejected on an spf hardfail.


I was one of the early adopters among aol.com and others to promote 
hard fails early on because it was quite evident most of the time it 
was a complete waste of DNS calls when its softfail or especially 
neutral or NXDOMAIN.


All of my wcSMTP customers benefited from the integrated 
wcDKIM/wcDMARC add-on.


As of today, after 20 years of daily data collection, SPF offers 6.3% 
of the INCOMING total rejection rates.   It was a slow climb. None are 
forwarding problems.


I'm pretty sure a huge set of transport outgoing logs of forwarded 
mail were 55z due to SPF hardfail policies.  Not the only one.


Some do but it’s not at all reliable. DMARC is accepted by most as 
the new policy layer. It’s where policy should be handled. The OR 
logic is in part to get away from the policy layer that breaks 
fairly easily (e.g., forwarding). SPF is important but given a 
choice between authenticating with just aligned SPF or just aligned 
DKIM, I’d choose DKIM.


Gmail rejects forwards.  Its users MUST POP to pick up there mail now.

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


I’m skeptical and I’d imagine some others are too so a cite would go 
a long way. Thanks.


I have 20 years of collected daily stats here:

https://winserver.com/public/spamstats.wct

By the way, the #1 rejection method is the CBV - Call Back Verifier.  
Comes from the Modem Caller ID days where you check the client's ID.  
Check out the stats!!


SPF started as an IP::DOMAIN association.  In started during MARID. 
The early 2000 emergency IETF working group to help address the spoof 
problem to the tune of $13B dollars in the industry.  Yes, I remember 
the news number. :-)


I've implemented many of the LMAP IP::DOMAIN proposed; DMP, RMX and 
SPF was somewhat of a blend. I was there with this.  Did you know 
Microsoft still has their early version of SenderID in XML format? It 
came with a _ep.  subdomain, so please do a DNS TXT up for _ep.hotmail.com


"testing='true'>list1._ep.hotmail.com
t>list2._ep.hotmail.comlist3._ep.hotmail.com"


Since day one. I was there.

DKIM came with a ADID::SDID association (author, signer) and that was 
defined via policy, starting with SSP, reduced to ADSP and replaced as 
DMARC with the same ADSP problems. But Levine did not believe anyone 
would honor the hard policies.  He was wrong, right?


The problem since day one was that we can't resolve the 3rd party 
association, the ADID::SDID authorization missing piece.


Anyway, there are far too much waste in electronic mail, ADSP/DMARC 
and this quest to resolve its issues, creating more junk, ARC, is not 
getting anywhere.


Hence, until I have more confidence in whats being developed, I will 
always go the route of optimization and in this case, SPF hard 
failures are rejected before the DATA payload.  Any forwarded issue is 
resolved by the originator fixing issues, the MDA whitelisting, or 
prepare the user to POP3 pick up the mail. Everyone happy now.


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



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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/15/2023 6:53 AM, Alessandro Vesely wrote:
I only know a handful of mailing lists, and they all do From: 
rewriting.  Some took years to adapt, but eventually adapted.  Are 
there any who don't?


Since 1996, wcListServer.

I agree lists may also refuse participation and require posters to 
get gmail addresses.


In the case of IETF lists, copyright issues are addressed by the 
Note Well.  I see no violation in From: rewriting.


Since the dawn of messaging, there was much power in From authorship - 
its a taboo to destroy it.  What you write is copyrighted.  It's 
yours.  Yes. The copyright is not lost with the IETF rewrite.


Until then, there is some disruption.  We know it.  We can document 
it; we're not ignoring it.  We thought hard about it and concluded 
that it necessarily arises.  To timidly roll back doesn't seem to be 
a feasible option.  Making laws that cannot be followed, implying 
that every body is implicitly guilty, is an oldish governmental 
practice which sounds just silly when enacted by someone who does 
not even have a protocol police.


Agree.  The MLS/MLM will need to adjust.  Restricting 
subscription/submissions (honoring the protocol) is the easiest first 
step. Imto, this is the correct technical way but it comes with 
disruption.  This disruption MAY be acceptable to the domain but not 
the user.


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



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



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

Re: [dmarc-ietf] Signaling MLMs

[Neil Anuskiewicz]

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

Re: [dmarc-ietf] Signaling MLMs

[Neil Anuskiewicz]




> On Apr 15, 2023, at 7:29 AM, Scott Kitterman  wrote:
> 
> 
>> On April 15, 2023 12:26:16 PM UTC, Laura Atkins  
>> wrote:
>> On Apr 15, 2023, at 4:25 AM, Scott Kitterman  wrote:
> ...
>>> Or [person] gets a Gmail account for his IETF work and doesn't bother 
>>> tilting at
>>> windmills.
>> 
>> That solution only works until gmail publishes p=reject. At one point they 
>> said they were going to do that. 
>> 
>> It seems to me that there is zero harm in actively documenting the problems 
>> with DMARC and making interoperability recommendations about who should and 
>> should not be publishing restrictive policies.
> 
> I agree on documenting the issues with DMARC and making recommendations to 
> improve interoperability.  There are issues and they're significant, but we 
> shouldn't catastrophize them either.
> 
> To your other point, if that happens then people will move to another 
> provider if it affects them negatively.  If free email providers that don't 
> have p=reject get hard to find, then that probably creates a demand signal 
> and some entrepreneur will fill the void.

Does anyone know if there are promising paths that these market signals could 
impel?

I don’t like dealing with mailing list issues either and I have to do so 
regularly. If there were some avenues of r&d that looked promising then that 
would mean the market signals would likely make it worth the hassle of 
implementing a solution. 

I agree there’s a problem. There was that one that gave me headaches and stress 
as recently as a couple weeks ago. It’s not that I don’t think there’s a 
problem but I do think there’s some catastrophising. I think this is a solvable 
problem.

If we write a solid appendix that explains the problems and the options for 
addressing it as I think was proposed, that would provide the information 
needed, while making it clear the IETF isn’t the internet regulatory agency. 

I think if someone came up with a viable solution their ML software would do 
well. Problems are the markets way of facilitating the solving of difficult 
problems. I’m not a market purist but the market is very good at certain 
things. Market signals are the bat signal for entrepreneurs to leverage gaps in 
the market. It could be one of the established players that gets there first or 
it could be an upstart. I think the odds favor one of the better established 
players.

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

Re: [dmarc-ietf] Signaling MLMs

[Neil Anuskiewicz]

> On Apr 15, 2023, at 7:29 AM, Scott Kitterman  wrote:
> 
> 
> 
>> On April 15, 2023 12:26:16 PM UTC, Laura Atkins  
>> wrote:
>> On Apr 15, 2023, at 4:25 AM, Scott Kitterman  wrote:
> ...
>>> Or [person] gets a Gmail account for his IETF work and doesn't bother 
>>> tilting at 
>>> windmills.
>> 
>> That solution only works until gmail publishes p=reject. At one point they 
>> said they were going to do that. 
>> 
>> It seems to me that there is zero harm in actively documenting the problems 
>> with DMARC and making interoperability recommendations about who should and 
>> should not be publishing restrictive policies. 
> 
> I agree on documenting the issues with DMARC and making recommendations to 
> improve interoperability.  There are issues and they're significant, but we 
> shouldn't catastrophize them either.
> 
> To your other point, if that happens then people will move to another 
> provider if it affects them negatively.  If free email providers that don't 
> have p=reject get hard to find, then that probably creates a demand signal 
> and some entrepreneur will fill the void.

Does anyone know if there are promising paths that these market signals could 
impel?

I don’t like dealing with mailing list issues either and I have to do so 
regularly. If there were some avenues of r&d that looked promising then that 
would mean the market signals would likely make it worth the hassle of 
implementing a solution. 

I agree there’s a problem. There was that one that gave me headaches and stress 
as recently as a couple weeks ago. It’s not that I don’t think there’s a 
problem but I do think there’s some catastrophising. I think this is a solvable 
problem.

If we write a solid appendix that explains the problems and the options for 
addressing it as I think was proposed, that would provide the information 
needed, while making it clear the IETF isn’t the internet regulatory agency. 

I think if someone came up with a viable solution their ML software would do 
well. Problems are the markets way of facilitating the solving of difficult 
problems. I’m not a market purist but the market is very good at certain 
things. Market signals are the bat signal for entrepreneurs to leverage gaps in 
the market. It could be one of the established players that gets there first or 
it could be an upstart. I think the odds favor one of the better established 
players.

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

Re: [dmarc-ietf] Signaling MLMs

[Neil Anuskiewicz]

On Apr 15, 2023, at 7:52 AM, Hector Santos  wrote:On Apr 14, 2023, at 7:31 PM, Dotzero  wrote:On Fri, Apr 14, 2023 at 5:55 PM Hector Santos isdg.net> wrote:Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC failure.  In standard boolean logic is it an OR condition:IF SPF FAILS or DKIM FAILS Then Reject.You have it absolutely backwards.DMARC says if either (aligned) SPF validates or (aligned) DKIM validates, it passes.Hi Mike, Appreciate your comment. This OR gate logic will short-circuit DKIM with SPF validating.  Optimizing means not processing the payload and just issue a 250 which is ‘absolutely' not what we want. In fact, DMARC logic is an AND gate of two protocols; one standard, one informational with some controversial constraints (alignment).  I think you maybe meant:SPF predates ADSP/DMARC. It is a 5321 level technology.  It is not a payload 5322 technology.   Interestingly, you might be thinking in terms of SenderID which was a 5322 technology which offers SPF with the PRA (5322.From) as a new identity to evaluate.  I know it’s hard to believe for many but there is still a good percentage of domains that do not do ADSP or DMARC and maybe not even DKIM.  Just consider platforms using Integrated Mail Bots to automate things and they who don’t need the overhead. SPF is good enough.Using Pareto, SPF is the only thing needed for hard reject policy (-ALL).  DMARC is useless at this point unless you want it to override SPF hardfail rejects and record and send reports,  That would be a local policy.  An implementation detail.Over 88% of the time, when SPF fails, DKIM/ADSP/DMARC, if available would also fail.  So the payoff is high to short-circuit and lowered when you needless transfer a potential large and harmful payload.But for SPF soft failures (~ALL), that is when the interest of coupling SPF soft fail results  with ADSP results got traction.  SPF verifiers will pass SPF weaker policy results in meta-header data and that meant the payload protocol can help here.  Microsoft explored this method and had a secret source to determine how soft failures can be coupled with ADSP results. DMARC never considered partial results. DMARC see SPF as a pass not soft-fail.  So if DKIM passes and all four (4) domain identities are aligned, the transaction passes.  That’s an AND gate and you don’t need to even to process SPF or do DKIM validation if the domains do not align. Hector, respecfully, I disagree with several of your points.* You seemes to be saying that when spf fails then usually dkim fails, too. I’ve seen first hand that’s nit true.* you seemed to be placing too much weight on the value of spf hardfail. Even 10 years ago, few receivers rejected on an spf hardfail. Some do but it’s not at all reliable. DMARC is accepted by most as the new policy layer. It’s where policy should be handled. The OR logic is in part to get away from the policy layer that breaks fairly easily (e.g., forwarding). SPF is important but given a choice between authenticating with just aligned SPF or just aligned DKIM, I’d choose DKIM. Could you provide a citation for the following claim: “Over 88% of the time, when SPF fails, DKIM/ADSP/DMARC, if available would also fail.  So the payoff is high to short-circuit and lowered when you needless transfer a potential large and harmful payload.”I’m skeptical and I’d imagine some others are too so a cite would go a long way. Thanks.Neil___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[John Levine]

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

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

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

R's,
John

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

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

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

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

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

On other active topics:

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

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




DF

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

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

Re: [dmarc-ietf] Signaling MLMs

[Alessandro Vesely]

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

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

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

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


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


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


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


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


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



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


Best
Ale
--








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

Re: [dmarc-ietf] Signaling MLMs

[Alessandro Vesely]

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

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

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

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


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


This is where it breaks down for me.

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


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



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


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


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



Best
Ale
--




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

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

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

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

Scott K


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

Re: [dmarc-ietf] Signaling MLMs

[Alessandro Vesely]

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

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

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


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



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

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



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



Best
Ale
--






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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

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

Hi Mike, 

Appreciate your comment. 

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

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

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

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

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

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

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

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

—
HLS




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

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

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

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

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

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

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

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

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

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

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

Scott K

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

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

I can support Todd's language:

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

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

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

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

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

Doug Foster




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

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

Re: [dmarc-ietf] Signaling MLMs

[Jesse Thompson]

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

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

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

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

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

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

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

Jesse__

Re: [dmarc-ietf] Signaling MLMs

[Laura Atkins]

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

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

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

Laura



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

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

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

Or Todd gets a Gmail account for his IETF work and doesn't bother tilting at 
windmills.

Scott K



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

Re: [dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

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

> On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
>
> The Sender's users being denied the ability to participate in a list due
> to its policies seems to me like it puts this customer service problem
> where it belongs.
>
>
> Let's say, tomorrow, IETF configures this list to reject Todd's mail (as
> well as for every other member with p=reject) and/or disables from
> rewriting. Does Todd's domain owner care? No.
>

This is where it breaks down for me.

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

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

Before this domain turns on "p=reject", the MLM didn't have a customer
service problem.  Now it suddenly does, not through any change it made, but
rather because one of its subscriber's domains set that policy, and some
other subscriber's domain elects to enforce it.  Does that seem right to
you?  Because that's what all of this did to the IETF, for example.


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

So push on the smaller operator, not the ones imposing the change that
suddenly renders well established practices invalid.  That seems like the
right solution to you?

-MSK, participating
___
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 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] Signaling MLMs

[Murray S. Kucherawy]

On Fri, Apr 14, 2023, 14:51 Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Interoperability problems occur because MLMs believe they are exempt from
> the security problems that lesser mortals face.
>

This isn't true. Interoperability problems started when senders posted a
restrictive policy and receivers began enforcing it. The MLMs didn't have a
chance to form such a belief structure before things were already broken.


The Sender or MLM may be unhappy if lost eyes mean lost revenue, but an
> evaluator is tasked with disappointing senders, many times per day.
>

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.

Document the issue as a customer service problem and I am on board.
>

Indeed.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Dotzero]

On Fri, Apr 14, 2023 at 5:55 PM Hector Santos  wrote:

> Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.
>
> DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC
> failure.  In standard boolean logic is it an OR condition:
>
> IF SPF FAILS or DKIM FAILS Then Reject.
>

You have it absolutely backwards.

DMARC says if either (aligned) SPF validates or (aligned) DKIM validates,
it passes.

Michael Hammer


> On Apr 14, 2023, at 5:44 PM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
> Hector, it sounds like you are saying that SPF is all we need, so scrap
> DMARC.   If it is something else please clarify.
>
> Doug
>
> On Fri, Apr 14, 2023, 4:44 PM Hector Santos  40isdg@dmarc.ietf.org> wrote:
>
>>
>>
>> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy 
>> wrote:
>>
>> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely 
>> wrote:
>>
>>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>>> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <
>>> superu...@gmail.com> wrote:
>>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely 
>>> wrote:
>>> >>
>>> >>> Heck, MLMs should start rejecting messages sent from domains that
>>> publish a
>>> >>> blocking policy *when they fail authentication on entry*!!
>>> >>
>>> >> That's not enough to avoid the damage we're talking about.
>>>
>>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
>>> completely ignoring ABUSE.
>>>
>>
>> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against
>> rejection of messages merely because they fail authentication on ingress.
>>
>>
>> And respectfully, SPF always had a strong reject, hard fail policy
>> concept since it's LMAP R&D upbringing — immediate rejection, 55z rejection
>> code.
>>
>> Why Not?  It was optimized.  It served a purpose to address spoofs.
>> Partial, Neutral and Unknown results were possible. That was suppose to be
>> feed to a heuristics, highly subjective Reputation Engine. After exactly 20
>> years of data, SPF rejection rate is 6.3% of the incoming rejection
>> reasons. https://winserver.com/public/spamstats.wct
>>
>> I agree there are better solutions, but they're not yet developed.  As
>>> ugly as
>>> it may be, From: munging is the emerged solution.  It is a _fact_.  Now
>>> repeat
>>> again that the IETF standardized facts, not theories...
>>>
>>
>> Let's put the challenge back on you: Where's your evidence that From
>> munging is the emerged consensus solution that this working group should
>> standardize?  Where is this _fact_?  If we advance that as a Proposed
>> Standard, the community will quite reasonably ask why we think this is
>> true, and we're going to need to be able to answer them.  If working group
>> consensus agrees, then away we go.
>>
>>
>> As much as I am an original mail engineering purest (anyone here ever
>> work with Fidonet?) and therefore consider it to be a fundamental taboo to
>> destroy originating copyrighted authorship of anything, the MLS/MLM needs
>> to evolve to handle the various 1::many broadcasting distributions under a
>> new security umbrella.
>>
>> Because the current DMARCbis umbrella ist not providing 100% coverage,
>> for the MLS./MLM, it needs to do one of two things;  restrict
>> subscription/submissions or strip the security and rewrite the copyrighting
>> authorship, perpetuating a potential harm including legal.
>>
>> The latter is not preferred.  The former would be normal part of a
>> protocol complete algorithm. You would do the former always.  It’s the
>> easiest.  No need to modify the MLS.  Just the MLM low code provisional
>> scripts.
>>
>> —
>> HLS
>> ___
>> 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] Signaling MLMs

[Hector Santos]

Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.

DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC 
failure.  In standard boolean logic is it an OR condition:

IF SPF FAILS or DKIM FAILS Then Reject.

I hope you can understand this technical implementation detail.

—
HLS



> On Apr 14, 2023, at 5:44 PM, Douglas Foster 
>  wrote:
> 
> Hector, it sounds like you are saying that SPF is all we need, so scrap 
> DMARC.   If it is something else please clarify.
> 
> Doug
> 
> On Fri, Apr 14, 2023, 4:44 PM Hector Santos 
> mailto:40isdg@dmarc.ietf.org>> wrote:
>> 
>> 
>>> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy >> > wrote:
>>> 
>>> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely >> > wrote:
 On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
 > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
 > mailto:superu...@gmail.com>> wrote:
 >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely >>> >> > wrote:
 >>
 >>> Heck, MLMs should start rejecting messages sent from domains that 
 >>> publish a 
 >>> blocking policy *when they fail authentication on entry*!!
 >>
 >> That's not enough to avoid the damage we're talking about.
 
 Agreed.  Yet, it is a sane half-way between crazy rejecting always and 
 completely ignoring ABUSE.
>>> 
>>> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection 
>>> of messages merely because they fail authentication on ingress. 
>> 
>> And respectfully, SPF always had a strong reject, hard fail policy concept 
>> since it's LMAP R&D upbringing — immediate rejection, 55z rejection code.
>> 
>> Why Not?  It was optimized.  It served a purpose to address spoofs. Partial, 
>> Neutral and Unknown results were possible. That was suppose to be feed to a 
>> heuristics, highly subjective Reputation Engine. After exactly 20 years of 
>> data, SPF rejection rate is 6.3% of the incoming rejection reasons. 
>> https://winserver.com/public/spamstats.wct
>> 
 I agree there are better solutions, but they're not yet developed.  As 
 ugly as 
 it may be, From: munging is the emerged solution.  It is a _fact_.  Now 
 repeat 
 again that the IETF standardized facts, not theories...
>>> 
>>> Let's put the challenge back on you: Where's your evidence that From 
>>> munging is the emerged consensus solution that this working group should 
>>> standardize?  Where is this _fact_?  If we advance that as a Proposed 
>>> Standard, the community will quite reasonably ask why we think this is 
>>> true, and we're going to need to be able to answer them.  If working group 
>>> consensus agrees, then away we go.
>> 
>> As much as I am an original mail engineering purest (anyone here ever work 
>> with Fidonet?) and therefore consider it to be a fundamental taboo to 
>> destroy originating copyrighted authorship of anything, the MLS/MLM needs to 
>> evolve to handle the various 1::many broadcasting distributions under a new 
>> security umbrella.
>> 
>> Because the current DMARCbis umbrella ist not providing 100% coverage, for 
>> the MLS./MLM, it needs to do one of two things;  restrict 
>> subscription/submissions or strip the security and rewrite the copyrighting 
>> authorship, perpetuating a potential harm including legal.
>> 
>> The latter is not preferred.  The former would be normal part of a protocol 
>> complete algorithm. You would do the former always.  It’s the easiest.  No 
>> need to modify the MLS.  Just the MLM low code provisional scripts.
>> 
>> —
>> HLS
>> ___
>> dmarc mailing list
>> dmarc@ietf.org 
>> https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

Interoperability problems occur because MLMs believe they are exempt from
the security problems that lesser mortals face.

I am not obligated to deliver every message that arrives for my users.  If
DMARC causes an evaluator to block a message that his user wants, they have
a  customer service problem, not an interoperability problem.   The
protocol correctly provided information which the evaluator used as he saw
fit.

The Sender or MLM may be unhappy if lost eyes mean lost revenue, but an
evaluator is tasked with disappointing senders, many times per day.

Document the issue as a customer service problem and I am on board.

Doug

On Fri, Apr 14, 2023, 1:59 PM Scott Kitterman  wrote:

> On Friday, April 14, 2023 1:20:28 PM EDT Alessandro Vesely wrote:
> > On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
> > > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy"
>  wrote:
> > >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely 
> wrote:
> > >>> Heck, MLMs should start rejecting messages sent from domains that
> > >>> publish a
> > >>> blocking policy *when they fail authentication on entry*!!
> > >>
> > >> That's not enough to avoid the damage we're talking about.
> >
> > Agreed.  Yet, it is a sane half-way between crazy rejecting always and
> > completely ignoring ABUSE.
> >
> > >>> From: rewriting is the de-facto standard.  In DMARCbis we can only
> > >>> substitute "de-facto" with "proposed".  Better methods, implying
> > >>> different, possibly experimental, protocols are to be defined in
> > >>> separate documents. >>
> > >>
> > >> Are you suggesting we put that forward as our Proposed Standard way of
> > >> dealing with this problem?  It's been my impression that this is not a
> > >> solution that's been well received.
> >
> > I agree there are better solutions, but they're not yet developed.  As
> ugly
> > as it may be, From: munging is the emerged solution.  It is a _fact_.
> Now
> > repeat again that the IETF standardized facts, not theories...
> >
> > >>> Let me recall that when I proposed something like that, I was told
> that
> > >>> that was phase II and the WG was then already in phase III.  So,
> let's
> > >>> complete DMARCbis /without cannibalizing the spec/ by saying that it
> > >>> MUST NOT be used (as it is being used already).
> > >>
> > >> What you describe as "cannibalizing" is actually a matter of
> presenting
> > >> the
> > >> correct normative advice about interoperability.
> >
> > It is nonsensical.  It means DMARC is only useful for looking at the
> > reports. If that's really what we think, we'd be better off deprecating
> p=
> > completely. Otherwise, let's wait until next April 1st and publish it as
> > such.  It's ridiculous.
> >
> > >>  So I don't agree at all with that characterization.
> > >
> > > Agreed.  If people can't get over saying some domains will have
> > > interoperability problems when that's demonstrably a technically
> accurate
> > > statement (and I don't see anyone claiming it isn't), I don't see how
> > > progress is possible.
> >
> > I agree that we have to say that some domains have interoperability
> problems
> > as a consequence of DMARC.  Let's say that MLMs MUST do From: munging
> > unless (or until) better solutions arise, or unless they don't alter
> > messages.
> >
> > We're proposing email authentication, not anything less.
>
> Yes, but we don't get to close our eyes and pretend the rest of the world
> doesn't exist.
>
> If we want to change this, we're going to have to update RFC 5321, which I
> think is out of our scope.  In the section on aliases and lists (3.9), it
> says:
>
> >However, in this case, the message header section (RFC 5322 [4]) MUST
> >be left unchanged; in particular, the "From" field of the header
> >section is unaffected.
>
> I think it would be wrong to mandate From rewriting for a lot of reasons,
> but
> I don't think we get to just ignore an Internet Standard.  I think we
> particularly don't get to ignore an Internet Standard and make it through
> an
> IETF wide last call.
>
> I still don't hear anyone claiming there's no interoperability problems
> when
> some domains publish p=reject.  Can we please just agree to document
> reality
> and move forward?
>
> Scott K
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

Hector, it sounds like you are saying that SPF is all we need, so scrap
DMARC.   If it is something else please clarify.

Doug

On Fri, Apr 14, 2023, 4:44 PM Hector Santos  wrote:

>
>
> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy 
> wrote:
>
> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely  wrote:
>
>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <
>> superu...@gmail.com> wrote:
>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely 
>> wrote:
>> >>
>> >>> Heck, MLMs should start rejecting messages sent from domains that
>> publish a
>> >>> blocking policy *when they fail authentication on entry*!!
>> >>
>> >> That's not enough to avoid the damage we're talking about.
>>
>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
>> completely ignoring ABUSE.
>>
>
> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection
> of messages merely because they fail authentication on ingress.
>
>
> And respectfully, SPF always had a strong reject, hard fail policy concept
> since it's LMAP R&D upbringing — immediate rejection, 55z rejection code.
>
> Why Not?  It was optimized.  It served a purpose to address spoofs.
> Partial, Neutral and Unknown results were possible. That was suppose to be
> feed to a heuristics, highly subjective Reputation Engine. After exactly 20
> years of data, SPF rejection rate is 6.3% of the incoming rejection
> reasons. https://winserver.com/public/spamstats.wct
>
> I agree there are better solutions, but they're not yet developed.  As
>> ugly as
>> it may be, From: munging is the emerged solution.  It is a _fact_.  Now
>> repeat
>> again that the IETF standardized facts, not theories...
>>
>
> Let's put the challenge back on you: Where's your evidence that From
> munging is the emerged consensus solution that this working group should
> standardize?  Where is this _fact_?  If we advance that as a Proposed
> Standard, the community will quite reasonably ask why we think this is
> true, and we're going to need to be able to answer them.  If working group
> consensus agrees, then away we go.
>
>
> As much as I am an original mail engineering purest (anyone here ever work
> with Fidonet?) and therefore consider it to be a fundamental taboo to
> destroy originating copyrighted authorship of anything, the MLS/MLM needs
> to evolve to handle the various 1::many broadcasting distributions under a
> new security umbrella.
>
> Because the current DMARCbis umbrella ist not providing 100% coverage, for
> the MLS./MLM, it needs to do one of two things;  restrict
> subscription/submissions or strip the security and rewrite the copyrighting
> authorship, perpetuating a potential harm including legal.
>
> The latter is not preferred.  The former would be normal part of a
> protocol complete algorithm. You would do the former always.  It’s the
> easiest.  No need to modify the MLS.  Just the MLM low code provisional
> scripts.
>
> —
> HLS
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy  wrote:
> 
> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely  > wrote:
>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
>> > mailto:superu...@gmail.com>> wrote:
>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely > >> > wrote:
>> >>
>> >>> Heck, MLMs should start rejecting messages sent from domains that 
>> >>> publish a 
>> >>> blocking policy *when they fail authentication on entry*!!
>> >>
>> >> That's not enough to avoid the damage we're talking about.
>> 
>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and 
>> completely ignoring ABUSE.
> 
> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection of 
> messages merely because they fail authentication on ingress. 

And respectfully, SPF always had a strong reject, hard fail policy concept 
since it's LMAP R&D upbringing — immediate rejection, 55z rejection code.

Why Not?  It was optimized.  It served a purpose to address spoofs. Partial, 
Neutral and Unknown results were possible. That was suppose to be feed to a 
heuristics, highly subjective Reputation Engine. After exactly 20 years of 
data, SPF rejection rate is 6.3% of the incoming rejection reasons. 
https://winserver.com/public/spamstats.wct

>> I agree there are better solutions, but they're not yet developed.  As ugly 
>> as 
>> it may be, From: munging is the emerged solution.  It is a _fact_.  Now 
>> repeat 
>> again that the IETF standardized facts, not theories...
> 
> Let's put the challenge back on you: Where's your evidence that From munging 
> is the emerged consensus solution that this working group should standardize? 
>  Where is this _fact_?  If we advance that as a Proposed Standard, the 
> community will quite reasonably ask why we think this is true, and we're 
> going to need to be able to answer them.  If working group consensus agrees, 
> then away we go.

As much as I am an original mail engineering purest (anyone here ever work with 
Fidonet?) and therefore consider it to be a fundamental taboo to destroy 
originating copyrighted authorship of anything, the MLS/MLM needs to evolve to 
handle the various 1::many broadcasting distributions under a new security 
umbrella.

Because the current DMARCbis umbrella ist not providing 100% coverage, for the 
MLS./MLM, it needs to do one of two things;  restrict subscription/submissions 
or strip the security and rewrite the copyrighting authorship, perpetuating a 
potential harm including legal.

The latter is not preferred.  The former would be normal part of a protocol 
complete algorithm. You would do the former always.  It’s the easiest.  No need 
to modify the MLS.  Just the MLM low code provisional scripts.

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

Re: [dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely  wrote:

> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely 
> wrote:
> >>
> >>> Heck, MLMs should start rejecting messages sent from domains that
> publish a
> >>> blocking policy *when they fail authentication on entry*!!
> >>
> >> That's not enough to avoid the damage we're talking about.
>
> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
> completely ignoring ABUSE.
>

Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection
of messages merely because they fail authentication on ingress.  They both
acknowledge that there are perfectly legitimate mail flows where that can
happen.  Since DMARC is built on those foundations, I think your assertion
strains reason.  That is, it's weird to say "If you observe DKIM and SPF,
don't reject; but if you observe DMARC, do."

>>> From: rewriting is the de-facto standard.  In DMARCbis we can only
> >>> substitute "de-facto" with "proposed".  Better methods, implying
> >>> different, possibly experimental, protocols are to be defined in
> >>> separate documents. >>
> >> Are you suggesting we put that forward as our Proposed Standard way of
> >> dealing with this problem?  It's been my impression that this is not a
> >> solution that's been well received.
>
> I agree there are better solutions, but they're not yet developed.  As
> ugly as
> it may be, From: munging is the emerged solution.  It is a _fact_.  Now
> repeat
> again that the IETF standardized facts, not theories...
>

Let's put the challenge back on you: Where's your evidence that From
munging is the emerged consensus solution that this working group should
standardize?  Where is this _fact_?  If we advance that as a Proposed
Standard, the community will quite reasonably ask why we think this is
true, and we're going to need to be able to answer them.  If working group
consensus agrees, then away we go.

Laura, I believe, enumerated a few reasons why it doesn't work all that
well.  We'll need to explain why that's all fine.


> >> What you describe as "cannibalizing" is actually a matter of presenting
> the
> >> correct normative advice about interoperability.
>
> It is nonsensical.  It means DMARC is only useful for looking at the
> reports.
> If that's really what we think, we'd be better off deprecating p=
> completely.
> Otherwise, let's wait until next April 1st and publish it as such.  It's
> ridiculous.
>

I think that's rather hyperbolic, but ignoring that for the moment, there
is some validity to the idea that the reports part of DMARC is the only
part of DMARC that does not disrupt interoperability.

>>  So I don't agree at all with that characterization.
> >
> > Agreed.  If people can't get over saying some domains will have
> > interoperability problems when that's demonstrably a technically
> accurate
> > statement (and I don't see anyone claiming it isn't), I don't see how
> > progress is possible.
>
> I agree that we have to say that some domains have interoperability
> problems as
> a consequence of DMARC.  Let's say that MLMs MUST do From: munging unless
> (or
> until) better solutions arise, or unless they don't alter messages.
>
> We're proposing email authentication, not anything less.
>

Sure, but that proposal is -- clearly by now -- fraught with disruption.
We can't ignore it because it's inconvenient to DMARC's goal.

This is the first time I've ever heard someone push the idea that From
munging deserves Proposed Standard status.  I'd be happy to hear what
others think.  If that's actually a sleeper consensus of some kind, then
out with it.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

The solution to move forward is:

- Recommend MUST NOT publish if domain wants to allow users to use domain in 
public list systems,

- Warn MLS/MLS  to avoid From Rewrite and recommend to honor p=reject by 
rejecting subscription, submissions. This is already in practice since 2011.

- Update section 4.4.3 to assist domains with a desire to use p=reject to 
consider supporting extended technologies to help with public usage of p=reject.

- Add a section for marketers of DMARC security systems to assist in correcting 
this problem with less aggressive campaigns to be prepare mail hosting 
customers with p=reject policies before they’re ready to do so. Always start 
with p=none.

- Make DMARCbis Informational status for faster IETF adoption  As a proposed 
standard, it’s going to be a rough poison pill too shallow after ADSP was 
abandoned for the same problems.  The difference now is this MUST NOT publish 
and honor for DMARCbis.  This may be enough to get IETF endorsement for a 
proposed standard.  

—
HLS


> On Apr 14, 2023, at 1:58 PM, Scott Kitterman  wrote:
> 
> On Friday, April 14, 2023 1:20:28 PM EDT Alessandro Vesely wrote:
>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>>> On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
>  wrote:
 On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:
> Heck, MLMs should start rejecting messages sent from domains that
> publish a
> blocking policy *when they fail authentication on entry*!!
 
 That's not enough to avoid the damage we're talking about.
>> 
>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
>> completely ignoring ABUSE.
>> 
> From: rewriting is the de-facto standard.  In DMARCbis we can only
> substitute "de-facto" with "proposed".  Better methods, implying
> different, possibly experimental, protocols are to be defined in
> separate documents. >>
 
 Are you suggesting we put that forward as our Proposed Standard way of
 dealing with this problem?  It's been my impression that this is not a
 solution that's been well received.
>> 
>> I agree there are better solutions, but they're not yet developed.  As ugly
>> as it may be, From: munging is the emerged solution.  It is a _fact_.  Now
>> repeat again that the IETF standardized facts, not theories...
>> 
> Let me recall that when I proposed something like that, I was told that
> that was phase II and the WG was then already in phase III.  So, let's
> complete DMARCbis /without cannibalizing the spec/ by saying that it
> MUST NOT be used (as it is being used already).
 
 What you describe as "cannibalizing" is actually a matter of presenting
 the
 correct normative advice about interoperability.
>> 
>> It is nonsensical.  It means DMARC is only useful for looking at the
>> reports. If that's really what we think, we'd be better off deprecating p=
>> completely. Otherwise, let's wait until next April 1st and publish it as
>> such.  It's ridiculous.
>> 
 So I don't agree at all with that characterization.
>>> 
>>> Agreed.  If people can't get over saying some domains will have
>>> interoperability problems when that's demonstrably a technically accurate
>>> statement (and I don't see anyone claiming it isn't), I don't see how
>>> progress is possible.
>> 
>> I agree that we have to say that some domains have interoperability problems
>> as a consequence of DMARC.  Let's say that MLMs MUST do From: munging
>> unless (or until) better solutions arise, or unless they don't alter
>> messages.
>> 
>> We're proposing email authentication, not anything less.
> 
> Yes, but we don't get to close our eyes and pretend the rest of the world 
> doesn't exist.
> 
> If we want to change this, we're going to have to update RFC 5321, which I 
> think is out of our scope.  In the section on aliases and lists (3.9), it 
> says:
> 
>>   However, in this case, the message header section (RFC 5322 [4]) MUST
>>   be left unchanged; in particular, the "From" field of the header
>>   section is unaffected.
> 
> I think it would be wrong to mandate From rewriting for a lot of reasons, but 
> I don't think we get to just ignore an Internet Standard.  I think we 
> particularly don't get to ignore an Internet Standard and make it through an 
> IETF wide last call.
> 
> I still don't hear anyone claiming there's no interoperability problems when 
> some domains publish p=reject.  Can we please just agree to document reality 
> and move forward?
> 
> Scott K
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org 
> https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

On Friday, April 14, 2023 1:20:28 PM EDT Alessandro Vesely wrote:
> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
 wrote:
> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:
> >>> Heck, MLMs should start rejecting messages sent from domains that
> >>> publish a
> >>> blocking policy *when they fail authentication on entry*!!
> >> 
> >> That's not enough to avoid the damage we're talking about.
> 
> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
> completely ignoring ABUSE.
> 
> >>> From: rewriting is the de-facto standard.  In DMARCbis we can only
> >>> substitute "de-facto" with "proposed".  Better methods, implying
> >>> different, possibly experimental, protocols are to be defined in
> >>> separate documents. >>
> >> 
> >> Are you suggesting we put that forward as our Proposed Standard way of
> >> dealing with this problem?  It's been my impression that this is not a
> >> solution that's been well received.
> 
> I agree there are better solutions, but they're not yet developed.  As ugly
> as it may be, From: munging is the emerged solution.  It is a _fact_.  Now
> repeat again that the IETF standardized facts, not theories...
> 
> >>> Let me recall that when I proposed something like that, I was told that
> >>> that was phase II and the WG was then already in phase III.  So, let's
> >>> complete DMARCbis /without cannibalizing the spec/ by saying that it
> >>> MUST NOT be used (as it is being used already).
> >> 
> >> What you describe as "cannibalizing" is actually a matter of presenting
> >> the
> >> correct normative advice about interoperability.
> 
> It is nonsensical.  It means DMARC is only useful for looking at the
> reports. If that's really what we think, we'd be better off deprecating p=
> completely. Otherwise, let's wait until next April 1st and publish it as
> such.  It's ridiculous.
> 
> >>  So I don't agree at all with that characterization.
> > 
> > Agreed.  If people can't get over saying some domains will have
> > interoperability problems when that's demonstrably a technically accurate
> > statement (and I don't see anyone claiming it isn't), I don't see how
> > progress is possible.
> 
> I agree that we have to say that some domains have interoperability problems
> as a consequence of DMARC.  Let's say that MLMs MUST do From: munging
> unless (or until) better solutions arise, or unless they don't alter
> messages.
> 
> We're proposing email authentication, not anything less.

Yes, but we don't get to close our eyes and pretend the rest of the world 
doesn't exist.

If we want to change this, we're going to have to update RFC 5321, which I 
think is out of our scope.  In the section on aliases and lists (3.9), it 
says:

>However, in this case, the message header section (RFC 5322 [4]) MUST
>be left unchanged; in particular, the "From" field of the header
>section is unaffected.

I think it would be wrong to mandate From rewriting for a lot of reasons, but 
I don't think we get to just ignore an Internet Standard.  I think we 
particularly don't get to ignore an Internet Standard and make it through an 
IETF wide last call.

I still don't hear anyone claiming there's no interoperability problems when 
some domains publish p=reject.  Can we please just agree to document reality 
and move forward?

Scott K


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

Re: [dmarc-ietf] Signaling MLMs

[Alessandro Vesely]

On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:

On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy"  
wrote:

On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:

Heck, MLMs should start rejecting messages sent from domains that publish a 
blocking policy *when they fail authentication on entry*!!


That's not enough to avoid the damage we're talking about.



Agreed.  Yet, it is a sane half-way between crazy rejecting always and 
completely ignoring ABUSE.



From: rewriting is the de-facto standard.  In DMARCbis we can only 
substitute "de-facto" with "proposed".  Better methods, implying 
different, possibly experimental, protocols are to be defined in 
separate documents. >>
Are you suggesting we put that forward as our Proposed Standard way of 
dealing with this problem?  It's been my impression that this is not a 
solution that's been well received.



I agree there are better solutions, but they're not yet developed.  As ugly as 
it may be, From: munging is the emerged solution.  It is a _fact_.  Now repeat 
again that the IETF standardized facts, not theories...



Let me recall that when I proposed something like that, I was told that 
that was phase II and the WG was then already in phase III.  So, let's 
complete DMARCbis /without cannibalizing the spec/ by saying that it 
MUST NOT be used (as it is being used already).


What you describe as "cannibalizing" is actually a matter of presenting the 
correct normative advice about interoperability.



It is nonsensical.  It means DMARC is only useful for looking at the reports. 
If that's really what we think, we'd be better off deprecating p= completely. 
Otherwise, let's wait until next April 1st and publish it as such.  It's 
ridiculous.




 So I don't agree at all with that characterization.


Agreed.  If people can't get over saying some domains will have 
interoperability problems when that's demonstrably a technically accurate 
statement (and I don't see anyone claiming it isn't), I don't see how 
progress is possible.


I agree that we have to say that some domains have interoperability problems as 
a consequence of DMARC.  Let's say that MLMs MUST do From: munging unless (or 
until) better solutions arise, or unless they don't alter messages.


We're proposing email authentication, not anything less.


Best
Ale
--







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

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

The situation will converge to two separate but unequal environments, those
that prioritize security, and those that require insecurity.

As people get burned, the pro-security segment will grow and the insecure
segment will find more and more restrictions on their ability to connect to
their high-risk environments

I see no reason to expect any other outcome.Whatever words we publish
will be ignored or followed based on the camp that domains have chosen.

Doug Foster

On Fri, Apr 14, 2023, 9:48 AM Scott Kitterman  wrote:

>
>
> On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> >On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:
> >
> >> Heck, MLMs should start rejecting messages sent from domains that
> publish
> >> a
> >> blocking policy *when they fail authentication on entry*!!
> >>
> >
> >That's not enough to avoid the damage we're talking about.
> >
> >
> >> From: rewriting is the de-facto standard.  In DMARCbis we can only
> >> substitute
> >> "de-facto" with "proposed".  Better methods, implying different,
> possibly
> >> experimental, protocols are to be defined in separate documents.
> >>
> >
> >Are you suggesting we put that forward as our Proposed Standard way of
> >dealing with this problem?  It's been my impression that this is not a
> >solution that's been well received.
> >
> >
> >> Let me recall that when I proposed something like that, I was told that
> >> that
> >> was phase II and the WG was then already in phase III.  So, let's
> complete
> >> DMARCbis /without cannibalizing the spec/ by saying that it MUST NOT be
> >> used
> >> (as it is being used already).
> >>
> >
> >What you describe as "cannibalizing" is actually a matter of presenting
> the
> >correct normative advice about interoperability.  So I don't agree at all
> >with that characterization.
>
> Agreed.  If people can't get over saying some domains will have
> interoperability problems when that's demonstrably a technically accurate
> statement (and I don't see anyone claiming it isn't), I don't see how
> progress is possible.
>
> Scott K
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy"  
wrote:
>On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:
>
>> Heck, MLMs should start rejecting messages sent from domains that publish
>> a
>> blocking policy *when they fail authentication on entry*!!
>>
>
>That's not enough to avoid the damage we're talking about.
>
>
>> From: rewriting is the de-facto standard.  In DMARCbis we can only
>> substitute
>> "de-facto" with "proposed".  Better methods, implying different, possibly
>> experimental, protocols are to be defined in separate documents.
>>
>
>Are you suggesting we put that forward as our Proposed Standard way of
>dealing with this problem?  It's been my impression that this is not a
>solution that's been well received.
>
>
>> Let me recall that when I proposed something like that, I was told that
>> that
>> was phase II and the WG was then already in phase III.  So, let's complete
>> DMARCbis /without cannibalizing the spec/ by saying that it MUST NOT be
>> used
>> (as it is being used already).
>>
>
>What you describe as "cannibalizing" is actually a matter of presenting the
>correct normative advice about interoperability.  So I don't agree at all
>with that characterization.

Agreed.  If people can't get over saying some domains will have 
interoperability problems when that's demonstrably a technically accurate 
statement (and I don't see anyone claiming it isn't), I don't see how progress 
is possible.

Scott K

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

Re: [dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:

> Heck, MLMs should start rejecting messages sent from domains that publish
> a
> blocking policy *when they fail authentication on entry*!!
>

That's not enough to avoid the damage we're talking about.


> From: rewriting is the de-facto standard.  In DMARCbis we can only
> substitute
> "de-facto" with "proposed".  Better methods, implying different, possibly
> experimental, protocols are to be defined in separate documents.
>

Are you suggesting we put that forward as our Proposed Standard way of
dealing with this problem?  It's been my impression that this is not a
solution that's been well received.


> Let me recall that when I proposed something like that, I was told that
> that
> was phase II and the WG was then already in phase III.  So, let's complete
> DMARCbis /without cannibalizing the spec/ by saying that it MUST NOT be
> used
> (as it is being used already).
>

What you describe as "cannibalizing" is actually a matter of presenting the
correct normative advice about interoperability.  So I don't agree at all
with that characterization.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Alessandro Vesely]

On Thu 13/Apr/2023 17:57:55 +0200 Dotzero wrote:

On Wed, Apr 12, 2023 at 11:38 PM Murray S. Kucherawy  
wrote:

On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones  wrote:

In any case, are we really going to start suggesting that list operators 
start rejecting messages sent from domains that publish a blocking policy, 
as official guidance? (Now I'm looking ever so forward to catching up on 
these other threads - what the heck are people seeing out there??)



Heck, MLMs should start rejecting messages sent from domains that publish a 
blocking policy *when they fail authentication on entry*!!



Well, this WG is chartered to come up with some kind of standards track 
solution to the problem.  I don't see one in DMARCbis at the moment.  Given 
how long this WG has existed so far, that's a fairly glaring omission. 
Doesn't seem to me this idea should be off the table just yet...


I don't think it should be off the table but believe it is only one of the 
options that MLMs/forwarders have.



From: rewriting is the de-facto standard.  In DMARCbis we can only substitute 
"de-facto" with "proposed".  Better methods, implying different, possibly 
experimental, protocols are to be defined in separate documents.


Let me recall that when I proposed something like that, I was told that that 
was phase II and the WG was then already in phase III.  So, let's complete 
DMARCbis /without cannibalizing the spec/ by saying that it MUST NOT be used 
(as it is being used already).


If it will be possible to get back to indirect mail flows, there's more work to 
do there.



Best
Ale
--





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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 13, 2023, at 4:33 PM, John Levine  wrote:
> 
>> (2) An author domain can decide to affix this at its discretion, ...
> 
> The basic problem is that author domains lie about their policy, i.e.,
> p=none but they expect mailing lists to work, and their users are
> stuck.

It’s not a lie. The protocol expected the MLS or MLM using low code scripts to 
adjust. It’s been 17 years!  Hello?

1. Honor the policy, protect security by rejecting restrictive domains, or

2. Break the security layer, redistribute with no security.

You, as the author of DMARCbis, oddly choose #2.  Why not #1?

—
HLS

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

Re: [dmarc-ietf] Signaling MLMs

[John Levine]

It appears that Murray S. Kucherawy   said:
>(1) MLMs don't necessarily want to start doing DNS queries.  They operate
>just fine never touching the DNS today; this is a new dependency and bunch
>of stuff they have to learn to apply and suppot.

Depends how they're set up.  In the common case that the inbound MTA adds an A-R
header, it can get the DMARC policy there.  That's how my dmarc.fail shim works.

>(2) An author domain can decide to affix this at its discretion, ...

The basic problem is that author domains lie about their policy, i.e.,
p=none but they expect mailing lists to work, and their users are
stuck.

R's,
John

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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/13/2023 11:14 AM, Barry Leiba wrote:
There's no need for a signal here: the MLM can simply check the 
sending domain's DMARC policy when a new post comes in, and 
preemptively reject it if the policy is "reject". The IETF 
considered doing that and ruled it out because it would mean that 
users with yahoo.com addresses (and others) could then not 
participate in IETF mailing lists without changing addresses. 

Code change where?  In the MLS or some post scripting code?

I think that was the wrong decision, but we decided on the ugly 
"from" alteration instead. 


Code change anyway.   No way around this code change - a direct MLS 
change or MLM low code script add-on/change.   My MLS checks it's 
entry points for restrictive DMARC domain; subscription and submissions.


I still think that outright refusal of posts from p=reject domains 
is a good approach and I wish it were used more, but most MLMs that 
are willing to put in a change to address this seems to prefer not 
to punish the sending domains users for the excesses of the domain 
management.


+1.

It can only be considered more with key cogs support and promotion to 
their industry/trade support peers. Iow, Editors SHOULD 
support/champion their RFC work like ATPS and DMARC.  Many ideas and 
concepts from DSAP merged from WG work. DMARC is a collection of all 
the past work with reporting. But it needs DSAP policy ideas and ATPS 
concept to help bring some steady state to transporters. DMARCbis p= 
should be describing the failure handling not restricting the 
evaluation of a failure.  This will provide the tools to define the 
nine possible 1st vs 3rd party signers.  MLS needs to support this.  
The MLM operators need to support it too. Of course, the MLS/MLM can 
use Local Policy to override at its own risk especially when DMARCBis 
offers nothing to resolve this problem.  But it can easily fit in too 
and see where it goes.



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



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

Re: [dmarc-ietf] Signaling MLMs

[Dotzero]

On Wed, Apr 12, 2023 at 11:38 PM Murray S. Kucherawy 
wrote:

> On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones  wrote:
>
>> This puts me in mind of Section 8.5, which calls out some potential
>> impacts of blocking policies to "Mediators," which role doesn't otherwise
>> appear very often in this document. Is there any need to add Mediator
>> Actions/Considerations under section 5? Or does this belong in a separate
>> document?
>>
>
> We should probably review it and think about whether what it says is
> enough.
>

This is certainly worth a discussion.


> ISTR there were some vocal and visible mailing list operators that were
>> rejecting messages from domains that published "p=reject" policies, maybe
>> around 2014-15? I also thought they did this by checking the sending
>> domain's published policy in DNS, to your point about implementation.
>>
> This would be great [anec-]data to have.  Do you remember where you might
> have seen it?
>

My recollection is similar to Steve's except that I saw the talk but didn't
see the walking the walk.

> In any case, are we really going to start suggesting that list operators
>> start rejecting messages sent from domains that publish a blocking policy,
>> as official guidance? (Now I'm looking ever so forward to catching up on
>> these other threads - what the heck are people seeing out there??)
>>
>
> Well, this WG is chartered to come up with some kind of standards track
> solution to the problem.  I don't see one in DMARCbis at the moment.  Given
> how long this WG has existed so far, that's a fairly glaring omission.
> Doesn't seem to me this idea should be off the table just yet...
>

 I don't think it should be off the table but believe it is only one of the
options that MLMs/forwarders have.

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

Re: [dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

On Thu, Apr 13, 2023 at 8:14 AM Barry Leiba  wrote:

> There's no need for a signal here: the MLM can simply check the
> sending domain's DMARC policy when a new post comes in, and
> preemptively reject it if the policy is "reject".  The IETF considered
> doing that and ruled it out because it would mean that users with
> yahoo.com addresses (and others) could then not participate in IETF
> mailing lists without changing addresses.  I think that was the wrong
> decision, but we decided on the ugly "from" alteration instead.
>

My idea is based on two assumptions:

(1) MLMs don't necessarily want to start doing DNS queries.  They operate
just fine never touching the DNS today; this is a new dependency and bunch
of stuff they have to learn to apply and suppot.

(2) An author domain can decide to affix this at its discretion, so it has
some say in which out-flows are subjected to this "do not modify"
constraint.  Of course, that discretion can lead to other problems, such as
the author domain not affixing it when it should, or vice versa.

As for the IETF, if this WG comes out with contrary advice to that
decision, we (the IETF) would have to reconsider.  It's an ugly question
either way.

I still think that outright refusal of posts from p=reject domains is
> a good approach and I wish it were used more, but most MLMs that are
> willing to put in a change to address this seems to prefer not to
> punish the sending domains users for the excesses of the domain
> management.
>

I think if the outcome is that we decide we don't want to do this, this
discussion would be good to capture in the document to indicate what we
considered and discarded.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Barry Leiba]

I would like to make the receiving advice stronger *also*, yes.  In
particular, I would change the SHOULD NOT to MUST NOT, and I would add text
that suggests that it's a particularly bad idea to react to p=reject for
domains that are known to host email addresses for the general public, and
expand on the reasons why.

I don't think that eliminates the need for strong advice to senders as well.

Barry


On Thu, Apr 13, 2023 at 11:07 AM Todd Herr  wrote:

> On Wed, Apr 12, 2023 at 11:35 PM Murray S. Kucherawy 
> wrote:
>
>> On Wed, Apr 12, 2023 at 11:41 AM Todd Herr > 40valimail@dmarc.ietf.org> wrote:
>>
>>> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy 
>>> wrote:
>>>
 I've been thinking about the point a few people have made now that
 DMARC has two actors that cause the problem: Those who "blindly" apply
 "p=reject", and those who advertise "p=reject".  You do, indeed, need two
 to tango; enforcement doesn't happen without an advertising sender and a
 participating receiver.  Maybe any "MUST NOT" advice we provide needs to
 cover both ends.  We need to be careful about admonishing participating
 receivers though.  What would we say to them about how to be selective in
 application?

>>>
>>> I'd argue that we have language already that advises receivers to be
>>> selective in application. The second paragraph of section 5.8, Policy
>>> Enforcement Considerations, currently reads as follows in DMARCbis:
>>>
>>> Mail Receivers MAY choose to accept email that fails the DMARC
>>> mechanism check even if the published Domain Owner Assessment Policy is
>>> "reject". In particular, because of the considerations discussed in [
>>> RFC7960
>>> ],
>>> it is important that Mail Receivers SHOULD NOT reject messages solely
>>> because of a published policy of "reject", but that they apply other
>>> knowledge and analysis to avoid situations such as rejection of legitimate
>>> messages sent in ways that DMARC cannot describe, harm to the operation of
>>> mailing lists, and similar.
>>>
>>>
>>> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#name-policy-enforcement-consider
>>>
>>> Might that language be made stronger? Sure. Might it or other text
>>> include mention of ARC as a possible solution? Maybe.
>>>
>>
>> Right, thanks for the reminder.
>>
>> I think part of the problem might be that blanket observance of "reject"
>> is already commonplace.  There's also very little in the way of algorithms
>> or text guidance to indicate to receivers how they're supposed to know when
>> it's safe to actually reject.
>>
>
> I'm not sure it's true to say blanket observance of "reject" is
> commonplace. Both Gmail and Microsoft will override p=reject on a regular
> basis due to reasons known only to them.
>
> As for when it's safe to actually reject, I'm not sure that the full
> effect of policy changes can ever truly be known or predicted before
> they're implemented; one usually only learns the full impact after
> implementation. Back when I worked in email ops, the volume of customer
> complaints was a pretty good indicator to tell me that a decision I'd made
> had resulted in users not getting wanted mail (or getting too much unwanted
> mail). There was no hard and fast rule, of course, nor should we ever
> expect that there will be, but each organization I'm sure has some
> threshold for realizing that a new change's impact is a net negative, and a
> process for deciding whether or not to roll back a change if it does prove
> to be a net negative.
>
> It is possible, of course (or should be) to simulate the effect of changes
> prior to implementing them and use the information gathered to determine
> whether or not to go forward. When the decision under consideration is
> "should we honor p=reject?" I would study the inbound traffic for a
> reasonable period of time (maybe a couple of months or more) and track how
> much mail would've been rejected (perhaps on a per-domain basis) and to the
> extent my system allowed, what percentage of that mail was engaged with,
> and how (spam complaints, opens, deleted without opening, forwarded, etc.).
> Obviously, such engagement tracking might be beyond the capability of some
> mail receivers, but that's how I'd want to approach the problem.
>
> Might the above two paragraphs contribute to additional text to add to
> this document in section 5.8?
>
>
>
>>
>>
>>>
>>> I've also been thinking about ways to push the burden back on the
 advertisers.  Imagine we have some kind of signaling mechanism that MLMs
 can take advantage of indicating to them that the author is using a strong
 policy, and so it would be possibly a bad idea for the MLM to accept,
 mutate, and re-send this message.  This could be a header field or an SMTP
 extension (though the latter is complex to get right in a store-and-forward
 system).  The MLM can then d

Re: [dmarc-ietf] Signaling MLMs

[Barry Leiba]

> I've also been thinking about ways to push the burden back on the
> advertisers.  Imagine we have some kind of signaling mechanism that
> MLMs can take advantage of indicating to them that the author is using
> a strong policy, and so it would be possibly a bad idea for the MLM to
> accept, mutate, and re-send this message.  This could be a header
> field or an SMTP extension (though the latter is complex to get right
> in a store-and-forward system).  The MLM can then decide if it is
> willing to pass the message unmodified to the list, or reject it with
> an error like "The policies of this list require modification of your
> message, which violates your domain's apparent policy.  Your
> submission therefore cannot be accepted.  Please contact your support
> organization for further assistance."  There's never an opportunity
> for the collateral bounce to occur if the message is never
> distributed, and the author domain has to either soften its policy or
> separate its regular users from its transactional stuff somehow.

There's no need for a signal here: the MLM can simply check the
sending domain's DMARC policy when a new post comes in, and
preemptively reject it if the policy is "reject".  The IETF considered
doing that and ruled it out because it would mean that users with
yahoo.com addresses (and others) could then not participate in IETF
mailing lists without changing addresses.  I think that was the wrong
decision, but we decided on the ugly "from" alteration instead.

I still think that outright refusal of posts from p=reject domains is
a good approach and I wish it were used more, but most MLMs that are
willing to put in a change to address this seems to prefer not to
punish the sending domains users for the excesses of the domain
management.

Barry

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

Re: [dmarc-ietf] Signaling MLMs

[Todd Herr]

On Wed, Apr 12, 2023 at 11:35 PM Murray S. Kucherawy 
wrote:

> On Wed, Apr 12, 2023 at 11:41 AM Todd Herr  40valimail@dmarc.ietf.org> wrote:
>
>> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy 
>> wrote:
>>
>>> I've been thinking about the point a few people have made now that DMARC
>>> has two actors that cause the problem: Those who "blindly" apply
>>> "p=reject", and those who advertise "p=reject".  You do, indeed, need two
>>> to tango; enforcement doesn't happen without an advertising sender and a
>>> participating receiver.  Maybe any "MUST NOT" advice we provide needs to
>>> cover both ends.  We need to be careful about admonishing participating
>>> receivers though.  What would we say to them about how to be selective in
>>> application?
>>>
>>
>> I'd argue that we have language already that advises receivers to be
>> selective in application. The second paragraph of section 5.8, Policy
>> Enforcement Considerations, currently reads as follows in DMARCbis:
>>
>> Mail Receivers MAY choose to accept email that fails the DMARC mechanism
>> check even if the published Domain Owner Assessment Policy is "reject". In
>> particular, because of the considerations discussed in [RFC7960
>> ],
>> it is important that Mail Receivers SHOULD NOT reject messages solely
>> because of a published policy of "reject", but that they apply other
>> knowledge and analysis to avoid situations such as rejection of legitimate
>> messages sent in ways that DMARC cannot describe, harm to the operation of
>> mailing lists, and similar.
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#name-policy-enforcement-consider
>>
>> Might that language be made stronger? Sure. Might it or other text
>> include mention of ARC as a possible solution? Maybe.
>>
>
> Right, thanks for the reminder.
>
> I think part of the problem might be that blanket observance of "reject"
> is already commonplace.  There's also very little in the way of algorithms
> or text guidance to indicate to receivers how they're supposed to know when
> it's safe to actually reject.
>

I'm not sure it's true to say blanket observance of "reject" is
commonplace. Both Gmail and Microsoft will override p=reject on a regular
basis due to reasons known only to them.

As for when it's safe to actually reject, I'm not sure that the full effect
of policy changes can ever truly be known or predicted before they're
implemented; one usually only learns the full impact after implementation.
Back when I worked in email ops, the volume of customer complaints was a
pretty good indicator to tell me that a decision I'd made had resulted in
users not getting wanted mail (or getting too much unwanted mail). There
was no hard and fast rule, of course, nor should we ever expect that there
will be, but each organization I'm sure has some threshold for realizing
that a new change's impact is a net negative, and a process for deciding
whether or not to roll back a change if it does prove to be a net negative.

It is possible, of course (or should be) to simulate the effect of changes
prior to implementing them and use the information gathered to determine
whether or not to go forward. When the decision under consideration is
"should we honor p=reject?" I would study the inbound traffic for a
reasonable period of time (maybe a couple of months or more) and track how
much mail would've been rejected (perhaps on a per-domain basis) and to the
extent my system allowed, what percentage of that mail was engaged with,
and how (spam complaints, opens, deleted without opening, forwarded, etc.).
Obviously, such engagement tracking might be beyond the capability of some
mail receivers, but that's how I'd want to approach the problem.

Might the above two paragraphs contribute to additional text to add to this
document in section 5.8?



>
>
>>
>> I've also been thinking about ways to push the burden back on the
>>> advertisers.  Imagine we have some kind of signaling mechanism that MLMs
>>> can take advantage of indicating to them that the author is using a strong
>>> policy, and so it would be possibly a bad idea for the MLM to accept,
>>> mutate, and re-send this message.  This could be a header field or an SMTP
>>> extension (though the latter is complex to get right in a store-and-forward
>>> system).  The MLM can then decide if it is willing to pass the message
>>> unmodified to the list, or reject it with an error like "The policies of
>>> this list require modification of your message, which violates your
>>> domain's apparent policy.  Your submission therefore cannot be accepted.
>>> Please contact your support organization for further assistance."  There's
>>> never an opportunity for the collateral bounce to occur if the message is
>>> never distributed, and the author domain has to either soften its policy or
>>> separate its regular users from its transactional stuff somehow.
>>>
>>

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/12/2023 11:38 PM, Murray S. Kucherawy wrote:
On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones > wrote:


ISTR there were some vocal and visible mailing list operators
that were rejecting messages from domains that published
"p=reject" policies, maybe around 2014-15? I also thought they
did this by checking the sending domain's published policy in
DNS, to your point about implementation.

This would be great [anec-]data to have.  Do you remember where you 
might have seen it?


This was initially outlined in 2006 DSAP guidelines for list servers.  
It has been mentioned numerous times in the DKIM and DMARC WGs 
throughout the many years.  The following is a 2011 Wildcat! SMTP List 
Server wcBASIC language p-code script called at DATA and it applies to 
ADSP/DMARC restrictive domain list submissions.  All of my Wildcat! 
customers/operators managing a list have the same stock code.


//***
// (c) Copyright 1998-2012 Santronics Software, Inc. All Rights Reserved.
//***
//
// File Name : smtpfilter-listchecker.wcc
// Subsystem : wcListServer
// Date  : 10/11/2011
// Author: SSI
// About : checks wcListServer list to accept delivery
//
//data\smtpfilterhookloader.ini
//config\wcmail.names
//
// Run this filter before smtpfitler-whitelist because you may have
// some auto-whitelisted users with restricted DMARC domains.  If
// WCLS is not ready for DMARC checking, a major distribution problem
// will occur with DMARC checking downlink receivers.
//
// Revision History:
//
// 2.0, 454.6, 11/09/18 11:28 pm
// 2.1, 454.6, 11/12/18 10:52 am
// 3.0, 454.12, 04/11/21 01:10 pm
//
// - Added ADSP/DMARC check.
//
//   ADSP/DMARC checks are not done on control messages.
//
// - Adding new support accepting extended list control messages:
//
// tmailist.name + "-subscribe";
// tmailist.name + "-unsubscribe"
// tmailist.name + "-bounces"
//
// 2.2, 454.10, 05/03/20 11:18 am
//
// - fix DMARC bug of using just the local part and not the
//   the domain to see of its a valid list.  The fix is
//   compare the ListDomain with the address.domain
//
//***

#include 
#include 
#include 
#include 

//--
// GLOBALS
//--

const FILTER_VERSION = "3.0"
Const CONTROL_NAMES  = "wc:\cfg\wcmail.names"

//--
// MAIN PROGRAM
//--


  sfInitializeHook(paramstr(1))

  dim args  as string  = lcase(paramstr(1))
  dim msgfn as string  = GetParamStr(args,"psf")  // prespool
  dim from  as string  = GetParamStr(args,"from") // sender
  dim rcpt  as string  = GetParamStr(args,"rcpt") // recipient

  // strip angle brackets from addresses

  rcpt = lcase(sfStripBrackets(rcpt))
  from = lcase(sfStripBrackets(from))

  // Parse the rcpt address to get its parts.
  // We want the user id part (left hand side) of address.
  // This would be the "list name".

  dim eaToas TEmailAddress
  dim eaFrom  as TEmailAddress
  ParseEmailAddress(rcpt,eaTo)
  ParseEmailAddress(from,eaFrom)

  dim lname as string = eaTo.usrid

  // Get the WCLS control name and compare with the list name,
  // or search for a existing mailing list by list name.
  // If found, then accept this email, record it in log
  // and also in the session trace (meta log).

  dim cname as string = lcase(ReadListControlName())

  dim ml as TMailList

  //-
  // 2.1
  // - Added control name and list control names check
  dim IsControlName as boolean
  if (cname = lname) then IsControlName = true
  if not IsControlName and right(lname,10) = "-subscribe"   then 
IsControlName = true
  if not IsControlName and right(lname,12) = "-unsubscribe" then 
IsControlName = true
  if not IsControlName and right(lname, 8) = "-bounces" then 
IsControlName = true

  //-

  // 2.2 05/03/20 04:58 pm
  // -- pass the domain to compare with listdomain
  dim ListDomainOK as Boolean = 
MailListRead(lname+".LIST",ml,eaTo.Domain)

  //
  if (IsControlName or ListDomainOk) then
 dim s as string = "Sender: "+from
 if from = "" then
 s = "Bounce message"
 from = "<>"
 end if
 //---
 // 2.1, added ADSP/DMARC check
 //---
 if (not IsControlName) and ml.CheckADSP then
dim dmarc  as string
dim adsp  as string
dim policy as string
if GetDMARC(eaFrom.Domain, "", dmarc) then
   policy = lcase(GetHeaderTag(dmarc,"p="))
   dim fv as inte

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

I am beginning work on a Best Practices document which will attempt to
explain what evaluators should understand about p=reject.   Topics to
include:

   - PASS is more important than FAIL
   - SPF and DMARC are not the end of authentication options.   Any message
   can be authenticated for the purpose of distinguishing acceptable mail
   streams from their impersonators.
   - Exceptions are to be expected.
   - Tuning of Sender Authentication should be a normal process of filter
   tuning, occurring in parallel with content filter adjustment, whitelisting,
   and blacklisting.

Since nothing like this exists, it may change the approach used by some
evaluators, but nothing will change all of them.

MLM senders need their minimally-authenticated messages to be accepted by
evaluators.  This requires a recognized identity with a high reputation
that is considered relevant to the decision.John suggested that his
doman's signature should be enough to remove distrust.   If his domain was "
pphosted.com" or "mimecast.com", his signature might be sufficient.
 Evaluators know that those signatures mean the message has been initiated
by a big-money organization, and then been filtered to prevent accidental
release of malicious messages.

How does a MLM start building that kind of reputation?

   - Ensure posts are personal messages where MailFrom and From represent
   the same account, or at minimum the same domain.
   - Ensure messages are not impersonated by validating the MailFrom domain
   with SPF, DKIM (in the absence of SPF policy), or a local policy that
   corrects for SPF policy errors.
   - Ensure messages are not malicious by performing best-effort malware
   filtering.
   - Further protect against malware and abuse by restricting high-risk
   attachment types and overly large attachments.
   - Most importantly, publish all of these policies online where a
   subscriber and his mail system administrator will find it.

But yes, it is within the power of MLMs to reject subscriptions from
p=reject domains, especially since alternatives like Gmail are readily
available for free.  But this could have happened already without IETF
advice on the matter.   So how serious is the problem, and how does our
document add value to the negotiation between domains and MLMs?

Doug Foster



On Wed, Apr 12, 2023 at 11:35 PM Murray S. Kucherawy 
wrote:

> On Wed, Apr 12, 2023 at 11:41 AM Todd Herr  40valimail@dmarc.ietf.org> wrote:
>
>> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy 
>> wrote:
>>
>>> I've been thinking about the point a few people have made now that DMARC
>>> has two actors that cause the problem: Those who "blindly" apply
>>> "p=reject", and those who advertise "p=reject".  You do, indeed, need two
>>> to tango; enforcement doesn't happen without an advertising sender and a
>>> participating receiver.  Maybe any "MUST NOT" advice we provide needs to
>>> cover both ends.  We need to be careful about admonishing participating
>>> receivers though.  What would we say to them about how to be selective in
>>> application?
>>>
>>
>> I'd argue that we have language already that advises receivers to be
>> selective in application. The second paragraph of section 5.8, Policy
>> Enforcement Considerations, currently reads as follows in DMARCbis:
>>
>> Mail Receivers MAY choose to accept email that fails the DMARC mechanism
>> check even if the published Domain Owner Assessment Policy is "reject". In
>> particular, because of the considerations discussed in [RFC7960
>> ],
>> it is important that Mail Receivers SHOULD NOT reject messages solely
>> because of a published policy of "reject", but that they apply other
>> knowledge and analysis to avoid situations such as rejection of legitimate
>> messages sent in ways that DMARC cannot describe, harm to the operation of
>> mailing lists, and similar.
>>
>>
>> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#name-policy-enforcement-consider
>>
>> Might that language be made stronger? Sure. Might it or other text
>> include mention of ARC as a possible solution? Maybe.
>>
>
> Right, thanks for the reminder.
>
> I think part of the problem might be that blanket observance of "reject"
> is already commonplace.  There's also very little in the way of algorithms
> or text guidance to indicate to receivers how they're supposed to know when
> it's safe to actually reject.
>
>
>>
>> I've also been thinking about ways to push the burden back on the
>>> advertisers.  Imagine we have some kind of signaling mechanism that MLMs
>>> can take advantage of indicating to them that the author is using a strong
>>> policy, and so it would be possibly a bad idea for the MLM to accept,
>>> mutate, and re-send this message.  This could be a header field or an SMTP
>>> extension (though the latter is complex to get right in a store-and-forward
>>> system).  The MLM can then decide if it i

Re: [dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones  wrote:

> This puts me in mind of Section 8.5, which calls out some potential
> impacts of blocking policies to "Mediators," which role doesn't otherwise
> appear very often in this document. Is there any need to add Mediator
> Actions/Considerations under section 5? Or does this belong in a separate
> document?
>

We should probably review it and think about whether what it says is
enough.

> ISTR there were some vocal and visible mailing list operators that were
> rejecting messages from domains that published "p=reject" policies, maybe
> around 2014-15? I also thought they did this by checking the sending
> domain's published policy in DNS, to your point about implementation.
>
This would be great [anec-]data to have.  Do you remember where you might
have seen it?

> In any case, are we really going to start suggesting that list operators
> start rejecting messages sent from domains that publish a blocking policy,
> as official guidance? (Now I'm looking ever so forward to catching up on
> these other threads - what the heck are people seeing out there??)
>

Well, this WG is chartered to come up with some kind of standards track
solution to the problem.  I don't see one in DMARCbis at the moment.  Given
how long this WG has existed so far, that's a fairly glaring omission.
Doesn't seem to me this idea should be off the table just yet...

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

On Wed, Apr 12, 2023 at 11:41 AM Todd Herr  wrote:

> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy 
> wrote:
>
>> I've been thinking about the point a few people have made now that DMARC
>> has two actors that cause the problem: Those who "blindly" apply
>> "p=reject", and those who advertise "p=reject".  You do, indeed, need two
>> to tango; enforcement doesn't happen without an advertising sender and a
>> participating receiver.  Maybe any "MUST NOT" advice we provide needs to
>> cover both ends.  We need to be careful about admonishing participating
>> receivers though.  What would we say to them about how to be selective in
>> application?
>>
>
> I'd argue that we have language already that advises receivers to be
> selective in application. The second paragraph of section 5.8, Policy
> Enforcement Considerations, currently reads as follows in DMARCbis:
>
> Mail Receivers MAY choose to accept email that fails the DMARC mechanism
> check even if the published Domain Owner Assessment Policy is "reject". In
> particular, because of the considerations discussed in [RFC7960
> ],
> it is important that Mail Receivers SHOULD NOT reject messages solely
> because of a published policy of "reject", but that they apply other
> knowledge and analysis to avoid situations such as rejection of legitimate
> messages sent in ways that DMARC cannot describe, harm to the operation of
> mailing lists, and similar.
>
>
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#name-policy-enforcement-consider
>
> Might that language be made stronger? Sure. Might it or other text include
> mention of ARC as a possible solution? Maybe.
>

Right, thanks for the reminder.

I think part of the problem might be that blanket observance of "reject" is
already commonplace.  There's also very little in the way of algorithms or
text guidance to indicate to receivers how they're supposed to know when
it's safe to actually reject.


>
> I've also been thinking about ways to push the burden back on the
>> advertisers.  Imagine we have some kind of signaling mechanism that MLMs
>> can take advantage of indicating to them that the author is using a strong
>> policy, and so it would be possibly a bad idea for the MLM to accept,
>> mutate, and re-send this message.  This could be a header field or an SMTP
>> extension (though the latter is complex to get right in a store-and-forward
>> system).  The MLM can then decide if it is willing to pass the message
>> unmodified to the list, or reject it with an error like "The policies of
>> this list require modification of your message, which violates your
>> domain's apparent policy.  Your submission therefore cannot be accepted.
>> Please contact your support organization for further assistance."  There's
>> never an opportunity for the collateral bounce to occur if the message is
>> never distributed, and the author domain has to either soften its policy or
>> separate its regular users from its transactional stuff somehow.
>>
>> This avoids the "collateral" and "persistent" damage issues I raised in a
>> separate post.  It still requires the MLMs to do something new, but avoids
>> the need to implement any of a variety of unsavory mutations.  MLMs could
>> also determine this by querying the current DMARC policy of the author's
>> domain, to be sure, so it's a choice between MLMs looking for a header
>> field (which they already know how to do) or becoming DNS-aware (relatively
>> simple, but pulls in some complexities and dependencies they may not want).
>>
>
> My preference here would be to add text for Domain Owners to make them
> understand the ways that p=reject might cause some mail using their domain
> to not make it to its destination, with "mailing lists might reject your
> mail" being one such example.
>

And a good example, given it's the most obvious one.  But is it enough to
say that and nothing else?  What about MLMs actually doing something like
this?

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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 12, 2023, at 2:15 PM, Murray S. Kucherawy  wrote:
> 
> I've been thinking about the point a few people have made now that DMARC has 
> two actors that cause the problem: Those who "blindly" apply "p=reject", and 
> those who advertise "p=reject".  You do, indeed, need two to tango; 
> enforcement doesn't happen without an advertising sender and a participating 
> receiver.  Maybe any "MUST NOT" advice we provide needs to cover both ends.  
> We need to be careful about admonishing participating receivers though.  What 
> would we say to them about how to be selective in application?

Murray, you have RFC 5016 Section 10.3, Item10 as a Functional Specification 
reinforcement basis for a MUST NOT honor DMARC p=reject that causes 3rd party 
problems.   Even though 5016 applied to SSP, it applies equally to DMARCbis too.

—
HLS


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

Re: [dmarc-ietf] Signaling MLMs

[Steven M Jones]

On 4/12/23 11:15 AM, Murray S. Kucherawy wrote:


The MLM can then decide if it is willing to pass the message 
unmodified to the list, or reject it with an error like "The policies 
of this list require modification of your message, which violates your 
domain's apparent policy.  Your submission therefore cannot be 
accepted.  Please contact your support organization for further 
assistance."  There's never an opportunity for the collateral bounce 
to occur if the message is never distributed, and the author domain 
has to either soften its policy or separate its regular users from its 
transactional stuff somehow.


This puts me in mind of Section 8.5, which calls out some potential 
impacts of blocking policies to "Mediators," which role doesn't 
otherwise appear very often in this document. Is there any need to add 
Mediator Actions/Considerations under section 5? Or does this belong in 
a separate document?


ISTR there were some vocal and visible mailing list operators that were 
rejecting messages from domains that published "p=reject" policies, 
maybe around 2014-15? I also thought they did this by checking the 
sending domain's published policy in DNS, to your point about 
implementation.


In which case I think this approach was tried, and I don't recall it 
persisting as a pain point for terribly long - perhaps they moved on to 
"unsavory mutations..."


In any case, are we really going to start suggesting that list operators 
start rejecting messages sent from domains that publish a blocking 
policy, as official guidance? (Now I'm looking ever so forward to 
catching up on these other threads - what the heck are people seeing out 
there??)



On 4/12/23 11:41 AM, Todd Herr wrote:

My preference here would be to add text for Domain Owners to make them 
understand the ways that p=reject might cause some mail using their 
domain to not make it to its destination, with "mailing lists might 
reject your mail" being one such example.
Yes, it seems like we'd either add something short to domain owner 
considerations per Todd, or we'd need to add considerably more to cover 
list operators and/or other Mediators.


--S.

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

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

My own feeling is that lists should have a service agreement / disclosure
statement that says,
"We will modify your text in {manner} for {reason}.".
"We will do {feature} to reduce the risk of unwanted or dangerous list
posts".
"We will do {feature} to minimize use of off-topic posts.   The following
behaviors will ..."
"Your email address will be released to all list participants.   This list
does not condone use of list addresses for non-lust purposes, but cannot
prevent that from occurring.   Consider this possibility when choosing an
address to use for list participation."

My only point of reference is this list, and I am not happy that such a
disclosure was not provided at sign-up.

DF


On Wed, Apr 12, 2023, 2:16 PM Murray S. Kucherawy 
wrote:

> I've been thinking about the point a few people have made now that DMARC
> has two actors that cause the problem: Those who "blindly" apply
> "p=reject", and those who advertise "p=reject".  You do, indeed, need two
> to tango; enforcement doesn't happen without an advertising sender and a
> participating receiver.  Maybe any "MUST NOT" advice we provide needs to
> cover both ends.  We need to be careful about admonishing participating
> receivers though.  What would we say to them about how to be selective in
> application?
>
> We've talked about having signal from the enforcing receivers back to the
> MLM that the bounce occurred because of DMARC, but we haven't seen much
> uptake of that idea for various reasons.
>
> I've also been thinking about ways to push the burden back on the
> advertisers.  Imagine we have some kind of signaling mechanism that MLMs
> can take advantage of indicating to them that the author is using a strong
> policy, and so it would be possibly a bad idea for the MLM to accept,
> mutate, and re-send this message.  This could be a header field or an SMTP
> extension (though the latter is complex to get right in a store-and-forward
> system).  The MLM can then decide if it is willing to pass the message
> unmodified to the list, or reject it with an error like "The policies of
> this list require modification of your message, which violates your
> domain's apparent policy.  Your submission therefore cannot be accepted.
> Please contact your support organization for further assistance."  There's
> never an opportunity for the collateral bounce to occur if the message is
> never distributed, and the author domain has to either soften its policy or
> separate its regular users from its transactional stuff somehow.
>
> This avoids the "collateral" and "persistent" damage issues I raised in a
> separate post.  It still requires the MLMs to do something new, but avoids
> the need to implement any of a variety of unsavory mutations.  MLMs could
> also determine this by querying the current DMARC policy of the author's
> domain, to be sure, so it's a choice between MLMs looking for a header
> field (which they already know how to do) or becoming DNS-aware (relatively
> simple, but pulls in some complexities and dependencies they may not want).
>
> -MSK, trying to be useful here
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Todd Herr]

On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy 
wrote:

> I've been thinking about the point a few people have made now that DMARC
> has two actors that cause the problem: Those who "blindly" apply
> "p=reject", and those who advertise "p=reject".  You do, indeed, need two
> to tango; enforcement doesn't happen without an advertising sender and a
> participating receiver.  Maybe any "MUST NOT" advice we provide needs to
> cover both ends.  We need to be careful about admonishing participating
> receivers though.  What would we say to them about how to be selective in
> application?
>

I'd argue that we have language already that advises receivers to be
selective in application. The second paragraph of section 5.8, Policy
Enforcement Considerations, currently reads as follows in DMARCbis:

Mail Receivers MAY choose to accept email that fails the DMARC mechanism
check even if the published Domain Owner Assessment Policy is "reject". In
particular, because of the considerations discussed in [RFC7960
],
it is important that Mail Receivers SHOULD NOT reject messages solely
because of a published policy of "reject", but that they apply other
knowledge and analysis to avoid situations such as rejection of legitimate
messages sent in ways that DMARC cannot describe, harm to the operation of
mailing lists, and similar.

https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#name-policy-enforcement-consider

Might that language be made stronger? Sure. Might it or other text include
mention of ARC as a possible solution? Maybe.


> We've talked about having signal from the enforcing receivers back to the
> MLM that the bounce occurred because of DMARC, but we haven't seen much
> uptake of that idea for various reasons.
>
> I've also been thinking about ways to push the burden back on the
> advertisers.  Imagine we have some kind of signaling mechanism that MLMs
> can take advantage of indicating to them that the author is using a strong
> policy, and so it would be possibly a bad idea for the MLM to accept,
> mutate, and re-send this message.  This could be a header field or an SMTP
> extension (though the latter is complex to get right in a store-and-forward
> system).  The MLM can then decide if it is willing to pass the message
> unmodified to the list, or reject it with an error like "The policies of
> this list require modification of your message, which violates your
> domain's apparent policy.  Your submission therefore cannot be accepted.
> Please contact your support organization for further assistance."  There's
> never an opportunity for the collateral bounce to occur if the message is
> never distributed, and the author domain has to either soften its policy or
> separate its regular users from its transactional stuff somehow.
>
> This avoids the "collateral" and "persistent" damage issues I raised in a
> separate post.  It still requires the MLMs to do something new, but avoids
> the need to implement any of a variety of unsavory mutations.  MLMs could
> also determine this by querying the current DMARC policy of the author's
> domain, to be sure, so it's a choice between MLMs looking for a header
> field (which they already know how to do) or becoming DNS-aware (relatively
> simple, but pulls in some complexities and dependencies they may not want).
>

My preference here would be to add text for Domain Owners to make them
understand the ways that p=reject might cause some mail using their domain
to not make it to its destination, with "mailing lists might reject your
mail" being one such example.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

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

[dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

I've been thinking about the point a few people have made now that DMARC
has two actors that cause the problem: Those who "blindly" apply
"p=reject", and those who advertise "p=reject".  You do, indeed, need two
to tango; enforcement doesn't happen without an advertising sender and a
participating receiver.  Maybe any "MUST NOT" advice we provide needs to
cover both ends.  We need to be careful about admonishing participating
receivers though.  What would we say to them about how to be selective in
application?

We've talked about having signal from the enforcing receivers back to the
MLM that the bounce occurred because of DMARC, but we haven't seen much
uptake of that idea for various reasons.

I've also been thinking about ways to push the burden back on the
advertisers.  Imagine we have some kind of signaling mechanism that MLMs
can take advantage of indicating to them that the author is using a strong
policy, and so it would be possibly a bad idea for the MLM to accept,
mutate, and re-send this message.  This could be a header field or an SMTP
extension (though the latter is complex to get right in a store-and-forward
system).  The MLM can then decide if it is willing to pass the message
unmodified to the list, or reject it with an error like "The policies of
this list require modification of your message, which violates your
domain's apparent policy.  Your submission therefore cannot be accepted.
Please contact your support organization for further assistance."  There's
never an opportunity for the collateral bounce to occur if the message is
never distributed, and the author domain has to either soften its policy or
separate its regular users from its transactional stuff somehow.

This avoids the "collateral" and "persistent" damage issues I raised in a
separate post.  It still requires the MLMs to do something new, but avoids
the need to implement any of a variety of unsavory mutations.  MLMs could
also determine this by querying the current DMARC policy of the author's
domain, to be sure, so it's a choice between MLMs looking for a header
field (which they already know how to do) or becoming DNS-aware (relatively
simple, but pulls in some complexities and dependencies they may not want).

-MSK, trying to be useful here
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc