If you prefix _domainkey to those names and do a lookup, several of them
return NOERROR which suggests they have DKIM keys.
Hm... one of them returns NXDOMAIN even though there is a DMARC record
below.
ale@pcale:~/tmp$ dig mail.foodnetwork.com
;; ->>HEADER<<- opcode: QUERY, status:
On Mon 20/Dec/2021 20:59:45 +0100 John Levine wrote:
It appears that Alessandro Vesely said:
On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote:
I am not doing any root domain lookups. If that is part of the proposed
algorithm, somebody needs to document it. I am simply looking for a
Using an NXDOMAIN test, I have these occurrences in the last 24 hours:
- 1 nxdomain that is from a legitimate sender,
- 1 that is NXDOMAIN because the ESP misspelled the client organization
name, and
- 1 that is a bogus NDR.
So the NXDOMAIN test will identify fewer problems, but will create fewer
It is not infrequent. Here is some more detailed statistics:
msgs domains description Msg Fail Domain Fail
3,025 1,253 All messages1.72% 0.80%
1,098 296 Allowed msgs4.74% 3.38%
581 175 ESP messages8.95% 5.71%
52 10 MX/A Failures
The percentages are
It appears that Alessandro Vesely said:
>On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote:
>> I am not doing any root domain lookups. If that is part of the proposed
>> algorithm, somebody needs to document it. I am simply looking for a
>> resource
>> record matching the FROM domain
On Monday, December 20, 2021 12:10:31 PM EST Alessandro Vesely wrote:
> On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote:
> > I am not doing any root domain lookups. If that is part of the proposed
> > algorithm, somebody needs to document it. I am simply looking for a
> > resource record
On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote:
I am not doing any root domain lookups. If that is part of the proposed
algorithm, somebody needs to document it. I am simply looking for a resource
record matching the FROM domain name.
Oops, yes, you're right. Dunno why I looked
I am not doing any root domain lookups. If that is part of the proposed
algorithm, somebody needs to document it. I am simply looking for a
resource record matching the FROM domain name.
Because I am a Windows guy, I use the deprecated NSLOOKUP. I have done
minimal work in DIG. I retested
On Mon 20/Dec/2021 00:42:27 +0100 Douglas Foster wrote:
I detected 52 messages, from 10 unique domains, which failed the MX/A test.
[...]
7 of 10 had DMARC PASS based on both SPF and DKIM:
bc.qvcemail.com
doctors-digest.com
email.nutricia-na.com
mail.foodnetwork.com
mail.medscape.org
Here are some results based on 3025 messages, involving 1253 unique
RFC5322.From domains, collected over less than 24 hours. These results
are collected AFTER excluding messages from blacklisted sources and sources
with SPF=NXDOMAIN, so a high percentage is not spam.
I detected 52 messages,
On Fri, Dec 17, 2021 at 9:06 PM Scott Kitterman
wrote:
> On Friday, December 17, 2021 8:43:17 PM EST Tim Wicinski wrote:
> > On Fri, Dec 17, 2021 at 6:56 PM Douglas Foster <
> >
> > dougfoster.emailstanda...@gmail.com> wrote:
> > > That is not my position, and I don't know how you drew that
> >
The previous message laid out what we should seek in an NP test, but rushed
through the ending.
We are looking to create a test:
- Which identifies all names that are used for RFC5322.From
addressing, so that names which are not identified can be classified as
NP=TRUE because the domain
On Fri, Dec 17, 2021 at 6:56 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> That is not my position, and I don't know how you drew that
> conclusion from those words.
>
Then my mistake.
>
> I do take the position that DMARC PASS means "This name correctly
> represents the
That is not my position, and I don't know how you drew that conclusion from
those words.
I do take the position that DMARC PASS means "This name correctly
represents the stated domain", and NP=TRUE means "This name cannot
represent the stated domain because the domain owner never uses that
name".
On Fri, Dec 17, 2021 at 6:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> The way I evaluate a design is to first look for logical consistency or
> inconsistency.If there is obvious inconsistency, then the design needs
> to be re-evaluated to correct the problem.Once
The way I evaluate a design is to first look for logical consistency or
inconsistency.If there is obvious inconsistency, then the design needs
to be re-evaluated to correct the problem.Once a design appears to be
logically consistent, we do data analysis to validate our design. The
On Fri 17/Dec/2021 18:38:54 +0100 Tim Wicinski wrote:
On Fri, Dec 17, 2021 at 12:30 PM Dotzero wrote:
DMARC does not assess "honesty" nor does it assess "fraudulence". It only
determines whether something passes or fails the validation check. You are
apparently trying to overload your value
On Fri, Dec 17, 2021 at 12:30 PM Dotzero wrote:
>
>
>
>
> DMARC does not assess "honesty" nor does it assess "fraudulence". It only
> determines whether something passes or fails the validation check. You are
> apparently trying to overload your value interpretations in a manner that
> does not
On Thu, Dec 16, 2021 at 12:58 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Yes, this is important stuff.
>
> This is one of my problem scenarios:
>
> A record arrives at the first hop and obtains DMARC PASS, based on SPF
> and/or DKIM interpreted by a DMARC policy. Based on
On Thu, Dec 16, 2021 at 3:52 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> We both know exactly what causes messages to lose credentials:
> - A record that is only SMTP validated, which is then forwarded without
> SMTP rewrite
> - A message which is forwarded after
We both know exactly what causes messages to lose credentials:
- A record that is only SMTP validated, which is then forwarded without
SMTP rewrite
- A message which is forwarded after modifications, such as the ubiquitous
"this message received from an external source". Of course, it could be a
On Wed, Dec 15, 2021 at 9:58 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Yes, this is important stuff.
>
> This is one of my problem scenarios:
>
> A record arrives at the first hop and obtains DMARC PASS, based on SPF
> and/or DKIM interpreted by a DMARC policy. Based on
On Thu, Dec 16, 2021 at 12:58 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Yes, this is important stuff.
>
> This is one of my problem scenarios:
>
> A record arrives at the first hop and obtains DMARC PASS, based on SPF
> and/or DKIM interpreted by a DMARC policy. Based on
Yes, this is important stuff.
This is one of my problem scenarios:
A record arrives at the first hop and obtains DMARC PASS, based on SPF
and/or DKIM interpreted by a DMARC policy. Based on DMARC PASS, the
RFC5322.From address is confidently judged to be "Honestly identified"
DMARC checks SPF
Agreed. That's the most recently added PSD record and my guess is they are
early in their journey. For those of you that haven't done it, managing
deployment of DMARC (+ DKIM and SPF) across a large number of domains is a
very time consuming process. Getting the internal policies right is at
Thanks Scott. _dmarc.police.uk doesn't seem to have the 'np' tag.
There are a number of domains with policies that have 'p=quarantine|reject
sp=none' - it would be good to see if 'np=reject' is added to any.
tim
On Wed, Dec 15, 2021 at 6:50 PM Scott Kitterman
wrote:
> On Wednesday,
On Wednesday, December 15, 2021 5:44:46 PM EST Barry Leiba wrote:
> > Scott, I have many problems with your response. Was it intended as an
> > ad hominem? It certainly came across that way.
>
> It doesn't seem even remotely so to me. Please be careful with
> attributing intent. No one tried
> Scott, I have many problems with your response. Was it intended as an ad
> hominem?
> It certainly came across that way.
It doesn't seem even remotely so to me. Please be careful with
attributing intent. No one tried to say that we shouldn't listen to
you.
> If the NP objective can be
Scott, I have many problems with your response. Was it intended as an ad
hominem? It certainly came across that way.
If the NP objective can be stated in a sentence or two, you should have
done so, instead of telling me to read years of archive. An objective that
cannot be explained tersely
On December 15, 2021 4:16:13 AM UTC, Douglas Foster
wrote:
>What does we mean for an RFC5322.From address to be “non-existent”?
>
>We have said that it is non-existent because it fails the MX/A/ test,
>but we have not documented what that test represents. Perhaps it seemed
>obvious, but
What does we mean for an RFC5322.From address to be “non-existent”?
We have said that it is non-existent because it fails the MX/A/ test,
but we have not documented what that test represents. Perhaps it seemed
obvious, but let's make it clear:
A failed MX/A/ test is a very reliable
31 matches
Mail list logo
