Barry,
Your note underscored the lack of interest in engaging in discussion of
the original substance to my posting. So I will of course drop further
attempts at improving the working group's documentation effort.
However your note also underscored a basic misunderstanding in rules,
On Tue 01/Feb/2022 00:01:33 +0100 Dotzero wrote:
On Mon, Jan 31, 2022 at 3:51 PM Alessandro Vesely wrote:
(This message is not going to be accepted by the IETF today, so I CC John too)
Why wouldn't your email be accepted?
I messed around with the DNS and reverse IP wasn't resolving
On Mon, Jan 31, 2022 at 3:51 PM Alessandro Vesely wrote:
> (This message is not going to be accepted by the IETF today, so I CC John
> too)
>
Why wouldn't your email be accepted?
>
> On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote:
> >>> 3. The role of the function that uses the PSD and
No that will not work.
A TLD is always a PSD, and PSDs cannot be used for alignment.
Domain1.bank and Dkim.bank are considered part of different administrative
domains.
I am also recommending that we move away from sister-domain alignment. If
adopted, then Domain1.OrgDomain and Dkim.OrgDomain
(This message is not going to be accepted by the IETF today, so I CC John too)
On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote:
3. The role of the function that uses the PSD and the role of the
function that does a tree walk are identical. Since you apparently feel
otherwise, please
Dave,
> 2. Your 'for the sake of' is uncalled for and dismissive. Please stop
> doing that. Attempts to be dismissive are a popular debating
> technique in the IETF, but they are counter-productive, as well as
> unprofessional.
Two things here:
First, please do not admonish participants for
My two cents:
Our document will be both a technical description of how to participate in
DMARC and a persuasive description of why participation is desirable. The
organization domain represents an ADMD. Therefore, alignment is not
allowed between two organizational domains because they
On Sunday, January 30, 2022 2:57:56 PM EST Dave Crocker wrote:
> On 1/30/2022 10:39 AM, Scott Kitterman wrote:
> > On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote:
> >> On 1/29/2022 7:53 PM, Scott Kitterman wrote:
> 1. Using 7489 or 9091 as fixed, controlling documents is
On 1/30/2022 10:39 AM, Scott Kitterman wrote:
On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote:
On 1/29/2022 7:53 PM, Scott Kitterman wrote:
1. Using 7489 or 9091 as fixed, controlling documents is problematic, as
I've noted. So, 'consistency' with them is frankly irrelevant.
On Sunday, January 30, 2022 11:14:18 AM EST John R Levine wrote:
> On Sun, 30 Jan 2022, Alessandro Vesely wrote:
> > Let me ask if the following scenario is possible at all:
> >
> > .BANK admins decide to setup a DKIM signing service for .bank domains.
> > They register dkim.bank, and accept and
On Sunday, January 30, 2022 7:34:35 AM EST Alessandro Vesely wrote:
> (This message is not going to be accepted by the IETF today, so I CC John
> too)
> On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote:
> >>> 3. The role of the function that uses the PSD and the role of the
> >>> function that
On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote:
> On 1/29/2022 7:53 PM, Scott Kitterman wrote:
> >> 1. Using 7489 or 9091 as fixed, controlling documents is problematic, as
> >> I've noted. So, 'consistency' with them is frankly irrelevant.
> >
> > The WG charter doesn't say
RFC 7489 has two different scopes applied to policies:
current-domain-only and
current-domain-plus-subdomains
For undocumented reasons, RFC 7489 created a restriction that
current-domain-plus-subdomains may only be used on "organizational domains"
(since revised to include PSD domains). I see
On 1/30/2022 4:34 AM, Alessandro Vesely wrote:
ANK admins decide to setup a DKIM signing service for .bank domains.
They register dkim.bank, and accept and relay messages originating
from their customers, signing them with d=dkim.bank. (Compare to
onmicrosoft.com?)
They may consider that a
On 1/29/2022 7:53 PM, Scott Kitterman wrote:
1. Using 7489 or 9091 as fixed, controlling documents is problematic, as
I've noted. So, 'consistency' with them is frankly irrelevant.
The WG charter doesn't say that they are irrelevant. I don't think we should
be redefining terms for the sake of
On Saturday, January 29, 2022 10:26:37 PM EST Dave Crocker wrote:
> On 1/29/2022 1:58 PM, Scott Kitterman wrote:
> > So going
> > back to Dave's proposed text that started the thread:
> >
> > On Saturday, January 29, 2022 1:11:29 PM EST Dave Crocker wrote:
> >> Here is some alternative phrasing:
On 1/29/2022 1:58 PM, Scott Kitterman wrote:
So going
back to Dave's proposed text that started the thread:
On Saturday, January 29, 2022 1:11:29 PM EST Dave Crocker wrote:
Here is some alternative phrasing:
For DMARC, an Organizational Domain can contain a DMARC record, to
be used
On 1/29/2022 12:48 PM, John R Levine wrote:
Since a PSD can't be an organizational domain, I don't think that's
going to work.
Please provide the foundation to this assertion, because I believe
the text I've offered makes your premise wrong.
Then it's lucky we caught this mistake now, isn't
On Saturday, January 29, 2022 3:48:46 PM EST John R Levine wrote:
> >> Since a PSD can't be an organizational domain, I don't think that's going
> >> to work.
> >
> > Please provide the foundation to this assertion, because I believe the
> > text
> > I've offered makes your premise wrong.
>
>
Since a PSD can't be an organizational domain, I don't think that's going
to work.
Please provide the foundation to this assertion, because I believe the text
I've offered makes your premise wrong.
Then it's lucky we caught this mistake now, isn't it?
See RFC 9091, section 1.
Regards,
John
On 1/29/2022 10:52 AM, John Levine wrote:
Since a PSD can't be an organizational domain, I don't think that's going to
work.
Please provide the foundation to this assertion, because I believe the
text I've offered makes your premise wrong.
That is, I think you are taking as a given,
It appears that Dave Crocker said:
>Here is some alternative phrasing:
>
>For DMARC, an Organizational Domain can contain a DMARC record, to
>be used as the default DMARC record for subordinate domains that do
>not have a DMARC record of their own, and for subordinate domains
>
22 matches
Mail list logo
