On Wed, 26 Jan 2022, Murray S. Kucherawy wrote:
On Wed, Jan 26, 2022 at 9:56 AM John Levine wrote:
More saliently, we had an entire working group called DBOUND that tried
and failed to come up with a way to publish boundary info about the DNS:
https://datatracker.ietf.org/wg/dbound/about/
On Wed, Jan 26, 2022 at 9:56 AM John Levine wrote:
> More saliently, we had an entire working group called DBOUND that tried
> and failed
> to come up with a way to publish boundary info about the DNS:
>
> https://datatracker.ietf.org/wg/dbound/about/
>
DBOUND came up with two ways to deal with
It appears that Steve Siirila said:
>-=-=-=-=-=-
>
>After reading this thread, I couldn't help but wonder about how the
>addition of a "PSD flag" specifically targeted to DMARC might be repurposed
>for other non-DMARC applications since my understanding is that the PSL is
>currently being used
On Wednesday, January 26, 2022 10:27:04 AM EST Steve Siirila wrote:
> After reading this thread, I couldn't help but wonder about how the
> addition of a "PSD flag" specifically targeted to DMARC might be repurposed
> for other non-DMARC applications since my understanding is that the PSL is
>
After reading this thread, I couldn't help but wonder about how the
addition of a "PSD flag" specifically targeted to DMARC might be repurposed
for other non-DMARC applications since my understanding is that the PSL is
currently being used for other purposes as well. Just food for thought.
On Tue, Jan 25, 2022 at 3:31 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Overall, I doubt that we can replace the PSL without moving to DMARCv2,
> and I don't think we have a standards-worthy document unless the PSL is
> replaced.
>
I don't think such an opinion is going to
>
>
> DMARC for PSD is based on the rule that the PSD is one segment above the
> organization domain, and the organization domain is assumed to be known
> with confidence from the PSL.
> When we switch directions, we cannot as easily assume that the
> organization domain is one segment below
It appears that Alessandro Vesely said:
>As John said, the gap is that PSD domains are not going to publish
>psd=y.
No, that is not at all what I said.
Most PSDs will publish no DMARC record at all. Based on what Scott has said,
the handful that do publish a DMARC record will indeed include
On January 25, 2022 5:36:23 PM UTC, Alessandro Vesely wrote:
>On Tue 25/Jan/2022 12:47:21 +0100 Scott Kitterman wrote:
>> On January 25, 2022 11:30:51 AM UTC, Alessandro Vesely
>> wrote:
>>> On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote:
On Monday, January 24, 2022 10:15:49 PM
On Tue 25/Jan/2022 12:47:21 +0100 Scott Kitterman wrote:
On January 25, 2022 11:30:51 AM UTC, Alessandro Vesely wrote:
On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote:
On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote:
On January 25, 2022 12:46:48 AM UTC, John Levine
On January 25, 2022 11:30:51 AM UTC, Alessandro Vesely wrote:
>On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote:
>> On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote:
>>> On January 25, 2022 12:46:48 AM UTC, John Levine wrote:
It appears that Scott Kitterman
On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote:
On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote:
On January 25, 2022 12:46:48 AM UTC, John Levine wrote:
It appears that Scott Kitterman said:
What I implemented is roughly:
For policy determination, first check
On Mon 24/Jan/2022 15:40:01 +0100 John Levine wrote:
On Mon, 24 Jan 2022, Alessandro Vesely wrote:
This misses the point. It would be a good idea for a multi-tenant
domain to publish a PSD record to keep the tenants apart, just as
it would be a good idea to send a PSL pull request to keep
On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote:
> On January 25, 2022 12:46:48 AM UTC, John Levine wrote:
> >It appears that Scott Kitterman said:
> >>What I implemented is roughly:
> >>
> >>For policy determination, first check the From domain, if that has a DMARC
>
On January 25, 2022 12:46:48 AM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>What I implemented is roughly:
>>
>>For policy determination, first check the From domain, if that has a DMARC
>>record, then that's the policy domain. Otherwise, tree walk up to the apex
It appears that Scott Kitterman said:
>What I implemented is roughly:
>
>For policy determination, first check the From domain, if that has a DMARC
>record, then that's the policy domain. Otherwise, tree walk up to the apex
>looking for DMARC records. First domain you find with a record is
On Monday, January 24, 2022 5:23:27 PM EST Scott Kitterman wrote:
> On Wednesday, January 19, 2022 1:38:15 PM EST John Levine wrote:
> > I took a look at sections 4.5 and 4.6 of the draft, the part that
> > describes
> > the tree walk and PSD, and unfortunately what it currently says is
> >
On Wednesday, January 19, 2022 1:38:15 PM EST John Levine wrote:
> I took a look at sections 4.5 and 4.6 of the draft, the part that describes
> the tree walk and PSD, and unfortunately what it currently says is
> seriously wrong. Apologies for not catching this sooner.
>
> It currently says you
On Mon, 24 Jan 2022, Alessandro Vesely wrote:
This misses the point. It would be a good idea for a multi-tenant domain
to publish a PSD record to keep the tenants apart, just as it would be a
good idea to send a PSL pull request to keep them from spoofing browser
cookies, but I don't think it
On Sat 22/Jan/2022 16:29:34 +0100 John Levine wrote:
Ale said:
Mike said:
I have previously pointed out that there are organizations that
lease/rent or otherwise provide subdomains as part of their
commercial offerings. Your assertion is akin to claiming that
tenants in an apartment building
To correct my last post, we are not reduced to using a list, as we have
already anticipated this situation with the PSD flag.
The solution to the sub-lease situation is for the parent domain to publish
psd=y.
We may need two PSD flag, one for
"I am a real PSD and never send mail and should not
On Sat, Jan 22, 2022 at 11:02 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> If a.b.example.com is considered aligned with c.example.com under
> RFC7489, but will be considered unaligned under DMARCbis, then we have a
> pretty significant incompatibility and need to move to
If a.b.example.com is considered aligned with c.example.com under RFC7489,
but will be considered unaligned under DMARCbis, then we have a pretty
significant incompatibility and need to move to DMARCv2.
In the current example of comparing a.b.example.com and c.example.com to
each other: if there
Ale said:
No, the concept of Organizational Domain is foundational to DMARC. ...
We went though this whole discussion quite a while ago when we agreed to
switch to the tree walk. Unless you have a compelling argument about why
our previous analysis and decision was wrong, I think we're
On Sat, Jan 22, 2022 at 6:52 AM Alessandro Vesely wrote:
>
> No, the concept of Organizational Domain is foundational to DMARC. We
> cannot
> overthrow it to spare an extra lookup. When we talked about tree walk we
> knew
> that additional lookups might well have come out.
>
> To specify
Yes, that is the plan. Please go back and look at the discussion when we
talked about the tree walk in the first place.
I don't remember that we ever convene that subdomains cannot override the org
domain record.
The "org domain record" is now whatever you find in the tree walk. There
is
On Fri 21/Jan/2022 15:20:17 +0100 Douglas Foster wrote:
Your idea is brilliant - search for a policy that applies to both the FROM
domain and the other domain name. If it is not a PSD policy, then the two
names are aligned. It eliminates the PSL while also creating no need for PSD
policies.
On Friday, January 21, 2022 9:28:07 AM EST John R Levine wrote:
> >> For the same reason the PSL has a lot of two- and three-label domains.
> >
> > Except that the PSL is somehow vetted; that is, there are no
> > self-appointed
> > PSDs.
>
> Sorry, but that is simply false. The entire "private
For the same reason the PSL has a lot of two- and three-label domains.
Except that the PSL is somehow vetted; that is, there are no self-appointed
PSDs.
Sorry, but that is simply false. The entire "private domains" part of the
PSD is self-appointed PSDs.
No, the org domain for
Your idea is brilliant - search for a policy that applies to both the FROM
domain and the other domain name. If it is not a PSD policy, then the two
names are aligned. It eliminates the PSL while also creating no need for
PSD policies.
But your organization assumption does not work. In the RFC
On Fri 21/Jan/2022 05:29:05 +0100 John Levine wrote:
It appears that Alessandro Vesely said:
On Wed 19/Jan/2022 19:38:15 +0100 John Levine wrote:
What I always intended with the tree walk is that you walk up the tree and if
you find
a DMARC record that isn't a PSD, that's your org domain.
It appears that Alessandro Vesely said:
>On Wed 19/Jan/2022 19:38:15 +0100 John Levine wrote:
>> What I always intended with the tree walk is that you walk up the tree and
>> if you find
>> a DMARC record that isn't a PSD, that's your org domain. To see if two
>> names are in relaxed
>>
That sounds closer. I think Todd knows what he needs to change, so I'd prefer
to see what goes into the document than to continue to tweak it.
Scott K
On Thursday, January 20, 2022 12:18:03 PM EST Douglas Foster wrote:
> So if the first tree walk stops at a a PSD=y policy, then the match
So if the first tree walk stops at a a PSD=y policy, then the match string
used for alignment is the organizational domain, one segment down from the
PSD policy. Any SPF or DKIM domain must match or be a child of the
organizational domain, so there is no secondary tree walk,
Does that correct
On Thursday, January 20, 2022 9:57:48 AM EST Douglas Foster wrote:
...
> -- If a policy is found with PSD=y, the domain does not participate in
> DMARC but may need to be tested for non-existence. If the policy also
> specifies NP=reject, query the next-lower domain name for a resource
> record.
I think this refinement of the concept will work better:
1) Check to see if the From domain participates in DMARC
Starting with the FROM domain, perform the previously specified tree walk
(start with the exact-match FROM domain, jumping to level 5 if necessary,
then continuing to walk up the
On January 19, 2022 6:47:56 PM UTC, Todd Herr
wrote:
>On Wed, Jan 19, 2022 at 1:38 PM John Levine wrote:
>
>> I took a look at sections 4.5 and 4.6 of the draft, the part that
>> describes the tree walk
>> and PSD, and unfortunately what it currently says is seriously wrong.
>> Apologies for
On Wed, Jan 19, 2022 at 1:38 PM John Levine wrote:
> I took a look at sections 4.5 and 4.6 of the draft, the part that
> describes the tree walk
> and PSD, and unfortunately what it currently says is seriously wrong.
> Apologies for
> not catching this sooner.
>
>
>
No worries; that's what draft
I took a look at sections 4.5 and 4.6 of the draft, the part that describes the
tree walk
and PSD, and unfortunately what it currently says is seriously wrong.
Apologies for
not catching this sooner.
It currently says you do a tree walk to find a PSD record, and the org domain
is the one
39 matches
Mail list logo
