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

[Murray S. Kucherawy]

On Sat, Apr 15, 2023 at 3:58 PM Neil Anuskiewicz  wrote:

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

The claim was made that DMARC solves a real problem, which is direct domain
attacks.  I don't think anyone doubts this to be true when it's used in
transaction-only scenarios (the opposite of what we're now calling "general
purpose" domains).

There are two things I think that are important to resolve, and not dismiss
as red herrings:

(1) Exactly how much of a win is it when it's used in a way that disrupts
normal operations?  This may turn out to be a value judgement to some
people, pitting the value of what DMARC actually solves against the value
of what it breaks.  This is extra challenging given the IETF's bias toward
preferring things that interoperate.

(2) Exactly how much of a win is it when attackers can simply change the
domain they're using, use a display name attack, and still successfully
attack the same operator?  If the size of what it defeats turns out to be
small relative to the overall attack space, then I think the answer to this
question influences the answer to the first one.

I think we should expect that these are the sorts of questions on which we
will be challenged when we send this work out to the wider IETF.  Punting
on them as unimportant is not likely to result in a smooth ride.

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

Yes, that's my understanding of the term.  As I recall, Yahoo! moved its
people from yahoo.com to yahoo-inc.com, PayPal's from paypal.com to
paypal-inc.com, Google's from google.com to google-inc.com, etc.

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

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 16 06:00:04 2023

[John Levine]

   Count|  Bytes |  Who
++---
185 ( 100%) |1962907 ( 100%) | Total
 21 (11.4%) | 212655 (10.8%) | Murray S. Kucherawy 
 20 (10.8%) | 193948 ( 9.9%) | Hector Santos 
 20 (10.8%) | 143595 ( 7.3%) | Scott Kitterman 
 19 (10.3%) | 305491 (15.6%) | Douglas Foster 

 17 ( 9.2%) | 130450 ( 6.6%) | Neil Anuskiewicz 
 17 ( 9.2%) | 107256 ( 5.5%) | Alessandro Vesely 
 17 ( 9.2%) |  93836 ( 4.8%) | John Levine 
 10 ( 5.4%) | 124843 ( 6.4%) | Dotzero 
  8 ( 4.3%) |  93887 ( 4.8%) | Barry Leiba 
  7 ( 3.8%) |  81859 ( 4.2%) | Mark Alley 
  5 ( 2.7%) |  96393 ( 4.9%) | Wei Chuang 
  5 ( 2.7%) |  82489 ( 4.2%) | Laura Atkins 
  4 ( 2.2%) |  93906 ( 4.8%) | Brotman, Alex 
  4 ( 2.2%) |  54834 ( 2.8%) | Jesse Thompson 
  3 ( 1.6%) |  66119 ( 3.4%) | Todd Herr 
  3 ( 1.6%) |  17635 ( 0.9%) | Matthäus Wander 
  2 ( 1.1%) |  37557 ( 1.9%) | Emanuel Schorsch 
  1 ( 0.5%) |  11184 ( 0.6%) | Eric D. Williams 
  1 ( 0.5%) |   9688 ( 0.5%) | Steven M Jones 
  1 ( 0.5%) |   5282 ( 0.3%) | Hector Santos 

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