Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not

[John Levine]

In article  you write:
>3.3.  Transport
>
>Email streams carrying DMARC failure reports MUST conform to the
>DMARC mechanism, thereby resulting in an aligned "pass".  Special
>care must be taken of authentication, as failure to authenticate
>failure reports may provoke further reports.

Reporters SHOULD rate limit the number of failure reports sent
to any recipient to avoid overloading recipient systems.


Why would reports due to a mail loop be more of a problem than due to
some random spammer sending a lot of fake mail, or (real life) your
users send mail to mailing lists with thousands of subscribers? Rate
limit your reports, don't worry about where they came from.

R's,
John

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

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Dave Crocker]

On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker > wrote:




Abstract

DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling.  The design of DMARC
presumes that domain names represent either nodes in the tree below
which registrations occur, or nodes where registrations have

DMARC does not have 'registrations'.


It's referring to domain name registrations, not DMARC registrations.

Also the occur/occured contrast has no obvious meaning to me. 
Really, I have no idea what's intended by it.

"exist"?
"take place"?
"are made"?
"are done"?


The issue wasn't synonyms but semantics.  'registrations occurred' has 
no obvious DMARC meaning.


unless, perhaps, the meaning is 'domain names exist', but that still 
doesn't explain the contrast being drawn.






occurred; it does not permit a domain name to have both of these

"both" of what?  registration?


It's describing properties of nodes in the domain name tree. DMARC's 
current design stipulates that every node is either (a) a node below 
which registrations can occur, or (b) a node at which a registration 
has occurred.  An example of the former is "org", and an example of 
the latter is "ietf.org " and its entire subtree.


DMARC does not have 'registrations'.

The word in used in the spec as:

"


   3 . Terminology and
   Definitions

Domain Owner:  An entity or organization that owns a DNS domain.  The
  term "owns" here indicates that the entity or organization being
  referenced holds the registration of that DNS domain."


and:


"


 3.2 .
 Organizational Domain



   The Organizational Domain is determined using the following
   algorithm:

   1.  Acquire a "public suffix" list, i.e., a list of DNS domain names
   reserved for registrations. "

(The later reference to the Tag Registry is presumably irrelevant here.)





properties simultaneously.  Since its deployment in 2015, use of
DMARC has shown a clear need for the ability to express policy for
these domains as well.

Which domains?


The intent is to augment DMARC's ability to describe the domain name 
tree such that a node can be both (a) and (b) at the same time, for 
the purposes of policy expression.  So those are the nodes (domains) 
of interest.



My frustration is that a document that reaches wg Last Call should not 
have language that is this confusing, especially about its fundamentals 
and especially given how much revision it has already gotten.




d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Murray S. Kucherawy]

On Fri, Jan 29, 2021 at 3:02 AM Alessandro Vesely  wrote:

> I just run a quick test on my current folder.  Out of 3879 messages I
> extracted
> 944 unique helo names.  721 of these matched the reverse lookup exactly.
> Out
> of the 223 remaining, 127 had an SPF pass for the helo identity anyway.
> So in
> 96 cases, roughly 10%, the helo name was indeed junk.  Isn't the remaining
> ~90%
> something worth considering?
>

I am admittedly quite heavily biased against using the HELO/EHLO value for
anything.  I have simply never found value in it, probably because at the
SMTP layer it's simply a value that gets logged or used in cute ways in the
human-readable portion of SMTP.  I seem to recall (but cannot seem to find
at the moment) RFC 5321 saying you can't reject HELO/EHLO based on a bogus
value, so it's even explicitly not useful to me.

Even if it's not junk, there's pretty much always something else on which
to hang a pass/fail decision about the apparent authenticity of a message
that at least feels safer if not actually being more sound.  Or put another
way, if you present to me a DKIM-signed message with a MAIL FROM value and
the only thing that passes is an SPF check against HELO, I'm mighty
skeptical.

Anyway, I'll let consensus fall where it may.

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

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Murray S. Kucherawy]

On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker  wrote:

>
> Abstract
>
>DMARC (Domain-based Message Authentication, Reporting, and
>Conformance) is a scalable mechanism by which a mail-originating
>organization can express domain-level policies and preferences for
>message validation, disposition, and reporting, that a mail-receiving
>organization can use to improve mail handling.  The design of DMARC
>presumes that domain names represent either nodes in the tree below
>which registrations occur, or nodes where registrations have
>
> DMARC does not have 'registrations'.
>

It's referring to domain name registrations, not DMARC registrations.

Also the occur/occured contrast has no obvious meaning to me.  Really, I
> have no idea what's intended by it.
>
"exist"?
"take place"?
"are made"?
"are done"?

