On November 1, 2021 2:19:02 AM UTC, Douglas Foster
wrote:
>Currently, the Publicssuffix.org list protects the PSL names. Although I
>don't believe it is covered anywhere in the DMARC v1 document, any DMARC
>implementer will have to notice that a PSL name must produce DMARC FAIL,
>because it
Ad hominem dismissal of things that you disagree with as "crazy talk" is not an
effective form of technical argument.
Care to try again.
Scott K
On November 1, 2021 1:29:19 AM UTC, Douglas Foster
wrote:
>To my mind, it is crazy talk to assert that DMARC is not an authentication
>method.
>
Currently, the Publicssuffix.org list protects the PSL names. Although I
don't believe it is covered anywhere in the DMARC v1 document, any DMARC
implementer will have to notice that a PSL name must produce DMARC FAIL,
because it cannot be authenticated itself, and it cannot be authenticated
by
To my mind, it is crazy talk to assert that DMARC is not an authentication
method.
My bank's phone app gives me the option of authenticating with either a
username+password or a fingerprint. For remote access to work computers,
I use two authentication methods together. Using two component
On Sun, Oct 31, 2021 at 1:03 PM Scott Kitterman
wrote:
> Perhaps it's a pointless semantic distinction. I think of DMARC as a
> mechanism for expressing policy about authentication, not an authentication
> method.
>
> I still don't understand what you think is unprotected.
>
> Scott K
>
+1
Perhaps it's a pointless semantic distinction. I think of DMARC as a mechanism
for expressing policy about authentication, not an authentication method.
I still don't understand what you think is unprotected.
Scott K
On October 31, 2021 4:48:10 PM UTC, Douglas Foster
wrote:
>DMARC is an
John said
I don't immediately see the utility of the org domain of the HELO unless
you're
checking SPF on a bounce, but why wouldn't you do the same tree walk?
Apparently he has never evaluated the reputation of server organizations by
aggregating data based on server organization. It is a
DMARC is an authentication test also. The authentication of the first
identifier (SPF or DKIM) serves as a proxy to authenticate the second
identifer (FROM), which is conditioned on a satisfactory relationship
(equal or aligned) between the two domains.
You began to address the issue in your
Neither SPF nor DKIM use the PSL, so I still don't understand. What do you
mean by "authentication testing"?
Scott K
On October 31, 2021 11:30:29 AM UTC, Douglas Foster
wrote:
>We have two issues floating here:
>1) For policy lookup, replace the PSL with a constrained tree walk.
>2) For
On October 31, 2021 11:29:41 AM UTC, Alessandro Vesely wrote:
>On Sat 30/Oct/2021 22:56:00 +0200 Scott Kitterman wrote:
>> On October 30, 2021 8:47:51 PM UTC, John Levine wrote:
>>> According to Scott Kitterman :
>That usage has proven to work quite well. And some respect for the
It appears that Alessandro Vesely said:
The alternative I suggested is 100% compatible with the installed base.
If a domain has published DMARC policy per RFC 7489, the proposed new
approach will still find it.
>
>Yes, but would PSL-based DMARC filters have to be re-written,
On Sat 30/Oct/2021 05:15:14 +0200 Scott Kitterman wrote:
On October 30, 2021 1:58:00 AM UTC, Douglas Foster
wrote:
I enthusiastically endorse John's proposal for policy discovery.
PSL replacement using DNS Flags
This proposal specifies a resource record that can be used to distinguish
We have two issues floating here:
1) For policy lookup, replace the PSL with a constrained tree walk.
2) For authentication testing, replace the PSL with something based on the
policy lookup.
Currently, the DMARC policy has nothing to do with the authentication
test.
If the second idea is still
On Sat 30/Oct/2021 22:56:00 +0200 Scott Kitterman wrote:
On October 30, 2021 8:47:51 PM UTC, John Levine wrote:
According to Scott Kitterman :
That usage has proven to work quite well. And some respect for the installed
base wouldn't hurt.
The alternative I suggested is 100% compatible
On Sat 30/Oct/2021 19:42:01 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
IMHO, we shouldn't throw away the PSL. Most importantly, we should stick to
the concept of Organizational Domain. We can give an abstract definition of
the latter in terms of affiliation of some
Count| Bytes | Who
++---
50 ( 100%) | 406868 ( 100%) | Total
15 (30.0%) | 81050 (19.9%) | John Levine
11 (22.0%) | 96610 (23.7%) | Scott Kitterman
6 (12.0%) | 81478 (20.0%) | Douglas Foster
4 ( 8.0%) | 31641 ( 7.8%) | Joe Humphreys
16 matches
Mail list logo
