Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Tobias Herkula]

But this is only for “org-domain” evaluation, the example from Doug was about 
“adkim:s vs adkim:r”, but 4.8 speaks about “psd”. If at all if “example.com” 
would have a “psd:y” entry than my first sentence would even be a necessity, as 
there should be no alignment possible between a “domain” and a 
“public-suffix-domain”. Reading through 4.8, I think a more important question 
pops up, my expectation is that PSDs cannot be aligned in sense of DMARCbis to 
the 5322.From header domain, but 4.8 does not really answer that. And I’m not 
sure anymore if that is only my opinion and what the groups intend is with 
DMARCbis in this case.

/ Tobias Herkula

From: dmarc  On Behalf Of Murray S. Kucherawy
Sent: Tuesday, March 12, 2024 8:49 PM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Problem with multiple policies, different alignment

On Tue, Mar 12, 2024 at 6:23 AM Tobias Herkula 
mailto:401und1...@dmarc.ietf.org>> 
wrote:
The DMARC Record on the DKIM signing domain is not relevant for DMARC 
evaluation, so if the 5322.From header domain is 
“example.com<http://example.com>” the “adkim:r” is relevant for evaluation 
regarding your example setup and would consider a DKIM signature domain of 
“sub1.example.com<http://sub1.example.com>” as aligned. It’s the same behavior 
as vice versa. As if the 5322.From header domain is 
“sub1.example.com<http://sub1.example.com>” the “adkim:s” would apply and a 
DKIM signature Domain of “example.com<http://example.com>” should not be 
considered aligned.

Well, Section 4.8 in -30 reads:

== BEGIN ==
For Organizational Domain discovery, it may be necessary to perform multiple 
DNS Tree Walks to determine if any two domains are in alignment. This means 
that a DNS Tree Walk to discover an Organizational Domain might start at any of 
the following locations:
•
* The domain found in the RFC5322.From header of the message being evaluated.
•  * The domain found in the RFC5321.MailFrom header if there is an SPF pass 
result for the message being evaluated.
•  * Any DKIM d= domain if there is a DKIM pass result for that domain for the 
message being evaluated.=== END ===
So it's not clear that the "d=" domain isn't relevant.  Perhaps this list 
should be ordered?

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

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Tobias Herkula]

The DMARC Record on the DKIM signing domain is not relevant for DMARC 
evaluation, so if the 5322.From header domain is “example.com” the “adkim:r” is 
relevant for evaluation regarding your example setup and would consider a DKIM 
signature domain of “sub1.example.com” as aligned. It’s the same behavior as 
vice versa. As if the 5322.From header domain is “sub1.example.com” the 
“adkim:s” would apply and a DKIM signature Domain of “example.com” should not 
be considered aligned.

/ Tobias Herkula

From: dmarc  On Behalf Of Douglas Foster
Sent: Tuesday, March 12, 2024 12:15 PM
To: IETF DMARC WG 
Subject: [dmarc-ietf] Problem with multiple policies, different alignment

I have been building a DMARC implementation, starting with a simple function:
TreeWalk(domain) which returns:

  *   Policy found or not found indicator
  *   Policy Domain
  *   Organizational Domain
  *   Policy record
My thought was that the Tree Walk result was independent of the domain 
identifier being checked, but this is not true.

Assume these DMARC policies:

  *   example.com<http://example.com> aspf:r adkim:r
  *   sub1.example.com<http://sub1.example.com> aspf:s akim:s

When the message contains:

  *   From: u...@sub1.example.com<mailto:u...@sub1.example.com>
  *   DKIM: d=example.com<http://example.com>
Strict alignment on the From domain makes the organizational domain 
unimportant, so the PSL lookup or Tree Walk are not necessary.   The 
organizational domain used for reporting purposes is 
sub1.example.com<http://sub1.example.com>.The DKIM signature is not aligned.

But when the message contains the reverse, the logic gets complicated:

  *   From: u...@example.com<mailto:u...@example.com>
  *   DKIM: d=sub1.example.com<http://sub1.example.com>
If we apply the same Tree Walk to this message, we have a problem.   The From 
domain Tree Walk returns "example.com<http://example.com>" as the 
organizational domain, and the Tree Walk of the DKIM domain returns 
"sub1.example.com<http://sub1.example.com>" as the organizational domain 
because of strict alignment.   So the result appears to be unaligned.

Consequently, the Tree Walk needs to be sensitive to the identifier being 
checked. If the identifier is not the From address, the Tree Walk is only 
interested in the existence of a policy and the PSL tags, and the special case 
related to strict alignment needs to be bypassed.

I don't think this case was covered in previous discussions.

Doug Foster

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

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

[Tobias Herkula]

Signing That, nothing to add.

-Original Message-
From: dmarc  On Behalf Of Barry Leiba
Sent: Tuesday, June 27, 2023 4:24 PM
To: Alessandro Vesely 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

I don't understand how most of your message fits into this discussion:
you're comparing SPF's policy points with DMARC policy.  we're talking about 
SPF as an authentication mechanism together with DKIM (not
DMARC) as an authentication mechanism... and then using those authentication 
results in DMARC policy evaluation.

But here: I've said all this before in separate places, so I'll put it in one 
place, here, one more time:

Given that SPF and DKIM are both configured properly:
1. If SPF passes, DKIM will always pass.
2. If DKIM fails, SPF will always fail.
3. In some scenarios, DKIM will pass when SPF fails.