>
>occurred; it does not permit a domain name to have both of these
>
> "both" of what?  registration?
>

It's describing properties of nodes in the domain name tree.  DMARC's
current design stipulates that every node is either (a) a node below which
registrations can occur, or (b) a node at which a registration has
occurred.  An example of the former is "org", and an example of the latter
is "ietf.org" and its entire subtree.

   properties simultaneously.  Since its deployment in 2015, use of
>DMARC has shown a clear need for the ability to express policy for
>these domains as well.
>
> Which domains?
>

The intent is to augment DMARC's ability to describe the domain name tree
such that a node can be both (a) and (b) at the same time, for the purposes
of policy expression.  So those are the nodes (domains) of interest.


>Domains at which registrations can occur are referred to as Public
>Suffix Domains (PSDs).  This document describes an extension to DMARC
>to enable DMARC functionality for PSDs.
>
> This is the definition of public suffix provided by the PSL folk:
>
> "A public suffix is a set of DNS names or wildcards concatenated with
> dots. It represents the part of a domain name which is *not* under the
> control of the individual registrant."
>

That seems to say the same thing to me, though perhaps more crisply.

>
>This document also seeks to address implementations that consider a
>domain on a public Suffix list to be ineligible for DMARC
>enforcement.
>
> seeks?
> [...]
>

Hmm.  Maybe that sentence can be struck entirely.  Is this a problem with
certain implementations only, or with DMARC as specified in 7489?  If the
latter, I think we can drop this because the main paragraph already says
this.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Murray S. Kucherawy]

On Fri, Jan 29, 2021 at 8:21 AM Kurt Andersen (b)  wrote:

> On Fri, Jan 29, 2021 at 6:52 AM Tim Wicinski  wrote:
>
>>
>> I suggest adding it to this paragraph:
>>
>>This document specifies experimental updates to the DMARC and PSL
>>algorithm cited above, in an attempt to mitigate this abuse.
>>
>
> update to DMARC = yes; update to PSL = no
>

Why?


>
>> On Fri, Jan 29, 2021 at 1:44 AM Murray S. Kucherawy 
>> wrote:
>>
>>> On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski  wrote:
>>>
 Since this is an experiment, Appendix A discusses the updates that
 happen.  we don't actually say explicitly "if the experiment is a success,
 the following changes will be made" and perhaps I should add some wording
 like that.

>>>
>>> Something like this, perhaps?
>>>
>>> "A standards track update to [RFC7489] will take into account the
>>> results of this experiment."
>>>
>>> ... somewhere in Section 1.
>>>
>>
> A normative dependency from an experimental spec imposed upon a standards
> track spec seems like a bad idea to me. At the very least it would impose a
> timing constraint that DMARCbis could not be "completed" until after the
> PSD experiment is "completed", analyzed and consensus achieved.
>

I thought that was exactly the intent here.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Alessandro Vesely]

On Fri 29/Jan/2021 19:11:56 +0100 I wrote:


I attach a patch.



P.S.  It also changed the example slightly.  It sounds wrong as is now.  Pls 
look at that...



Best
Ale
--

















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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Alessandro Vesely]

On Fri 29/Jan/2021 17:21:19 +0100 Kurt Andersen (b) wrote:

On Fri, Jan 29, 2021 at 6:52 AM Tim Wicinski  wrote:



I suggest adding it to this paragraph:


   This document specifies experimental updates to the DMARC and PSL
   algorithm cited above, in an attempt to mitigate this abuse.




update to DMARC = yes; update to PSL = no



It is difficult to propose changes in OLD:/NEW: format.  I attach a patch.  It 
defers mentioning a PSL until Section 3.  That way it may address part of 
Dave's objections as well.




On Fri, Jan 29, 2021 at 1:44 AM Murray S. Kucherawy 
wrote:


On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski  wrote:


Since this is an experiment, Appendix A discusses the updates that
happen.  we don't actually say explicitly "if the experiment is a success,
the following changes will be made" and perhaps I should add some wording
like that.



Something like this, perhaps?

"A standards track update to [RFC7489] will take into account the results
of this experiment."

... somewhere in Section 1.




A normative dependency from an experimental spec imposed upon a standards
track spec seems like a bad idea to me. At the very least it would impose a
timing constraint that DMARCbis could not be "completed" until after the
PSD experiment is "completed", analyzed and consensus achieved.



This could be weakened by saying "*may* take into account".  However, it's not 
needed, as the sentence doesn't say *the next* standards track update...



Best
Ale
--

--- draft-ietf-dmarc-psd-tim.xml2021-01-24 18:50:28.355829817 +0100
+++ draft-ietf-dmarc-psd-ale.xml2021-01-29 18:58:35.349494946 +0100
@@ -42,14 +42,14 @@
TLD
 

