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 : Domain-based Message Authentication, Reporting, and
Conformance (DMARC) Failur
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 : Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
It appears that these tickets are all related to this issue:
#24 objection to maintaining registry for all participating public
suffixes
#34 Define the term "Public Suffix" referencing RFC8499
#46 Separate org domain definition from core DMARC
#58 Add third l
This use case is actually the intention of (the extremely poorly worded)
https://trac.ietf.org/trac/dmarc/ticket/59
To the earlier conversation, this is all simplified dramatically if we
define organizational domain (or whatever it's renamed) discovery in a
separate I-D that DMARC just inherits...
On Wed, 11 Nov 2020, Dave Crocker wrote:
Just to invoke a bit of ancient history, here, you are saying that if there
was the domain name:
engineering.sun.com
people would be surprised that the organization domain is
oracle.com
In a DMARC context, that would be quite surprising. I am aw
On 11/11/2020 11:24 AM, John R Levine wrote:
DMARC has had a consistent construct, which is 'the domain name that
is at the top of the organization's administrative hierarchy". Hence,
Organizational Domain. Nothing in the term requires that it be up the
'current' domain name chain.
I think
"Parent default" or something like that. There's no claim that it is
or isn't in the same organization, just that it's a parent name of the
target name.
For Scott's _dmarc.BANK. thing it would deliberately*not* be the same
organization.
Where is such generality discussed in DMARC? I don't re
On 11/11/2020 8:50 AM, John R Levine wrote:
The current text says (in many more words), take a list of public
suffixes,
...
If you mean that we would punt a potential change this large into a
different document, that seems like a stretch.
It's not.
The entire topic is a mess. In pretty
The ticket in question is https://trac.ietf.org/trac/dmarc/ticket/68
(as an individual)
If we go the tree walk route, I believe the realistic hack needed will
simply be to add a max depth for the walk. The longest PSL suffix is only 4
labels deep, so a max depth of 10 seems generous without openi
I believe the core of this is referenced in
https://trac.ietf.org/trac/dmarc/ticket/68 and can be discussed in detail
when the chairs or relevant editors open that ticket.
The further discussion seems to be if "org domain" (or whatever new name
its given) definition and discovery mechanism should
I was trying to address the tree walk objections and denial-of-service
objections by starting at the upper end of the tree, so that an evaluator
cannot be tricked into trying 100 possibilities for a single email message.
An additional protection would be to specify a few TLDs, (particularly .
On 11/11/2020 10:18 AM, John Levine wrote:
"Parent default" or something like that. There's no claim that it is
or isn't in the same organization, just that it's a parent name of the
target name.
For Scott's _dmarc.BANK. thing it would deliberately*not* be the same
organization.
Where is su
In article <03758d8d-a4d7-3f9d-bc0c-3ee404fc5...@dcrocker.net> you write:
>On 11/11/2020 8:58 AM, John R Levine wrote:
>> Except that if we do a tree walk, I don't think we'd call that the
>> Organizational Domain any more.
>
>What would you call it?
"Parent default" or something like that. There
On 11/11/2020 8:58 AM, John R Levine wrote:
Except that if we do a tree walk, I don't think we'd call that the
Organizational Domain any more.
What would you call it?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
d
On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote:
The proposal is, I think, to change the main document to leave a
pointer, and the pointer can be changed much more easily than the actual
method. So the new DMARC document would say: "Determine the
Organizational Domain. The legacy way to do t
On Wed, Nov 11, 2020 at 6:01 AM Douglas E. Foster wrote:
> Can we eliminate the PSL problem simply by adding some DNS queries?
>
> Isn't there a maximum depth to the PSL, so that the evaluator can simply
> walk up the top N levels of the domain tree to find either an
> organizational DMARC entry
On Wed, Nov 11, 2020 at 8:52 AM John R Levine wrote:
> The current text says (in many more words), take a list of public
> suffixes, find the longest match, and the Org domain is one below that
> match. If we consider the Org domain to be found via a list of public
> registration points, that wo
On Wed, 11 Nov 2020, Dave Crocker wrote:
So, DMARC should punt the entire topic. It should have some text, along the
lines of:
Find the Organizational Domain. The means of finding the Organizational
Domain are outside the scope of this specification.
Except that if we do a tree walk, I d
On 11/11/2020 8:50 AM, John R Levine wrote:
The current text says (in many more words), take a list of public
suffixes,
...
If you mean that we would punt a potential change this large into a
different document, that seems like a stretch.
It's not.
The entire topic is a mess. In pretty
On Wed, 11 Nov 2020, Dave Crocker wrote:
There is a difference between "splitting out existing text, on topic x" from
"revise text on topic x".
The current suggestion is to take the org domain text that is current in the
DMARC spec and to split it out, so that the core DMARC spec does not cont
Can we eliminate the PSL problem simply by adding some DNS queries?
Isn't there a maximum depth to the PSL, so that the evaluator can simply walk
up the top N levels of the domain tree to find either an organizational DMARC
entry with sp= or a PSD DMARC entry with sp=? It looks like currently,
On 11/10/2020 6:24 PM, John Levine wrote:
In article
you write:
This actually makes sense because there are other potential documents/uses
besides DMARC that could reference PSL-type mechanisms.
Remember that this is a well-known swamp of despair. We had a whole
DBOUND working group that fai
22 matches
Mail list logo
