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
Richard,
Thanks for the notes. I'll file a few trac issues to get these resolved, and
try to get a new version released soon-ish. If you're okay with it, I may send
you a preview version to ensure it resolves the items noted below. Thanks again
--
Alex Brotman
Sr. Engineer, Anti-Abuse &
On Tuesday, January 25, 2022 2:48:24 PM EST Todd Herr wrote:
> Greetings.
>
> I've been monitoring the on-list discussion and I would like to take a stab
> at incorporating it into the next draft.
>
> My plan is to get a next draft released either Monday, January 31
> or Tuesday, February 1, but
>
>
> 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
I think that draft revisions are cheap, and that it's better to put a
revision out than to hold it for more changes.
Barry
On Tue, Jan 25, 2022 at 2:49 PM Todd Herr wrote:
> Greetings.
>
> I've been monitoring the on-list discussion and I would like to take a
> stab at incorporating it into
Greetings.
I've been monitoring the on-list discussion and I would like to take a stab
at incorporating it into the next draft.
My plan is to get a next draft released either Monday, January 31
or Tuesday, February 1, but that will depend on whether or not list
discussion reaches a point where
On Tue, Jan 25, 2022 at 11:26 AM John R Levine wrote:
> On Tue, 25 Jan 2022, Murray S. Kucherawy wrote:
> >> will get the same result. It also occurs to me that in the absence of
> >> a PSL-like thing, the idea of an organizational domain is no longer
> >> useful.
> >
> > Aren't we basically
On Tue, 25 Jan 2022, Murray S. Kucherawy wrote:
will get the same result. It also occurs to me that in the absence of
a PSL-like thing, the idea of an organizational domain is no longer
useful.
Aren't we basically trying to identify the same thing, just in a different
(and more robust) way?
On Tue, Jan 25, 2022 at 9:40 AM John Levine wrote:
> It appears that Scott Kitterman said:
> >My impression is that the group is generally okay with PSD=y. I prefer
> it over your suggestion. My strongest preference is that we pick
> something, stick with it, and move on.
>
> I think I see
On Tue, 25 Jan 2022, Dotzero wrote:
If they are cousin domains, walk up the tree from each until you find a
policy record. If you find the same policy
record and it's not a PSD and it allows relaxed alignment, they're in
relaxed alignment. If you find different
records, or only one record, or
On Tue, Jan 25, 2022 at 12:40 PM John Levine wrote:
> It appears that Scott Kitterman said:
> >My impression is that the group is generally okay with PSD=y. I prefer
> it over your suggestion. My strongest preference is that we pick
> something, stick with it, and move on.
>
> I think I see
On January 25, 2022 5:40:09 PM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>My impression is that the group is generally okay with PSD=y. I prefer it
>>over your suggestion. My strongest preference is that we pick something,
>>stick with it, and move on.
>
>I think I
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
It appears that Scott Kitterman said:
>My impression is that the group is generally okay with PSD=y. I prefer it
>over your suggestion. My strongest preference is that we pick something,
>stick with it, and move on.
I think I see where Ale's confusion is coming from. If we switch to a
tree
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
Hi,
I've been reading over the DMARC Aggregate Reporting draft and have
some feedback on the schema and sample report.
* The ActionDispositionType type definition in the schema is missing a
closing tag
* The schema has the DMARC report version element ()
specified immediately under the root
20 matches
Mail list logo