Therefore, when everything is configured properly, SPF adds no value beyond 
what DKIM does, and DKIM does add value beyond what SPF does.
That's why I am (and others are) arguing that we should remove SPF *from DMARC 
evaluation*.  There's no argument that for now, or some, SPF outside of DMARC 
still has value.

What others are arguing is that in the real world, things do get 
mis-configured, and if DKIM is misconfigured and fails when it shouldn't, SPF 
adds value by providing a working authentication.
(And, of course, similarly the other way around, plus DKIM covers some cases 
when messages are relayed or forwarded.)  That speaks for "SPF
*or* DKIM".

But "SPF *and* DKIM" -- requiring *both* to pass -- is technically unnecessary 
at best, because of (1) above: DKIM should always pass when SPF passes.  But 
where the harm comes is in cases of mis-configuration, because now if *either* 
of them is misconfigured, the whole thing fails -- neither of them serves as a 
backup for the other; instead, the misconfiguration of either one causes 
deliverability problems.  DMARC is damaged by requiring an authentication 
situation that is unnecessary when things are properly configured, and that is 
more fragile than what we've been using, more susceptible to configuration 
errors than we've seen before.

And I'm afraid that people will use it preferentially, *thinking* that it 
provides better "security" -- surely, double authentication is better than 
single, no?

No.

Barry

On Tue, Jun 27, 2023 at 6:36 AM Alessandro Vesely  wrote:
>
> On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote:
> > I'm saying I don't want "and" to be an option, because I think it's 
> > damaging to DMARC.  There is no reason anyone should ever want to 
> > say that, and providing the option asks for misconfigurations 
> > because people think it's somehow "more secure".  It's not more 
> > secure.  It would be very bad for deliverability of legitimate mail 
> > and would provide no additional security.  It would be a terrible mistake.
>
>
> I've been sporting spf-all for years, and seldom experienced bounces, 
> mostly due to misconfigured secondary MXes.  Out of 39 domains whose 
> posts to this list in the past year are still in my inbox, 14 have 
> spf-all.  So, while I'm not the only one, not many published -all even 
> though it may seem to be somehow more secure.
>
> I think it can be worth to compare SPF and DMARC.  Another sender 
> policy a decade and an authentication method after.  What adoption, what hype.
>
> Both policies ask receivers to reject a domain identifier in some 
> cases.  RFC
> 7208 explicitly suggests to consider whitelisting (Appendix D).  DMARC 
> provides for overrides but is less clear about how to handle 
> exceptions.  After SPF broke forwarding, the reaction was split 
> between some changing identifier and turning to ~all; after DMARC 
> broke mailing lists, between changing identifier and not altering 
> messages.  In my limited experience, the ratio seems to be higher for DMARC 
> than SPF, but I may be wrong.
>
> In theory, domains that currently have a strict DMARC policy and 
> spf-all, 6 of the above, should have their messages blocked when 
> either method fails, up to changing identifiers.  Why would it be so 
> bad for deliverability to additionally require DMARC alignment, which 
> is the difference between that and the "and"?
>
> And, it seems to me that an ESP not having a bloated SPF record could 
> stop a good deal of DKIM replay by resorting to auth=dkim+spf.  
> Besides collateral deliverability problems, why wouldn't that work?
>
> Wht would "and" damage DMARC more than -all damaged SPF?
>
> I hope we can discuss detailed criticism rather than vague ostracism.
>
>
> Best
> Ale
> --
>
>
>
>
>

___
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] DMARC2 & SPF Dependency Removal

[Tobias Herkula]

Sadly they can’t, there are Mailbox Providers that expect SPF Records, so to 
maintain deliverability to those, you have to keep SPF records in place and 
can’t switch to an DKIM only DMARC.

/ Tobias

From: dmarc  On Behalf Of Murray S. Kucherawy
Sent: Sunday, June 18, 2023 2:42 AM
To: Ken Simpson 
Cc: Douglas Foster ; Jan Dušátko 
; dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Sat, Jun 17, 2023 at 2:40 PM Ken Simpson 
mailto:ksimp...@mailchannels.com>> wrote:
FWIW, I'd like to chuck my hat in the ring on the side of removing SPF from the 
next iteration of DMARC. As the operator of an email delivery service with tens 
of millions of primarily uncontrolled senders on web hosting servers, it would 
be great if domain owners could assert via their DMARC record that receivers 
should only trust DKIM-signed email.

Can these senders not accomplish the same thing by removing the SPF record 
altogether?

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

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

[Tobias Herkula]

If we move to DMARC2 version string this would be solved easily, we could add 
the requirement to the tree-walk algo, we fallback to DMARC1 records if the 
tree-walk does not find a DMARC2 one. So, the long-tail can continue running in 
their current environment and upgrade on their own pace to the next DKIM only 
DMARC.

/ Tobias

Von: Seth Blank 
Datum: Donnerstag, 8. Juni 2023 um 16:35
An: Barry Leiba 
Cc: Seth Blank , Tobias Herkula , 
"dmarc@ietf.org" 
Betreff: Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

I’ll bring data. I think there’s a practical problem here and a class of 
services that are not email-first which will break completely (ie get 
immediately rejected) were such a change to be made.

This feels like a significant interoperability problem we’d be introducing.

I’m loathe to add flags when we’ve been so good at simplifying DMARC through 
the bis process and removing flags, but what about a way to say “I only send 
with DKIM, and do not evaluate SPF on my behalf”?

That wouldn’t create an interop problem, and gives a path to upgrade without 
creating breaking change out of the gate?

Seth

