Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[Murray S. Kucherawy]

On Tue, Dec 21, 2021 at 11:32 AM John Levine  wrote:

> The DNS has had a formal definition of non-existence for over 30
> years. You look up a name, if it returns records or NOERROR it exists,
> if it returns NXDOMAIN it doesn't. There is no reason for us to invent
> something new and incompatible.
>
> >I don't remember exactly why we settled on A/ / MX, but the lack of a
> clear, actionable definition is why we included one.
>
> See above.  I don't remember where the text in A.4 came from, but it is
> wrong.
> If we are telling people to test whether a domain exists, they should do it
> the way the DNS does it.  The correct test happens to be cheaper than A.4,
> one query rather than three.
>

We're talking about two different things here, I think.  The DNS definition
of "nonexistent" is as cited above while the DMARC definition matches the
well established SMTP algorithm that figures out where the next hop for a
particular recipient is.  If there is no next hop, then for email purposes,
the domain doesn't "exist".  The logic goes something like: If this message
fails DMARC, and a bounce has nowhere to go, then I'm pretty sure I don't
want to deliver it.

We're free to change our minds about what test is appropriate here, but
that was the genesis of A.4.

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

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[Murray S. Kucherawy]

On Tue, Dec 21, 2021 at 4:31 AM Scott Kitterman 
wrote:

> I don't remember exactly why we settled on A/ / MX, but the lack of a
> clear, actionable definition is why we included one. Lack of DNS records
> related to email authentication only means lack of email authentication,
> which is in no way required.  Given the way most systems are typically
> architected, by the time you are doing email authentication, A or  and
> MX will already be in the local cache, so this is a pretty inexpensive
> thing to check.
>

It comes from SMTP itself.  RFC 5321 and its antecedent(s) specify that to
identify the next hop for a message needing routing, you look up the MX for
the recipient's domain.  If that's missing, you try the A/ for that
same name.  If that's also missing, the message is undeliverable.

Since that test has worked well for SMTP for rather a long time, DMARC
adopted it.

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

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[Dave Crocker]

On 12/18/2021 10:17 AM, Phillip Hallam-Baker wrote:
Mailing lists are not well supported by SMTP and never will be. Any 
discussion of how to make mailing lists work better has to begin with 
the acceptance that they will never work very well which is what most 
people have been arguing in this thread.


SMTP is a transfer protocol.  It does not know about mailing lists and 
doesn't need to.  (There is text in the SMTP spec about mailing lists, 
but really the text has nothing to do with SMTP, per se, and not a lot 
to do with the operation of mailing lists.


Mailing lists are user-level processes that sit at a layer above SMTP.


Rather than seeing mailing lists as they work today as the pinnacle of 
evolution, we should see them for what they are, a rather disgusting 
hack that we never got round to fixing.


Can't say I've ever noticed anyone suggesting that mailing lists are the 
pinnacle of anything.  On the other hand, efforts to produce more 
interesting capabilities that aren't centralized have not gotten much 
traction.  One keeps hoping, but field experience is not encouraging.





Why is it assumed that the input to a mailing list is an SMTP email? 
That seems to me to be a rather narrow assumption.


Not everyone makes that assumption.

That said, where is the spec for the alternative and who supports that spec?


Once we recognize that the inputs and outputs from 'mailing lists' can 
be through other transports than SMTP, all arguments about preserving 
'original' headers collapse. This is not an interaction between an 
SMTP sender and receiver, the mailing list itself is a principal.


When playing in the sandbox of a particular set of specifications, then 
it's fine -- actually it's essential -- to specify requirements such as 
information preservation.


If the point is that mail can transit heterogeneous environments, with 
different semantics, then the fact of that difference ensures 
information loss.  Absent that assurance, why shouldn't the information 
be preserved, no matter how it is transported?  That is, after all, one 
of the benefits of distinguish the message object specification from the 
message transport specification.


Apologies. I've probably entirely missed your point.


d/

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

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[Scott Kitterman]