-  DMARC (Domain-based Message Authentication, Reporting, and
- Conformance) is a scalable mechanism by which a mail-originating
+  Domain-based Message Authentication, Reporting, and
+ Conformance (DMARC) is a scalable mechanism by which a 
mail-originating
  organization can express domain-level policies and preferences for
  message validation, disposition, and reporting, that a mail-receiving
- organization can use to improve mail handling.  The design of DMARC
- presumes that domain names represent either nodes in the tree below
- which registrations occur, or nodes where registrations have occurred;
- it does not permit a domain name to have both of these properties
+ organization can use to improve mail handling.
+   Internet domain names can be represented by a tree.  There are nodes 
below
+ which registrations occur, and nodes where registrations have 
occurred.
+ DMARC does not permit a domain name to have both of these properties
  simultaneously.  Since its deployment in 2015, use of DMARC has shown
  a clear need for the ability to express policy for these domains as
  well.
@@ -57,7 +57,7 @@
  Suffix Domains (PSDs).  This document describes an extension to DMARC
  to enable DMARC functionality for PSDs.
   This document also seeks to address implementations that consider a
- domain on a public Suffix list to be ineligible for DMARC
+ Public Suffix Domain to be ineligible for DMARC
  enforcement.

  
@@ -68,42 +68,47 @@
 organizational policy information to email receivers.  DMARC allows 
policy to be
 specified for both individual domains and for organizational domains
 and their sub-domains within a single organization.
- To determine the organizational domain for a message under evaluation,
-and thus where to look for a policy statement, DMARC makes use of a 
Public Suffix
-List. The process for doing this can be found in Section 3.2 of the 
DMARC
-specification.
- DMARC as specified presumes that domain names present in a PSL are not
+ Representing Internet domain names in a tree, Public Suffix Domains 
(PSD)
+are those right below or near to the top of the tree, which is the 
root.
+DMARC allows Organizational Domains, which are those right below a PSD,
+to publish a policy.  Subdomains can publish their policy too,
+overriding the policy of their Organizational Domain.  However,
+PSD currently cannot.  In other words,
+DMARC as specified presumes that PSDs are not
 organizational domains and thus not subject to DMARC processing; 
domains
 are either organizational domains, sub-domains of organizational
-domains, or listed on a PSL.  For domains listed in a
-PSL, i.e., TLDs and domains that exist between TLDs and
+domains, or PSDs.  For a
+PSD, i.e., TLDs and domains that exist between TLDs and
 organization level domains, policy can only be published for the
 exact domain.  No method is available for these domains to express
 policy or receive feedback reporting for sub-domains.  This missing
   

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Kurt Andersen (b)]

On Fri, Jan 29, 2021 at 6:52 AM Tim Wicinski  wrote:

>
> I suggest adding it to this paragraph:
>
>This document specifies experimental updates to the DMARC and PSL
>algorithm cited above, in an attempt to mitigate this abuse.
>

update to DMARC = yes; update to PSL = no


> On Fri, Jan 29, 2021 at 1:44 AM Murray S. Kucherawy 
> wrote:
>
>> On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski  wrote:
>>
>>> Since this is an experiment, Appendix A discusses the updates that
>>> happen.  we don't actually say explicitly "if the experiment is a success,
>>> the following changes will be made" and perhaps I should add some wording
>>> like that.
>>>
>>
>> Something like this, perhaps?
>>
>> "A standards track update to [RFC7489] will take into account the results
>> of this experiment."
>>
>> ... somewhere in Section 1.
>>
>
A normative dependency from an experimental spec imposed upon a standards
track spec seems like a bad idea to me. At the very least it would impose a
timing constraint that DMARCbis could not be "completed" until after the
PSD experiment is "completed", analyzed and consensus achieved.

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

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Dave Crocker]

On 1/29/2021 6:59 AM, Tim Wicinski wrote:
This starts a *one week* Working Group Last Call. 



Sorry, but even the Abstract appears to be littered with problematic 
language.


I always try to provide alternate language, when I can, but in spite of 
having offered suggestions for this document in the past, I can't for 
this set.




Abstract

DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling.  The design of DMARC
presumes that domain names represent either nodes in the tree below
which registrations occur, or nodes where registrations have

DMARC does not have 'registrations'.

Also the occur/occured contrast has no obvious meaning to me. Really, I 
have no idea what's intended by it.




occurred; it does not permit a domain name to have both of these

"both" of what?  registration?



properties simultaneously.  Since its deployment in 2015, use of
DMARC has shown a clear need for the ability to express policy for
these domains as well.

Which domains?



