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
On 1/26/2022 11:11 AM, John R Levine wrote:
Hm, we're addressing the same problem that DBOND did, but it's not
DBOUND. Well, OK.
You seem to be, but I'm not.
I'm addressing a documentation issue. I'm sorry you are having so much
trouble understanding that.
I've no idea how you came up
2. But since you are asking, I think it is pretty easy to specify the details
of the mechanism in a way that does not require DMARC specific text. Not
because it is will or might have more general use -- that that's often a
collateral benefit -- but because specs should not overspecify detail
On 1/26/2022 10:49 AM, Scott Kitterman wrote:
Or, not to put too fine a point on it, if you two want to discuss DBOUND, I
thinkdbo...@ietf.org is still active.
there's nothing in what I posted that has anything to do with dbound or
possible derivatives. The introduction of the reference
On 1/26/2022 10:54 AM, John R Levine wrote:
Ahh, You are claiming I said something about a 'general method'. I
didn't.
Since you think otherwise, could you explain in simple language that
even I could understand how you reached that interpretation of my note?
Now we're both confused.
Ahh, You are claiming I said something about a 'general method'. I didn't.
Since you think otherwise, could you explain in simple language that even I
could understand how you reached that interpretation of my note?
Now we're both confused. When you said "The method of finding the
On Wednesday, January 26, 2022 1:47:37 PM EST Dave Crocker wrote:
> On 1/26/2022 10:38 AM, John R Levine wrote:
> >>> It appears that Dave Crocker said:
> The method of finding the organizational domain should be specified
> outside of the base DMARC specification. I suggested this
On 1/26/2022 10:38 AM, John R Levine wrote:
It appears that Dave Crocker said:
The method of finding the organizational domain should be specified
outside of the base DMARC specification. I suggested this back during
the PSD discussion.
That assumes that the org domain is useful on its own,
It appears that Dave Crocker said:
The method of finding the organizational domain should be specified
outside of the base DMARC specification. I suggested this back during
the PSD discussion.
That assumes that the org domain is useful on its own, rather than
just as a tool to help find
On 1/26/2022 10:04 AM, John Levine wrote:
It appears that Dave Crocker said:
The method of finding the organizational domain should be specified
outside of the base DMARC specification. I suggested this back during
the PSD discussion.
That assumes that the org domain is useful on its own,
On Tue 25/Jan/2022 20:39:11 +0100 Murray S. Kucherawy wrote:
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
On Wednesday, January 26, 2022 12:30:01 PM EST Seth Blank wrote:
> Yes, this is a core ticket that needs to be addressed:
> https://trac.ietf.org/trac/dmarc/ticket/46
>
> I believe right now the group is just dialing in the definition/text, but
> there has been broad agreement (I don't remember
It appears that Dave Crocker said:
>-=-=-=-=-=-
>
>G'day.
>
>The method of finding the organizational domain should be specified
>outside of the base DMARC specification. I suggested this back during
>the PSD discussion.
That assumes that the org domain is useful on its own, rather than
just
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 1/26/2022 9:30 AM, Seth Blank wrote:
Yes, this is a core ticket that needs to be addressed:
https://trac.ietf.org/trac/dmarc/ticket/46
21 months ago? as if I'd remember something from 21 minutes ago. sheesh.
I believe right now the group is just dialing in the definition/text,
but
Yes, this is a core ticket that needs to be addressed:
https://trac.ietf.org/trac/dmarc/ticket/46
I believe right now the group is just dialing in the definition/text, but
there has been broad agreement (I don't remember hearing any disagreement,
but I wouldn't go so far as to call it consensus
G'day.
The method of finding the organizational domain should be specified
outside of the base DMARC specification. I suggested this back during
the PSD discussion.
There are a number of reasons:
1. There is already an installed base using the PSL. While I understand
the desire to move
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.
20 matches
Mail list logo