On Tuesday, December 21, 2021 2:32:12 PM EST John Levine wrote:
> It appears that Scott Kitterman   said:
> >>> What definition are you wondering why we didn't stick to?
> >>
> >>Real non-existence.  I'm not sure how to define it formally, ...
> 
> The DNS has had a formal definition of non-existence for over 30
> years. You look up a name, if it returns records or NOERROR it exists,
> if it returns NXDOMAIN it doesn't. There is no reason for us to invent
> something new and incompatible.
> 
> >I don't remember exactly why we settled on A/ / MX, but the lack of a
> >clear, actionable definition is why we included one.
> See above.  I don't remember where the text in A.4 came from, but it is
> wrong. If we are telling people to test whether a domain exists, they
> should do it the way the DNS does it.  The correct test happens to be
> cheaper than A.4, one query rather than three.

Fair enough.  I can't remember why we thought RFC 8020[1] wasn't adequate when 
we did RFC 9091.  I think we should modify the DMARC text to just refer to it.

Scott K

[1] https://www.rfc-editor.org/rfc/rfc8020.txt


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

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[John Levine]

It appears that Scott Kitterman   said:
>>> What definition are you wondering why we didn't stick to?
>>
>>Real non-existence.  I'm not sure how to define it formally, ...

The DNS has had a formal definition of non-existence for over 30
years. You look up a name, if it returns records or NOERROR it exists,
if it returns NXDOMAIN it doesn't. There is no reason for us to invent
something new and incompatible.

>I don't remember exactly why we settled on A/ / MX, but the lack of a 
>clear, actionable definition is why we included one.

See above.  I don't remember where the text in A.4 came from, but it is wrong.
If we are telling people to test whether a domain exists, they should do it
the way the DNS does it.  The correct test happens to be cheaper than A.4,
one query rather than three.

R's,
John

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

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[John R Levine]

If you prefix _domainkey to those names and do a lookup, several of them
return NOERROR which suggests they have DKIM keys.


Hm...  one of them returns NXDOMAIN even though there is a DMARC record 
below.


ale@pcale:~/tmp$ dig mail.foodnetwork.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64715


Sigh.  That's just wrong.  I'll see if I can find someone who can fix it.

R's,
John

PS: pretty please can we not even think about changing the spec to work 
around other people's bugs


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

[dmarc-ietf] [Technical Errata Reported] RFC8601 (6790)

[RFC Errata System]

The following errata report has been submitted for RFC8601,
"Message Header Field for Indicating Message Authentication Status".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6790

--
Type: Technical
Reported by: Scott Kitterman 

Section: 8