On Thu, Jun 8, 2023 at 16:05 Barry Leiba 
mailto:barryle...@computer.org>> wrote:
Oh, and as to your last paragraph, I think it’s the wrong question.  What we 
need to understand is that SPF is ineffective, and DKIM is what’s necessary to 
make DMARC work effectively.  When we started, DKIM was not as broadly deployed 
and we didn’t understand how bad SPF would be.  We have different information 
now, and we need to say that of you want to reliably authenticate you have to 
use DKIM… that’s it.

Barry

On Thu, Jun 8, 2023 at 3:54 PM Seth Blank 
mailto:s...@sethblank.com>> wrote:
Participating, while running around so apologies for terseness:

Sophisticated senders do DKIM. The long tail, we're lucky if they do SPF. Some 
authentication is better than none.

The problem isn't people evaluating SPF vs DKIM and choosing the easier option. 
It's people who have a business, who bolt on email, and then struggle to 
authenticate through any means. Again, we're lucky when we get SPF from them, 
and I'll still take that over no auth all day every day.

Don't disagree at all with the myriad problems with SPF, and that the goal 
should be to eliminate it. I just don't believe we're anywhere close to that 
being a reality yet.

The data that led to DMARC showed that SPF and DKIM were both necessary to 
determine legitimacy broadly. What would we need to understand now to see if 
only DKIM is necessary?

On Thu, Jun 8, 2023 at 3:44 PM Barry Leiba 
mailto:barryle...@computer.org>> wrote:
See, I don't look at it as "harmed".  Rather, I think they're using "we use 
SPF" as a *reason* not to use DKIM, and I think that *causes* harm.

SPF is, as I see it, worse than useless, as it adds no value to domain that use 
DKIM -- any time DKIM fails SPF will also fail -- and actually impedes the 
adoption of DKIM.  Reliance on SPF causes DMARC failures that result in 
deliverability problems for legitimate mail.  I wholeheartedly support removal 
of SPF as an authentication mechanism that DMARC accepts.

Barry, as participant

On Thu, Jun 8, 2023 at 3:30 PM Seth Blank 
mailto:40valimail@dmarc.ietf.org>> 
wrote:
Participating, I have data that I believe points to a long tail of businesses 
who predominantly only authenticate on behalf of others using SPF, and would be 
harmed by such a change. It will take me a little while to confirm and share.

I also know a predominant ccTLD with millions of registrations, that has SPF on 
roughly 80% of them, but DMARC on barely 5%. I don't have data on DKIM for 
those, but I assume it's closer to the DMARC penetration than the SPF one. I'll 
see if I can get this data to share more publically, and also get the DKIM 
answer.

Of course the goal is aligned dkim with a stated policy, but I don't think the 
data supports us being anywhere close to that realistically.

As Chair, this is a valuable conversation to have with real data on problems 
and opportunities at scale, and am excited to see Tobias share and see what 
others have to say.

Seth

On Thu, Jun 8, 2023 at 3:21 PM Murray S. Kucherawy 
mailto:superu...@gmail.com>> wrote:
On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula 
mailto:401und1...@dmarc.ietf.org>> 
wrote:
My team recently concluded an extensive study on the current use and 
performance of DMARC. We analyzed a staggering 3.2 billion emails, and the 
insights drawn are quite enlightening. Of these, 2.2 billion emails 
(approximately 69%) passed the DMARC check successfully. It's quite an 
achievement, reflective of our collective hard work in fostering a safer, more 
secure email environment.

However, upon further analysis, it's evident that a mere 1.6% (or thirty-six 
million) of these DMARC-passed emails relied exclusively on the Sender Policy 
Framework (SPF) for validation. This is a remark

[dmarc-ietf] DMARC2 & SPF Dependency Removal

[Tobias Herkula]

Hi All,

This message comes out of some discussions I had at the current MAAWG meeting 
in Dublin.

I hope this message finds you well. The intent of this is to propose and 
discuss an evolutionary step in the DMARC protocol, which I believe will result 
in increased efficiency, reduced DNS load, and a more accurate reflection of 
the current email landscape.

My team recently concluded an extensive study on the current use and 
performance of DMARC. We analyzed a staggering 3.2 billion emails, and the 
insights drawn are quite enlightening. Of these, 2.2 billion emails 
(approximately 69%) passed the DMARC check successfully. It's quite an 
achievement, reflective of our collective hard work in fostering a safer, more 
secure email environment.

However, upon further analysis, it's evident that a mere 1.6% (or thirty-six 
million) of these DMARC-passed emails relied exclusively on the Sender Policy 
Framework (SPF) for validation. This is a remarkably low volume compared to the 
overall DMARC-passed traffic, raising questions about SPF's relevancy and the 
load it imposes on the DNS systems.

Given the current use case scenarios and the desire to optimize our resources, 
I propose that we explore the possibility of removing the SPF dependency from 
DMARC. This step could result in a significant reduction in DNS load, increased 
efficiency, and an accurate alignment with our predominant use cases.

However, such a fundamental shift in the protocol's architecture warrants a 
clear signifier. I suggest we upgrade our DMARC version string from the current 
state to 'DMARC2.' This upgrade would not only denote the change of SPF 
removal, but also the switch from the Public Suffix List (PSL) to the Tree-Walk 
algorithm.

By moving towards DMARC2, we not only update our standard to better reflect our 
present requirements, but we also make a clear commitment to the ongoing 
evolution and improvement of the protocol.

Best regards,

Tobias Herkula
Mail Security & Transfer
1&1 (GMX, Web.de, Mail.com, IONOS)
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Section 5 - DKIM-only authentication