Domains at which registrations can occur are referred to as Public
Suffix Domains (PSDs).  This document describes an extension to DMARC
to enable DMARC functionality for PSDs.

This is the definition of public suffix provided by the PSL folk:

"A public suffix is a set of DNS names or wildcards concatenated with 
dots. It represents the part of a domain name which is *not* under the 
control of the individual registrant."




This document also seeks to address implementations that consider a
domain on a public Suffix list to be ineligible for DMARC
enforcement.

seeks?

implementations don't 'consider' anything.

is 'ineligibility' really the essential issue?

d/


--

Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

[dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Tim Wicinski]

All

We've done a number of updates to the PSD document to reflect the GEN-ART
review,
mostly to expand on the experiments.  There has been enough changes that we
want to do a short
working group last call.

https://tools.ietf.org/html/draft-ietf-dmarc-psd-10

To look at the differences, I would suggest looking at this diff from the
-08 version and the current version:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08=draft-ietf-dmarc-psd-10

This starts a *one week* Working Group Last Call.  Please review the
changes and offer up comments.
Offering suggestive text would be really useful as well.

This WGLC will end 5 February 2021

tim


-- Forwarded message -
From: 
Date: Sat, Jan 23, 2021 at 6:26 PM
Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-10.txt
To: 
Cc: 



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain-based Message Authentication,
Reporting & Conformance WG of the IETF.

Title   : Experimental DMARC Extension For Public Suffix
Domains
Author  : Scott Kitterman
Filename: draft-ietf-dmarc-psd-10.txt
Pages   : 14
Date: 2021-01-23

Abstract:
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

   Domains at which registrations can occur are referred to as Public
   Suffix Domains (PSDs).  This document describes an extension to DMARC
   to enable DMARC functionality for PSDs.

   This document also seeks to address implementations that consider a
   domain on a public Suffix list to be ineligible for DMARC
   enforcement.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-psd-10
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Tim Wicinski]

I suggest adding it to this paragraph:

   This document specifies experimental updates to the DMARC and PSL
   algorithm cited above, in an attempt to mitigate this abuse.



On Fri, Jan 29, 2021 at 1:44 AM Murray S. Kucherawy 
wrote:

> On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski  wrote:
>
>> Since this is an experiment, Appendix A discusses the updates that
>> happen.  we don't actually say explicitly "if the experiment is a success,
>> the following changes will be made" and perhaps I should add some wording
>> like that.
>>
>
> Something like this, perhaps?
>
> "A standards track update to [RFC7489] will take into account the results
> of this experiment."
>
> ... somewhere in Section 1.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Alessandro Vesely]

On Thu 28/Jan/2021 21:40:49 +0100 Murray S. Kucherawy wrote:

On Thu, Jan 28, 2021 at 4:13 AM Alessandro Vesely  wrote:

DKIM (in its simplest form) returns N tuples of the form (d= domain, 
pass/fail).  All of them were run through exactly the same check; all

of them were attached to the message in exactly the same way; all of
them have essentially identical semantics.  Giving them equal footing
makes sense to me. >>>
The two identifiers in SPF hold different places in the SMTP session,
and have different semantics.  I think treating them differently is also
just fine. >>
It is relevant that both identifier come from /the same/ SMTP session. 
That's not true for many DKIM signatures. >

I guess if report consumers really want this information, we can include
it.



Helo is essential if mfrom is missing.  A second SPF identifier is optional 
anyway.



I just don't see the value in the HELO parameter if it's effectively
random junk in the session.



Where does that notion come from?  Most mail admins choose the helo name 
carefully, possibly so that it resolves both ways to the IP number.


I just run a quick test on my current folder.  Out of 3879 messages I extracted 
944 unique helo names.  721 of these matched the reverse lookup exactly.  Out 
of the 223 remaining, 127 had an SPF pass for the helo identity anyway.  So in 
96 cases, roughly 10%, the helo name was indeed junk.  Isn't the remaining ~90% 
something worth considering?




At least a passing DKIM signature is associated with a domain that existed
at some point in time and whose DNS contained apparently-valid public keys.


Why cannot one type DKIM-Signature: d=anyrandomjunk ...?



I can mostly type anything I want to HELO or EHLO.



That's true for any identifier.  We know an identifier is associated with a 
domain that existed at some point in time only after it's been authenticated.


One may say DKIM authentication is somewhat more precise, because the vogue is 
to include whole classes of IPs in SPF records.  But then, such lack of 
accuracy affects mfrom and helo alike.


The real difference between helo and mfrom is that the former is a 
configuration parameter of the sending relay, while the latter is set by the 
submission client.  The former is akin to d= and s=, while the latter is akin 
to From:.  No rationale to discard either, AFAICS.



Best
Ale
--















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