Original Text
-
   [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
  "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
  RFC 6376, DOI 10.17487/RFC6376, September 2011,
  .

Corrected Text
--
   [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
  "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
  RFC 6376, DOI 10.17487/RFC6376, September 2011,
  .

Notes
-
In the next revision, this reference should be moved from Section 8.2, 
informative references, to Section 8.1, normative references.  In Section 2.2, 
formal definition, the definition for domain-name is taken from RFC 6376, so 
it's not merely informative.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8601 (draft-ietf-dmarc-rfc7601bis-06)
--
Title   : Message Header Field for Indicating Message 
Authentication Status
Publication Date: May 2019
Author(s)   : M. Kucherawy
Category: PROPOSED STANDARD
Source  : Domain-based Message Authentication, Reporting & 
Conformance
Area: Applications and Real-Time
Stream  : IETF
Verifying Party : IESG

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

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[Scott Kitterman]

On December 21, 2021 12:05:35 PM UTC, Alessandro Vesely  wrote:
>On Mon 20/Dec/2021 18:41:25 +0100 Scott Kitterman wrote:
>> On Monday, December 20, 2021 12:39:15 PM EST Alessandro Vesely wrote:
>>> On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote:
>>> > If the domain owner has suggested that you reject mail from a sub-domain
>>> > that has none of A, , or MX records, why would you not do that?
>>> Are we sure that's what the domain owner meant to suggest?
>>> 
>>> An organization can use sp= on its root domain record, or it can define a
>>> DMARC record at some subdomains.  So far so good.
>>> 
>>> Then it turns out that one can also define DMARC record at some non-existing
>>> sub domains, possibly as an alternative to using np=...  Now this begins to
>>> look puzzling.
>>> 
>>> The reason to introduce np= was to select domains that really don't exist. 
>>> Why don't we stick to that definition?
>> 
>> What definition are you wondering why we didn't stick to?
>
>
>Real non-existence.  I'm not sure how to define it formally, because it would 
>be exorbitant to require to try everything.  On the other hand an application 
>probably tried to authenticate SPF, DKIM, and DMARC already.  If any of those 
>record was found, then it's silly to even lookup A/ / MX for the purpose 
>to 
>determine if the domain exists.

I don't remember exactly why we settled on A/ / MX, but the lack of a 
clear, actionable definition is why we included one. Lack of DNS records 
related to email authentication only means lack of email authentication, which 
is in no way required.  Given the way most systems are typically architected, 
by the time you are doing email authentication, A or  and MX will already 
be in the local cache, so this is a pretty inexpensive thing to check.

Scott K

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

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[Alessandro Vesely]

On Mon 20/Dec/2021 20:59:45 +0100 John Levine wrote:

It appears that Alessandro Vesely   said:

On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote:
I am not doing any root domain lookups.   If that is part of the proposed 
algorithm, somebody needs to document it.  I am simply looking for a resource 
record matching the FROM domain name.



Oops, yes, you're right.  Dunno why I looked up their org domain, probably lack 
of caffeine...


Those 10 domains are non-existing under 3.2.6.  Only 4 of them return NXDOMAIN.


If you prefix _domainkey to those names and do a lookup, several of them
return NOERROR which suggests they have DKIM keys.



Hm...  one of them returns NXDOMAIN even though there is a DMARC record below.

ale@pcale:~/tmp$ dig mail.foodnetwork.com

; <<>> DiG 9.16.15-Debian <<>> mail.foodnetwork.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64715
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d56c07ed27e795d3010061c1bc09cea5581e05ff08ab (good)
;; QUESTION SECTION:
;mail.foodnetwork.com.  IN  A

;; AUTHORITY SECTION:
foodnetwork.com.875 IN  SOA ns-298.awsdns-37.com. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400


ale@pcale:~/tmp$ dig _dmarc.mail.foodnetwork.com txt

; <<>> DiG 9.16.15-Debian <<>> _dmarc.mail.foodnetwork.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32999
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 00298aa760a08142010061c1bc0e9fc192e7b9269cf7 (good)
;; QUESTION SECTION:
;_dmarc.mail.foodnetwork.com.   IN  TXT

;; ANSWER SECTION:
_dmarc.mail.foodnetwork.com. 300 IN TXT "v=DMARC1; p=reject; fo=1; ri=3600; 
rua=mailto:discov...@rua.agari.com; ruf=mailto:discov...@ruf.agari.com;




For the umpteenth time, there is a DNS definition of non-existent which is the 
only
one you get to use in the IETF.



The definition in Section 3.2.6 is different.



Can we stop wasting time with this fruitless argument, please?


Yes.

Best
Ale
--







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

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[Alessandro Vesely]

On Mon 20/Dec/2021 18:41:25 +0100 Scott Kitterman wrote:

On Monday, December 20, 2021 12:39:15 PM EST Alessandro Vesely wrote:

On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote:
> If the domain owner has suggested that you reject mail from a sub-domain
> that has none of A, , or MX records, why would you not do that?
Are we sure that's what the domain owner meant to suggest?

An organization can use sp= on its root domain record, or it can define a
DMARC record at some subdomains.  So far so good.

Then it turns out that one can also define DMARC record at some non-existing
sub domains, possibly as an alternative to using np=...  Now this begins to
look puzzling.

The reason to introduce np= was to select domains that really don't exist. 
Why don't we stick to that definition?


What definition are you wondering why we didn't stick to?



Real non-existence.  I'm not sure how to define it formally, because it would 
be exorbitant to require to try everything.  On the other hand an application 
probably tried to authenticate SPF, DKIM, and DMARC already.  If any of those 
record was found, then it's silly to even lookup A/ / MX for the purpose to 
determine if the domain exists.



Best
Ale
--





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