[Tobias Herkula]

Hi John,

I have one bigger example back from the days when I was working for an ESP. The 
Situation was that a financial Institution decided to sign all their messages 
with DKIM and deploy a DMARC reject policy and an active decision against a 
strict SPF record. Because a huge part of their Emails where constantly 
forwarded by their customer base and that created a lot of FP DMARC reports. At 
the same time a lot of their customers used a Mailboxprovider that required 
strict SPF records for Bulkmailersender. This dilemma wasn't solvable back then 
and isn't solvable now. As SPF is a global decision that needs to be made in 
comparison to DKIM where it is applied individually for each Email send 
Splitting that up into multiple Domains or Subdomains is not a viable 
alternative regarding Brand recognition, if my main goal is to reduce phishing 
attacks to my userbase.
And I'm pretty sure that there are lot of people on this list here that are 
aware of Mailboxproviders who are very strict on requirements for 
Bulkmailsender, and it would be much easier to comply with these requirements 
if DMARC would allow to specify that a valid DKIM Signature is needed to pass 
the DMARC check, so that a SPF policy can be omitted to prevent forwarding 
problems or can be published to honor MBP requirements without increasing the 
perceived Risk of loose SPF-RR...

/ Tobias


-Ursprüngliche Nachricht-
Von: John Levine  
Gesendet: Dienstag, 4. Januar 2022 23:54
An: dmarc@ietf.org
Cc: Tobias Herkula 
Betreff: Re: [dmarc-ietf] Section 5 - DKIM-only authentication

It appears that Tobias Herkula   said:
>the often stated argument of simply not publishing SPF records if a 
>Sender wants DKIM-only DMARC is not a viable solution in the real world.

If your SPF record accurately describes the sources of your mail, can you 
explain why it would be a problem for that to validate DMARC?

The obvious problem would be "my mail provider is so incompetent that they let 
other people send phishes with my address" but that is definitely not a problem 
for anyone else to solve.

R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Section 5 - DKIM-only authentication

[Tobias Herkula]

One big thing missing in the Discussion are Receiver obligations, I encountered 
a lof of Mailbox Providers that demand a valid and concise SPF record, and in 
this case the Sender has no way to state that he requires DKIM signatures for 
DMARC, the often stated argument of simply not publishing SPF records if a 
Sender wants DKIM-only DMARC is not a viable solution in the real world.

/ Tobias

Von: dmarc  Im Auftrag von Ken O'Driscoll
Gesendet: Dienstag, 4. Januar 2022 15:34
An: Douglas Foster 
Cc: IETF DMARC WG 
Betreff: Re: [dmarc-ietf] Section 5 - DKIM-only authentication


Organisations using DKIM-only (also SFP-only) with an enforcing DMARC policy 
are more common than you may think. While some configurations are perhaps in 
error, many I have encountered are deliberate decisions based on specific use 
cases.

For example, I have a finance house that uses DKIM-only auth with p=reject on 
their main domain. When deploying DMARC they risked it and decided that giving 
a third-party control of their SPF (via an include) was not an option. It’s a 
valid reason whether one personally agrees with it or not. There are tons of 
other reasons why organisations make similar decisions.

Single auth is actively used in the wild.

Ken.

From: dmarc mailto:dmarc-boun...@ietf.org>> On Behalf 
Of Douglas Foster
Sent: Monday 27 December 2021 13:51
To: IETF DMARC WG mailto:dmarc@ietf.org>>
Subject: [dmarc-ietf] Section 5 - DKIM-only authentication

These two sections assume that some domain owners will want DMARC 
authentication to be based on DKIM only.

5 Policy
A Domain Owner can also choose to not have some underlying authentication 
technologies apply to DMARC evaluation of its domain(s). In this case, the 
Domain Owner simply declines to advertise participation in those schemes. For 
example, if the results of path authorization checks ought not be considered as 
part of the overall DMARC result for a given Author Domain, then the Domain 
Owner does not publish an SPF policy record that can produce an SPF pass result.

5.7.2. Determine Handling Policy
Heuristics applied in the absence of use by a Domain Owner of either SPF or 
DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be the case that 
the Domain Owner wishes a Message Receiver not to consider the results of that 
underlying authentication protocol at all.

We agreed to drop the reference to Best-Guess-SPF, but we have not addressed 
the underlying requirement.  Do we actually have domain owners who do not want 
SPF included in the DMARC evaluation process?  If so, why?

I am guessing that this request could only originate from a domain owner with a 
valid but overly inclusive SPF record, probably because of include clauses.   
The suggested strategy of no SPF record, or the equivalent "?ALL", or not 
acceptable.   These approaches only make a weak SPF policy even weaker.To 
allow an overly-broad SPF policy to be ignored for DMARC purposes, we should 
provide an explicit policy flag for this purpose.

But each new option adds complexity.   Is this option actually valuable to 
somebody?
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational Alignment Options

[Tobias Herkula]

