On Mon 01/Aug/2022 21:15:36 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
You could make the argument that you "usually" find DMARC records at zone
cuts, but that's relying on convention or happenstance rather than a
standards-quality framework.
I'd agree, except that our
It appears that Alessandro Vesely said:
>> You could make the argument that you "usually" find DMARC records at zone
>> cuts, but that's relying on convention or happenstance rather than a
>> standards-quality framework.
>
>I'd agree, except that our definition of Organizational Domain as one
On Mon 01/Aug/2022 00:12:45 +0200 Murray S. Kucherawy wrote:
On Sat, Jul 30, 2022 at 4:29 AM Alessandro Vesely wrote:
On Fri 29/Jul/2022 19:44:28 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
In general, it is not possible to determine DNS zone cuts by querying
On Sun, 31 Jul 2022, Murray S. Kucherawy wrote:
You could make the argument that you "usually" find DMARC records at zone
cuts, but that's relying on convention or happenstance rather than a
standards-quality framework.
Right, we went through all of this in the failed DBOUND discussion.
If it
On Sat, Jul 30, 2022 at 4:29 AM Alessandro Vesely wrote:
> On Fri 29/Jul/2022 19:44:28 +0200 John Levine wrote:
> > It appears that Alessandro Vesely said:
> >> In general, it is not possible to determine DNS zone cuts by
> querying
> >> various subdomains. However, DMARC users
On Fri 29/Jul/2022 19:44:28 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
In general, it is not possible to determine DNS zone cuts by querying
various subdomains. However, DMARC users define DMARC records at their
Organizational Domain, so it is possible to
It appears that Alessandro Vesely said:
> In general, it is not possible to determine DNS zone cuts by querying
> various subdomains. However, DMARC users define DMARC records at their
> Organizational Domain, so it is possible to discover them based on that.
Sorry, but this is
On Thu 28/Jul/2022 20:19:36 +0200 Scott Kitterman wrote:
On July 28, 2022 3:26:45 PM UTC, Todd Herr
wrote:
On Thu, Jul 28, 2022 at 10:49 AM Murray S. Kucherawy
wrote:
A couple of tweaks to suggest, edited in-place:
On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman
wrote:
For
On July 28, 2022 9:10:06 PM UTC, Alessandro Vesely wrote:
>On Thu 28/Jul/2022 20:24:35 +0200 Scott Kitterman wrote:
>>>If this process does not determine the Organizational Domain, then
>>>the Organizational Domain is the starting domain.
>>>
>>>
>>> The last paragraph is a puzzle.
On Thu 28/Jul/2022 20:24:35 +0200 Scott Kitterman wrote:
If this process does not determine the Organizational Domain, then
the Organizational Domain is the starting domain.
The last paragraph is a puzzle. If a tree walk retrieved a DMARC record, then
there must exist a domain with a
On July 28, 2022 4:03:12 PM UTC, Alessandro Vesely wrote:
>On Thu 28/Jul/2022 13:23:45 +0200 Scott Kitterman wrote:
>> On Wednesday, July 27, 2022 4:05:27 AM EDT Alessandro Vesely wrote:
>>> On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote:
On Monday, July 25, 2022 9:59:02 AM EDT
On July 28, 2022 3:26:45 PM UTC, Todd Herr
wrote:
>On Thu, Jul 28, 2022 at 10:49 AM Murray S. Kucherawy
>wrote:
>
>> A couple of tweaks to suggest, edited in-place:
>>
>> On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman
>> wrote:
>>
>>> For Organizational Domain discovery, it will be
On Thu 28/Jul/2022 13:23:45 +0200 Scott Kitterman wrote:
On Wednesday, July 27, 2022 4:05:27 AM EDT Alessandro Vesely wrote:
On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote:
On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote:
...
Here's what's currently in Git between
On Thu, Jul 28, 2022 at 10:49 AM Murray S. Kucherawy
wrote:
> A couple of tweaks to suggest, edited in-place:
>
> On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman
> wrote:
>
>> For Organizational Domain discovery, it will be necessary to perform one
>> or
>> more DNS Tree Walks (#dns-tree-walk)
A couple of tweaks to suggest, edited in-place:
On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman
wrote:
> For Organizational Domain discovery, it will be necessary to perform one
> or
> more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are
> in
> alignment. This means that
On Wednesday, July 27, 2022 4:05:27 AM EDT Alessandro Vesely wrote:
> On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote:
> > On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote:
...
> > Here's what's currently in Git between the shortcuts and the numbered
> > steps
> >
> >
On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote:
On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote:
On Sun 24/Jul/2022 22:04:07 +0200 Scott Kitterman wrote:
On July 24, 2022 9:58:46 AM UTC, Alessandro Vesely wrote:
On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote:
As
On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote:
> On Sun 24/Jul/2022 22:04:07 +0200 Scott Kitterman wrote:
> > On July 24, 2022 9:58:46 AM UTC, Alessandro Vesely wrote:
> >> On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote:
> >>> As I would hope everyone in this discussion
On Sun 24/Jul/2022 22:04:07 +0200 Scott Kitterman wrote:
On July 24, 2022 9:58:46 AM UTC, Alessandro Vesely wrote:
On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote:
As I would hope everyone in this discussion would be aware, the "as if"
rule applies to all IETF standards. You can do
On July 24, 2022 9:58:46 AM UTC, Alessandro Vesely wrote:
>John,
>
>On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote:
>> As I would hope everyone in this discussion would be aware, the "as if"
>> rule applies to all IETF standards. You can do whatever you want so long
>> as the result is
Ale's point is part of a larger inefficiency. As information is gathered,
the candidate names can be reviewed for a match. If a match is obtained,
the result is PASS and the algorithm exits. If not, then candidate names
which can be ruled out are discarded. If this makes the candidate list
John,
On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote:
As I would hope everyone in this discussion would be aware, the "as if"
rule applies to all IETF standards. You can do whatever you want so long
as the result is the same as if you had done what the spec says.
The "as if" rule also
As I would hope everyone in this discussion would be aware, the "as if"
rule applies to all IETF standards. You can do whatever you want so long
as the result is the same as if you had done what the spec says.
In this case, the speedup from your change is unlikely to make any
speed difference
Hi,
the need to actually determine the organizational domain is a
misconception. For alignment, it is sufficient to determine that the
organizational domain of two identifier is the same. There is no need
to actually walk up there.
For example, let's reconsider the basic example with an
24 matches
Mail list logo