I'm aware of that, to be more explicit about my meaning. At least I currently 
believe (I don't know) that there is a difference in buying the domain 
"mydomain.example" under the assumption that .example is a gTLD, sTLD or ccTLD 
in comparison of buying a domain from ME, like "harharhar.mydomain.example".

-Ursprüngliche Nachricht-
Von: John Levine  
Gesendet: Freitag, 5. November 2021 18:58
An: dmarc@ietf.org
Cc: Tobias Herkula 
Betreff: Re: [dmarc-ietf] Organizational Alignment Options

It appears that Tobias Herkula   said:
>-=-=-=-=-=-
>Threat risk: I totally agree the ORG begins with the first label that 
>is not considered to be a PSD, but at least I want to know if that 
>decision is based on contractual obligations from ICANN/IANA or only a 
>business decision by an entity with a very different legal status, compared to 
>the other. And here a DNS based solution would need to be able to transport 
>that information. So, a rectification that DMARC shall only consider the 
>PUBLIC part of the PSL would be enough and easier for most entities.

If you think the public part of the PSL is "contractual obligations from 
ICANN/IANA" I have bad news for you. That is not even sort of what it is. It's 
a combination of info from the domain operators and guesses by the PSL 
maintainers, with a lot of references to Wikipedia.
I know of a lot of entries that are missing, like city 3LDs in Canada.
Even for TLDs that have ICANN contracts, there are a lot of entries unrelated 
to anything in the contract such as the 90 2LDs in .aero that the PSL includes.

It also has a lot of stale data. I like this comment:

// TODO: Check for updates (expected to be phased out around Q1/2009)

The PSL has no way to describe vanity TLDs where every name belongs to the same 
entity. They are listed as regular TLDs like .com but that isn't correct.

The tree walk allows the domain holder to publish its own policy about what its 
org domain, if any, is.  That matches the rest of DMARC.

R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational Alignment Options

[Tobias Herkula]

t complexity.

The tree walk stops when a policy is found.   Given the apparently flat nature 
of most email addresses, and the other complexities of email filtering, I don't 
see that DNS lookups are a significant design consideration.

Doug Foster

On Thu, Nov 4, 2021 at 9:19 AM Tobias Herkula 
mailto:tobias.herk...@1und1.de>> wrote:
As an entity you want to be on the PSL to declare an organizational boundary, 
and usage is now for Cookies, Certificates, Domain Reputation and most likely a 
longer list of more obscure individual use cases. So most of the time a DNS-RR 
on a DNS label that states “I’m a PSL” is the use-case that would be needed. 
The Problem that comes with a simple DNS-RR is, that it’s not possible anymore 
to discern between a PRIVATE decision to be a PSL and a PUBLIC (ICANN/IANA 
contract obligation) decision to be a PSL. And that would make it much harder 
to tackle malicious intent. For example:

_psl.com<http://psl.com>. IN TXT “true” == This is fine, and therefore for any 
first DNS label below “.com.” it would be clear to others that there is an 
organizational boundary between “example.com<http://example.com>” and 
“domain.com<http://domain.com>”.

But what happens if we suddenly encounter:

_psl.example.com<http://psl.example.com>. IN TXT “true” == This is not fine as 
there is no way to know if “example.com<http://example.com>” belongs to the 
same legal entity as “.com”.

The publicsuffic.org<http://publicsuffic.org> list provides a way to transport 
Registry policies about what DNS labels can be registered in flat format, if 
that needs to move to the DNS we would need a BI-directional solution similar 
to DNSSEC to make it “impossible” to fake such records.

Why?

Especially for Email, and that is what DMARC cares for, a Malicious Actor could 
use a single domain and generate a PSL DNS-RR and then he can use every 
subdomain of this domain to spam around with a different SPF/DKIM/DMARC 
setting, and only manual intervention can group all these mails together by the 
real org-domain (responsible entity).

Could someone explain why wee need a complex policy discovery algorithm? As 
from my perspective there are 2 places I would look for a DMARC policy right 
now, thats the 5322.From Domain at-hand and the org-domain of the 5322.From 
domain and for this, with the help of the PSL, that would be 2 DNS requests, do 
I miss a very important use case for DMARC that is not solved by these 2 querys?

Von: dmarc mailto:dmarc-boun...@ietf.org>> Im Auftrag 
von Douglas Foster
Gesendet: Donnerstag, 4. November 2021 11:54
An: Alessandro Vesely mailto:ves...@tana.it>>
Cc: IETF DMARC WG mailto:dmarc@ietf.org>>
Betreff: Re: [dmarc-ietf] Organizational Alignment Options

It would be helpful to understand why people want to climb into the 
publicsuffix.org<http://publicsuffix.org> list.My guess:   An ISP, such as 
"ISP.TLD" allows customers to create websites under their parent.   They need 
to be able to indicate that website JohnSmith.ISP.TLD is independent of website 
IvanWatson.ISP.TLD, and therefore cross-site scripting defenses should treat 
them as two organizations rather than one.This scenario needs a flag that 
says "No alignment for XSS purposes", and the set of names that need that flag 
may be very different from the set of names that need a DMARC non-alignment 
flag.So a set of feature-specific DNS flags will indeed be a better 
long-term design than a simple "I'm a PSL" flag.

I can't answer whether PSLs will cooperate by publishing DNS entries.   My 
original suggestion was to specify the flag syntax in the RFC, so that 
deployment negotiations can begin, while recommending that implementers use 
both.   For the same reason that I did not see a threat risk, I would place 
greater trust in the DNS entry when it is present, so I would check DNS first.  
But I would also check the publicsuffix.org<http://publicsuffix.org> list to 
handle the problem of DNS non-participation.

Can someone explain the private/public distinction in the PSL list?   What does 
the distinction mean as it relates to the four email-related attributes that I 
have listed?

Doug

On Thu, Nov 4, 2021 at 4:34 AM Alessandro Vesely 
mailto:ves...@tana.it>> wrote:
On Thu 04/Nov/2021 04:09:37 +0100 Douglas Foster wrote:
> Ale asks:
>
>>  Hm... but PSDs don't seem to gain any extras by letting receivers know 
>> they're
>>  a PSD, do they?
>
> I think they do.   They get the benefits of name protection which DMARC
> previously afforded only to organizational domains and subdomains, which I
> would expect them to consider very valuable.   While the 
> publicsuffix.org<http://publicsuffix.org>
> <http://publicsuffix.org> provides some protection, I would think they should
> prefer transferring control of their status from the volunteers to th

Re: [dmarc-ietf] Organizational Alignment Options

[Tobias Herkula]

As an entity you want to be on the PSL to declare an organizational boundary, 
and usage is now for Cookies, Certificates, Domain Reputation and most likely a 
longer list of more obscure individual use cases. So most of the time a DNS-RR 
on a DNS label that states “I’m a PSL” is the use-case that would be needed. 
The Problem that comes with a simple DNS-RR is, that it’s not possible anymore 
to discern between a PRIVATE decision to be a PSL and a PUBLIC (ICANN/IANA 
contract obligation) decision to be a PSL. And that would make it much harder 
to tackle malicious intent. For example:

_psl.com. IN TXT “true” == This is fine, and therefore for any first DNS label 
below “.com.” it would be clear to others that there is an organizational 
boundary between “example.com” and “domain.com”.

But what happens if we suddenly encounter:

_psl.example.com. IN TXT “true” == This is not fine as there is no way to know 
if “example.com” belongs to the same legal entity as “.com”.

The publicsuffic.org list provides a way to transport Registry policies about 
what DNS labels can be registered in flat format, if that needs to move to the 
DNS we would need a BI-directional solution similar to DNSSEC to make it 
“impossible” to fake such records.

Why?

Especially for Email, and that is what DMARC cares for, a Malicious Actor could 
use a single domain and generate a PSL DNS-RR and then he can use every 
subdomain of this domain to spam around with a different SPF/DKIM/DMARC 
setting, and only manual intervention can group all these mails together by the 
real org-domain (responsible entity).

Could someone explain why wee need a complex policy discovery algorithm? As 
from my perspective there are 2 places I would look for a DMARC policy right 
now, thats the 5322.From Domain at-hand and the org-domain of the 5322.From 
domain and for this, with the help of the PSL, that would be 2 DNS requests, do 
I miss a very important use case for DMARC that is not solved by these 2 querys?

Von: dmarc  Im Auftrag von Douglas Foster
Gesendet: Donnerstag, 4. November 2021 11:54
An: Alessandro Vesely 
Cc: IETF DMARC WG 
Betreff: Re: [dmarc-ietf] Organizational Alignment Options

It would be helpful to understand why people want to climb into the 
publicsuffix.org list.My guess:   An ISP, such as 
"ISP.TLD" allows customers to create websites under their parent.   They need 
to be able to indicate that website JohnSmith.ISP.TLD is independent of website 
IvanWatson.ISP.TLD, and therefore cross-site scripting defenses should treat 
them as two organizations rather than one.This scenario needs a flag that 
says "No alignment for XSS purposes", and the set of names that need that flag 
may be very different from the set of names that need a DMARC non-alignment 
flag.So a set of feature-specific DNS flags will indeed be a better 
long-term design than a simple "I'm a PSL" flag.

I can't answer whether PSLs will cooperate by publishing DNS entries.   My 
original suggestion was to specify the flag syntax in the RFC, so that 
deployment negotiations can begin, while recommending that implementers use 
both.   For the same reason that I did not see a threat risk, I would place 
greater trust in the DNS entry when it is present, so I would check DNS first.  
But I would also check the publicsuffix.org list to 
handle the problem of DNS non-participation.

Can someone explain the private/public distinction in the PSL list?   What does 
the distinction mean as it relates to the four email-related attributes that I 
have listed?

Doug

On Thu, Nov 4, 2021 at 4:34 AM Alessandro Vesely 
mailto:ves...@tana.it>> wrote:
On Thu 04/Nov/2021 04:09:37 +0100 Douglas Foster wrote:
> Ale asks:
>
>>  Hm... but PSDs don't seem to gain any extras by letting receivers know 
>> they're
>>  a PSD, do they?
>
> I think they do.   They get the benefits of name protection which DMARC
> previously afforded only to organizational domains and subdomains, which I
> would expect them to consider very valuable.   While the 
> publicsuffix.org
>  provides some protection, I would think they should
> prefer transferring control of their status from the volunteers to themselves.
>
> "I am a PSD means" four things:
>
> 1. "If you see a message with an SMTP address that uses my PSD name, it is  
> fraudulent and should be blocked."
>
> 2. "If you see a message with a FROM header that uses my PSD name, it is 
> fraudulent and should be blocked."
>
> 3. "If you see a DKIM signature that uses my PSD name, it will not verify  
> because the public key will be missing, but it is not merely unverified  
> material to ignore, it is positive evidence of a fraud attempt."
>
> 4. "If you are doing DMARC alignment testing, don't match on my PSD name,   
> You  are not looking at an organization record."


I agree those four make for a commendable behavior, but they are not 

Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

[Tobias Herkula]

I'm more or less thinking we should keep the alignment method as is, and only 
rephrase the subordinate clause to something that puts an emphasis on the fact 
that we currently don't have a perfect solution, and the PSL has shown to be a 
very stable external entity that is fine to use until something better comes 
around. If my google-foo is not failing me, the cab forum already discussed 
that at the beginning of the last decade, and still here we are at the end of 
2021 and are kind of fine with what the PSL provides.

Every big change, like reference tags inside of DMARC records or even a more 
sophisticated solution that tries to solve that not only for DMARC but for 
others as well should be handled outside of this discussion here. We have 
enough examples with other standards that opted for a dependency instead of 
trying to solve it alone. And if that is so important, "dbound" is not dead, 
only concluded...

-Ursprüngliche Nachricht-
Von: dmarc  Im Auftrag von Scott Kitterman
Gesendet: Dienstag, 2. November 2021 00:04
An: dmarc@ietf.org
Betreff: Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy 
Discovery



On November 1, 2021 10:51:13 PM UTC, Dotzero  wrote:
>On Mon, Nov 1, 2021 at 6:08 PM Tobias Herkula 
>wrote:
>
>> Yes this is used in a significant way, dropping the mechanic of the 
>> org-domain would make a lot of things in processing inbound mail 
>> streams a lot more complicated.
>>
>> The PSL does not exists for DKIM or DMARC, it is a product of the CAB 
>> forum. And the idea was borrowed for DMARC, but without it, DMARC 
>> will have a hard time, and depending standards as well. I don't want 
>> to discuss how good or bad BIMI is, but without an "org-domain" it 
>> doesn't work. But if DMARC as one of the base requirements for BIMI drops 
>> the "org-domain"
>> mechanic, you really need to produce a better alternative than, 
>> simply stating that things that are currently OK to do, are not used 
>> by enough entities and could be abandoned.
>>
>> I see a couple billion mails per week and can assure you that 
>> 5322.From's with a Sub-Domain but signed with the org-domain are a 
>> regular picture of totally valid mail streams, and this whole concept 
>> goes even deeper for large mail processors. It makes a huge 
>> difference for measuring reputation and responsibilities. And I think 
>> that this should be the baseline for the discussion here. As a mail 
>> receiver, I would at least assume, I and most of my colleagues use 
>> the org-domain concept to pin responsibilities to a clear and 
>> dedicated entity. If we abandon this, we are opening additional 
>> attack vectors without any increase in functionality and even 
>> increasing the complexity for almost all parties, only for the sake of 
>> getting the PSL out of the equation.
>>
>> Querying the PSL in a compiled trie data structure is much faster 
>> than even doing one DNS request, and even with the private part of 
>> the PSL this is a couple MB of memory. I get Mails that are larger 
>> than downloading the PSL once per day for a year. So why are we 
>> having this discussion? I know the PSL is not perfect, and I'm 
>> totally in for change if something doesn't work, but we have seen 
>> that DBound didn't made it and there are no real heavy usage PSL 
>> alternatives.
>>
>> And one thing I really don't get, why do we want to solve that so 
>> heavily that we use scare tactics with phrasing like "if we don't 
>> solve it now, we would need to write another RFC in a couple of 
>> years", isn't that totally fine, for a standard to evolve and update it if 
>> it needs an update?
>>
>
>Thank you for your voice of reason Tobias. It would appear that some 
>are willing to create a larger problem in order to address a smaller problem.

Let me assure you, I'm not trying to break anything, very much the opposite.  
It's difficult for people like me without access to tons of data to generalize 
from what we do have.  It appears that some of my assumptions are in error, so 
we shouldn't act on them.

That said, I don't think BIMI's needs should be a factor in the DMARC design.  
If BIMI needs an org domain and it turns out DMARC doesn't, then they can 
define it to support their needs.

I think we've just started a conversation on how to address change (if any) in 
the DMARC alignment algorithm.  We're nowhere near the end, so please don't 
panic.

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] same old org domain, Topic for IETF 112 - Policy Discovery

[Tobias Herkula]

Yes this is used in a significant way, dropping the mechanic of the org-domain 
would make a lot of things in processing inbound mail streams a lot more 
complicated.

The PSL does not exists for DKIM or DMARC, it is a product of the CAB forum. 
And the idea was borrowed for DMARC, but without it, DMARC will have a hard 
time, and depending standards as well. I don't want to discuss how good or bad 
BIMI is, but without an "org-domain" it doesn't work. But if DMARC as one of 
the base requirements for BIMI drops the "org-domain" mechanic, you really need 
to produce a better alternative than, simply stating that things that are 
currently OK to do, are not used by enough entities and could be abandoned.

I see a couple billion mails per week and can assure you that 5322.From's with 
a Sub-Domain but signed with the org-domain are a regular picture of totally 
valid mail streams, and this whole concept goes even deeper for large mail 
processors. It makes a huge difference for measuring reputation and 
responsibilities. And I think that this should be the baseline for the 
discussion here. As a mail receiver, I would at least assume, I and most of my 
colleagues use the org-domain concept to pin responsibilities to a clear and 
dedicated entity. If we abandon this, we are opening additional attack vectors 
without any increase in functionality and even increasing the complexity for 
almost all parties, only for the sake of getting the PSL out of the equation. 

Querying the PSL in a compiled trie data structure is much faster than even 
doing one DNS request, and even with the private part of the PSL this is a 
couple MB of memory. I get Mails that are larger than downloading the PSL once 
per day for a year. So why are we having this discussion? I know the PSL is not 
perfect, and I'm totally in for change if something doesn't work, but we have 
seen that DBound didn't made it and there are no real heavy usage PSL 
alternatives.

And one thing I really don't get, why do we want to solve that so heavily that 
we use scare tactics with phrasing like "if we don't solve it now, we would 
need to write another RFC in a couple of years", isn't that totally fine, for a 
standard to evolve and update it if it needs an update?

-Ursprüngliche Nachricht-
Von: dmarc  Im Auftrag von Scott Kitterman
Gesendet: Montag, 1. November 2021 21:24
An: dmarc@ietf.org
Betreff: Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy 
Discovery

On Monday, November 1, 2021 3:17:05 PM EDT Alessandro Vesely wrote:
> From: u...@sub.example.org, signed by example.org which also publishes 
> a policy has to be valid.

Why?  Do you know of this construct being used in any significant way?

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] DMARC variations

[Tobias Herkula]

I’m the Author of that pamphlet and yes „slow-entry“ stands for rate limiting, 
as we do not plan to reject traffic completly, I also would like to mention 
that this is a WIP document and I’m fascinated that it pops up here, as it only 
was a small comment on a completly different topic. I would also like to 
emphasis that this is not directly DMARC related as the goal we want to achieve 
is different and we also plan to bring our DMARC implementation forward at the 
same time.

/ Tobias Herkula
--
Senior Product Owner Mail Security
Product Mail Platform

1&1 Mail & Media GmbH

Von: dmarc  Im Auftrag von Douglas Foster
Gesendet: Sonntag, 24. Oktober 2021 19:37
An: Alessandro Vesely 
Cc: dmarc-ietf 
Betreff: Re: [dmarc-ietf] DMARC variations

What is meant by "slow entry" in the title?   Does it mean that non-compliant 
messages will be throttled with 4xx temporay failure result codes?


On Sun, Oct 24, 2021, 10:51 AM Alessandro Vesely 
mailto:ves...@tana.it>> wrote:
Hi all,

this proposal by some German mailbox providers sounds interesting:

https://docs.google.com/document/d/e/2PACX-1vQeodijKJJJPX6fCma3tm00n8m0aJI0VyuO17hKXTy0y7JYUzIxd5Cqh2VSttvJkw-yxWK5fT8NFDcO/pub

Note that it "is not directly referencing DMARC as a technology with similar 
functionalities, as [they] strive to establish a common ground, where DMARC, 
BIMI and future Systems can build up additional benefits for all sides."


Best
Ale
--








___
dmarc mailing list
dmarc@ietf.org<mailto: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] Sender-supplied decision matrix for passing DMARC

[Tobias Herkula]

This risks sendability with the fact that there are a lof of receivers that 
require SPF-RRs. So not providing SPF-RRs also fails with such an requirement. 
Besides that does SPF not help with any kind of 5322.From spoofing, but this 
ist he most important identifier for an enduser.

/ Tobias Herkula

Senior Product Owner Mail Security
Mail Application Security

1&1 Mail & Media GmbH | Mitte | 10115 Berlin | Deutschland
E-Mail: tobias.herk...@1und1.de<mailto:tobias.herk...@1und1.de> | Web: 
www.1und1.de<http://www.1und1.de>

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 7666

Geschäftsführer: Alexander Charles, Thomas Ludwig, Jan Oetjen, Sandra Vollmer

Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen 
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten 
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, 
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise 
auch immer zu verwenden.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient of this e-mail, you are hereby notified that saving, 
distribution or use of the content of this e-mail in any way is prohibited. If 
you have received this e-mail in error, please notify the sender and delete the 
e-mail.



Von: dmarc  Im Auftrag von Seth Blank
Gesendet: Montag, 14. Juni 2021 19:45
An: Brotman, Alex ; dmarc@ietf.org
Betreff: Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

HUGE cringe ;-) DMARC has an explicit policy that either SPF or DKIM must pass 
aligned. This proposal breaks that foundationally.

This is suggested quite frequently, but fails to understand just how few 
senders of email actually send with DKIM. Most email is sent from services that 
have a core business that's not in email, and when we're lucky, they manage to 
publish an SPF record for their customers to use. Only large volume 
sophisticated services tend to do DKIM.

A domain owner that requires everything that sends on its behalf to use DKIM 
basically shoots itself in the foot, and makes most of the services they'd need 
to use unavailable to themselves.

The correct answer is what you said: domain owners who want this should only 
authenticate services using DKIM.

Seth


On Mon, Jun 14, 2021 at 10:10 AM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
Hello,

I was talking to some folks about DMARC, and a question came as to suggest as 
the domain holder that your messages should always pass DKIM.  Effectively, the 
asker wants to say "I intend to deploy SPF and DKIM, but I will *always* sign 
my messages with DKIM."  So the obvious answer may be "Just only use DKIM", but 
I'm not sure that completely answers the question.  While discussing with 
someone else, "Tell me when DKIM fails, but SPF is fully aligned".  There was 
recently an incident at a provider where they were allowing any sender to send 
as any domain (and I'm aware that's not specifically a DMARC issue).  We all 
know brands that have just dumped in a pile of "include" statements without 
fully understanding the implications.  In this case, other users could send as 
other domains, but perhaps they would not have been DKIM signed.  Should there 
be a method by which a domain holder can say "We want all message to have both, 
or be treated as a failure", or "We'll provide both, but DKI
 M is a must"?

>From a receiver side, it makes evaluation more complex.  From a sender side, 
>it gives them more control over what is considered pass/fail.

How does this look in practice?  Maybe 
"v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
(pm=Policy Matrix)

Does this make everyone cringe, or perhaps worth a larger discussion?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

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


--
Seth Blank | VP, Product
e: s...@valimail.com<mailto:s...@valimail.com>
p: 415.273.8818
[https://hosted-packages.s3-us-west-1.amazonaws.com/Valimail+Logo.png]

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