Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[John R Levine]

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: NXDOMAIN, id: 64715


Sigh.  That's just wrong.  I'll see if I can find someone who can fix it.

R's,
John

PS: pretty please can we not even think about changing the spec to work 
around other people's bugs


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[Alessandro Vesely]

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 resource 
record matching the FROM domain name.



Oops, yes, you're right.  Dunno why I looked up their org domain, probably lack 
of caffeine...


Those 10 domains are non-existing under 3.2.6.  Only 4 of them return NXDOMAIN.


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

; <<>> DiG 9.16.15-Debian <<>> mail.foodnetwork.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64715
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d56c07ed27e795d3010061c1bc09cea5581e05ff08ab (good)
;; QUESTION SECTION:
;mail.foodnetwork.com.  IN  A

;; AUTHORITY SECTION:
foodnetwork.com.875 IN  SOA ns-298.awsdns-37.com. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400


ale@pcale:~/tmp$ dig _dmarc.mail.foodnetwork.com txt

; <<>> DiG 9.16.15-Debian <<>> _dmarc.mail.foodnetwork.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32999
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 00298aa760a08142010061c1bc0e9fc192e7b9269cf7 (good)
;; QUESTION SECTION:
;_dmarc.mail.foodnetwork.com.   IN  TXT

;; ANSWER SECTION:
_dmarc.mail.foodnetwork.com. 300 IN TXT "v=DMARC1; p=reject; fo=1; ri=3600; 
rua=mailto:discov...@rua.agari.com; ruf=mailto:discov...@ruf.agari.com";




For the umpteenth time, there is a DNS definition of non-existent which is the 
only
one you get to use in the IETF.



The definition in Section 3.2.6 is different.



Can we stop wasting time with this fruitless argument, please?


Yes.

Best
Ale
--







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[Douglas Foster]

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
problems also.

Caveat:  Consider that my email stream is modest.  Internet scale
multiplies everything by many orders of magnitude.   Does anyone have data
from a bigger message stream?

Doug

On Sun, Dec 19, 2021 at 6:42 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> 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, from 10 unique domains, which failed the MX/A
> test.  I do not test on  because I do not accept mail using IPv6.
>
> All 10 could produce DMARC PASS based on relaxed alignment, although I
> have not evaluated whether they publish a DMARC policy.   I simply evaluate
> SPF and DKIM based on relaxed alignment for all incoming messages.
>
> All 10 domains had RFC5321.MailFrom and RFC5322.From domains that were
> different.
>
> 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
> mktg.daily-harvest.com
> email3.reachmd.com
>
> 1 of 10 had DMARC PASS based on SPF alignment only:
> mg.homedepot.com
>
> 2 of 10 had DMARC PASS based on DKIM only:
> info.extraspace.com
> update.strava.com
>
> 1 of 10 had an SPF record on the RFC5322.From address.
> email.nutricia-na.com
>
> Overall, this suggests to me that ESP messages will have trouble complying
> with any NP criteria, and this may force us to use a weaker one, such as
> NXDOMAIN only, even though my preference is a strong one.
>
> Doug Foster
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[Douglas Foster]

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 relative to the failure counts.
"ESP messages" counts any message where the From addresses are different.
So 5.7% of third-party mailings use a From address that is not found or not
easily found in DNS.  This is not insignificant.

John, I don't know what algorithm you are proposing.   Please clarify.

Doug

On Mon, Dec 20, 2021 at 12:10 PM 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 matching the FROM domain name.
>
>
> Oops, yes, you're right.  Dunno why I looked up their org domain, probably
> lack
> of caffeine...
>
> Those 10 domains are non-existing under 3.2.6.  Only 4 of them return
> NXDOMAIN.
>
> One of them, mail.foodnetwork.com, has its own DMARC record with a policy
> different from that of its parent domain, which can be a reason to use a
> subdomain.  (Curiously, it is one of those returning NXDOMAIN.)
>
> For the other 9, all what I can think of is some kind of
> misconfiguration.  I
> asked a few times why would one want to use a non-existing domain for the
> From:
> address, but got no answers.  Anyway, your numbers show that it's not a
> very
> frequent setup.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[John Levine]

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 name.
>
>
>Oops, yes, you're right.  Dunno why I looked up their org domain, probably 
>lack 
>of caffeine...
>
>Those 10 domains are non-existing under 3.2.6.  Only 4 of them return NXDOMAIN.

If you prefix _domainkey to those names and do a lookup, several of them
return NOERROR which suggests they have DKIM keys.

For the umpteenth time, there is a DNS definition of non-existent which is the 
only
one you get to use in the IETF.  Can we stop wasting time with this fruitless
argument, please?

R's,
John


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[Scott Kitterman]

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 matching the FROM domain name.
> 
> Oops, yes, you're right.  Dunno why I looked up their org domain, probably
> lack of caffeine...
> 
> Those 10 domains are non-existing under 3.2.6.  Only 4 of them return
> NXDOMAIN.
> 
> One of them, mail.foodnetwork.com, has its own DMARC record with a policy
> different from that of its parent domain, which can be a reason to use a
> subdomain.  (Curiously, it is one of those returning NXDOMAIN.)
> 
> For the other 9, all what I can think of is some kind of misconfiguration. 
> I asked a few times why would one want to use a non-existing domain for the
> From: address, but got no answers.  Anyway, your numbers show that it's not
> a very frequent setup.

... for legitimate mail.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[Alessandro Vesely]

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 up their org domain, probably lack 
of caffeine...


Those 10 domains are non-existing under 3.2.6.  Only 4 of them return NXDOMAIN.

One of them, mail.foodnetwork.com, has its own DMARC record with a policy 
different from that of its parent domain, which can be a reason to use a 
subdomain.  (Curiously, it is one of those returning NXDOMAIN.)


For the other 9, all what I can think of is some kind of misconfiguration.  I 
asked a few times why would one want to use a non-existing domain for the From: 
address, but got no answers.  Anyway, your numbers show that it's not a very 
frequent setup.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[Douglas Foster]

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 one of the names and confirmed the same
results:

> set type=MX
> info.extraspace.com
Server:  G3100.myfiosgateway.com
Address:  192.168.1.1

*** G3100.myfiosgateway.com can't find info.extraspace.com: Non-existent
domain
> set type=A
> info.extraspace.com
Server:  G3100.myfiosgateway.com
Address:  192.168.1.1

*** G3100.myfiosgateway.com can't find info.extraspace.com: Non-existent
domain
>

Doug Foster

On Mon, Dec 20, 2021 at 4:44 AM Alessandro Vesely  wrote:

> 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
> > mktg.daily-harvest.com
> > email3.reachmd.com
> >
> > 1 of 10 had DMARC PASS based on SPF alignment only:
> > mg.homedepot.com
> >
> > 2 of 10 had DMARC PASS based on DKIM only:
> > info.extraspace.com
> > update.strava.com
>
>
> What do you mean by "failed the MX/A test"?  Only doctors-digest.com
> seems to be non-existent under 3.2.6.
>
>
> ale@pcale:~/tmp$ for d in $doms mg.homedepot.com info.extraspace.com
> update.strava.com; do r=$(get_root_domain $d|sed -rn 's/^ Root Domain:
> *(.*)$/\1/p'); echo "$d -> $r"; dig +short $r; dig +short $r mx; echo; done
> bc.qvcemail.com -> qvcemail.com
> 167.140.19.203
> 100 smtp2.qvc.com.
> 100 smtp3.qvc.com.
>
> doctors-digest.com -> doctors-digest.com
>
> email.nutricia-na.com -> nutricia-na.com
> 52.36.54.191
> 20 mail3792.nutricianorthamerica.mkt4389.com.
> 5 bounce.email.nutricia-na.com.
> 10 reply.email.nutricia-na.com.
>
> mail.foodnetwork.com -> foodnetwork.com
> 204.78.50.45
> 100 foodnetwork-com.mail.protection.outlook.com.
> 1 aspmx.l.google.com.
> 10 alt3.aspmx.l.google.com.
> 5 alt1.aspmx.l.google.com.
> 5 alt2.aspmx.l.google.com.
> 10 alt4.aspmx.l.google.com.
>
> mail.medscape.org -> medscape.org
> 104.18.27.226
> 104.18.26.226
> 10 alt3.aspmx.l.google.com.
> 10 reply-mx.s6.exacttarget.com.
> 1 aspmx.l.google.com.
> 5 alt2.aspmx.l.google.com.
> 5 alt1.aspmx.l.google.com.
> 10 alt4.aspmx.l.google.com.
>
> mktg.daily-harvest.com -> daily-harvest.com
> 104.18.1.9
> 104.18.0.9
> 10 alt4.aspmx.l.google.com.
> 1 aspmx.l.google.com.
> 10 alt3.aspmx.l.google.com.
> 5 alt1.aspmx.l.google.com.
> 5 alt2.aspmx.l.google.com.
>
> email3.reachmd.com -> reachmd.com
> 34.195.222.240
> 34.233.81.108
> 10 mx1-us1.ppe-hosted.com.
> 10 mx2-us1.ppe-hosted.com.
>
> mg.homedepot.com -> homedepot.com
> 35.201.95.83
> 20 mx0a-000e6601.pphosted.com.
> 10 mxb-000e6601.gslb.pphosted.com.
> 10 mxa-000e6601.gslb.pphosted.com.
> 20 mx0b-000e6601.pphosted.com.
>
> info.extraspace.com -> extraspace.com
> 13.107.246.13
> 10 mxa-00257001.gslb.pphosted.com.
> 10 mxb-00257001.gslb.pphosted.com.
>
> update.strava.com -> strava.com
> 3.227.103.50
> 44.195.56.39
> 52.0.47.160
> 3.217.33.77
> 3.237.58.53
> 34.197.5.198
> 54.209.232.157
> 52.72.119.210
> 30 alt2.aspmx.l.google.com.
> 50 aspmx3.googlemail.com.
> 20 alt1.aspmx.l.google.com.
> 10 aspmx.l.google.com.
> 40 aspmx2.googlemail.com.
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[Alessandro Vesely]

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
mktg.daily-harvest.com
email3.reachmd.com

1 of 10 had DMARC PASS based on SPF alignment only:
mg.homedepot.com

2 of 10 had DMARC PASS based on DKIM only:
info.extraspace.com
update.strava.com



What do you mean by "failed the MX/A test"?  Only doctors-digest.com seems to 
be non-existent under 3.2.6.


ale@pcale:~/tmp$ for d in $doms mg.homedepot.com info.extraspace.com update.strava.com; do 
r=$(get_root_domain $d|sed -rn 's/^ Root Domain: *(.*)$/\1/p'); echo "$d -> 
$r"; dig +short $r; dig +short $r mx; echo; done
bc.qvcemail.com -> qvcemail.com
167.140.19.203
100 smtp2.qvc.com.
100 smtp3.qvc.com.

doctors-digest.com -> doctors-digest.com

email.nutricia-na.com -> nutricia-na.com
52.36.54.191
20 mail3792.nutricianorthamerica.mkt4389.com.
5 bounce.email.nutricia-na.com.
10 reply.email.nutricia-na.com.

mail.foodnetwork.com -> foodnetwork.com
204.78.50.45
100 foodnetwork-com.mail.protection.outlook.com.
1 aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

mail.medscape.org -> medscape.org
104.18.27.226
104.18.26.226
10 alt3.aspmx.l.google.com.
10 reply-mx.s6.exacttarget.com.
1 aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

mktg.daily-harvest.com -> daily-harvest.com
104.18.1.9
104.18.0.9
10 alt4.aspmx.l.google.com.
1 aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.

email3.reachmd.com -> reachmd.com
34.195.222.240
34.233.81.108
10 mx1-us1.ppe-hosted.com.
10 mx2-us1.ppe-hosted.com.

mg.homedepot.com -> homedepot.com
35.201.95.83
20 mx0a-000e6601.pphosted.com.
10 mxb-000e6601.gslb.pphosted.com.
10 mxa-000e6601.gslb.pphosted.com.
20 mx0b-000e6601.pphosted.com.

info.extraspace.com -> extraspace.com
13.107.246.13
10 mxa-00257001.gslb.pphosted.com.
10 mxb-00257001.gslb.pphosted.com.

update.strava.com -> strava.com
3.227.103.50
44.195.56.39
52.0.47.160
3.217.33.77
3.237.58.53
34.197.5.198
54.209.232.157
52.72.119.210
30 alt2.aspmx.l.google.com.
50 aspmx3.googlemail.com.
20 alt1.aspmx.l.google.com.
10 aspmx.l.google.com.
40 aspmx2.googlemail.com.


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

[Douglas Foster]

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, from 10 unique domains, which failed the MX/A
test.  I do not test on  because I do not accept mail using IPv6.

All 10 could produce DMARC PASS based on relaxed alignment, although I have
not evaluated whether they publish a DMARC policy.   I simply evaluate SPF
and DKIM based on relaxed alignment for all incoming messages.

All 10 domains had RFC5321.MailFrom and RFC5322.From domains that were
different.

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
mktg.daily-harvest.com
email3.reachmd.com

1 of 10 had DMARC PASS based on SPF alignment only:
mg.homedepot.com

2 of 10 had DMARC PASS based on DKIM only:
info.extraspace.com
update.strava.com

1 of 10 had an SPF record on the RFC5322.From address.
email.nutricia-na.com

Overall, this suggests to me that ESP messages will have trouble complying
with any NP criteria, and this may force us to use a weaker one, such as
NXDOMAIN only, even though my preference is a strong one.

Doug Foster
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Tim Wicinski]

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
> > > conclusion from those words.
> >
> > Then my mistake.
> >
> > > 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".   I am willing to say that if NP=TRUE produces an accurate
> result,
> > > I
> > > will block the message and I can see no reason why anyone else would do
> > > otherwise.
> > >
> > > DMARC FAIL is an ambiguous result, which was your point.  DMARC PASS is
> > > not ambiguous.   NP=TRUE should be ambiguous if at all possible,
> otherwise
> > > it adds no value.
> > >
> > > But back to the actual topic:
> > > - Do you believe the NP test can be useful?  If so, for what purpose?
> > > - What is the optimal test to evaluate NP?  How did you reach that
> > > conclusion?
> >
> > I see the NP tag being useful for mid to large organizations that have a
> > regular amount of organizational change (mergers, acquisitions, etc).
> > A large mostly static organization will not deploy the np tag, because "p
> > == sp", where the domain tag = the subdomain tag.
> > Larger organizations deploying DMARC usually run into the problem of not
> > knowing all the mail flows from all the change, and they end up
> > with "p != sp" for some period of time.  In these cases, np is really
> > useful in preventing attack vectors using subdomains (log4j.example.com)
> > from
> > being used.
> >
> > I am sure there are folks who track DMARC record changes over time, but
> > back in mid 2020 I pulled a bunch of DMARC records of some alexa top 10K,
> > and noticed the number of domains where "p != sp".  Doing a quick pull of
> > those domains and checking now I see a number of them now show "p == sp",
> > which means they feel they have a better understanding of their mail
> > flows.
> >
> > I worked for a large organization which had to set "p != sp" for a period
> > of time as they understood things better. They are now a "p == sp"
> > organization now, which is good. But having the added bonus of blocking
> > invalid subdomains during that migration period I am sure would have
> > made folks feel better.
> >
> > (the other use case for the np tag is around TLDs and also the SLDs like
> > co.uk, and Scott is all over that).
>
> Actually .gov.uk.  I'd expect that .co.uk has similar challenges to what
> we'd
> expect with .com.


I knew I'd get something wrong.


>
> What you describe is something that was in my mind when we defined np=,
> despite
> the focus on PSD at the time.  I think that np= has potentially broad
> utility
> as a gap filler during the deployment process for large organizations.
>

As an operations person who has worked with a lot of technical debt, when I
saw your idea
for np=, *all* I could think of was large organizational issues.

>
> I think p=reject will be a problem of a lot of organizations for a long
> time,
> so I think anything we can do to make it easier to have some set of mail
> covered by a reject policy is a good thing.
>

Here is a data point on this.  Sometime back in Fall 2020, I was collecting
some DMARC DNS records.
I was using the alexa-top* lists, which are horrible datasets, because
web domains don't always send email
and email domains don't have web properties etc.

Using the top-1000 domains:

1000 domains
 562 domains with DMARC record
 318 domains with DMARC record where p != sp

Rechecking that same list of domains last night:

  371 domains with DMARC record where p != sp

53 domains from this list updated their policies.  I did not dive into the
specifics, but they mostly appear
to have the 'p=' move forward (none->quarantine->reject) while 'sp='
appeared to stay the same.
(I see a few where 'p=' moves to reject and 'sp=' moves to none. I can
figure this out if interested)

To Scotts' point on organizations moving to p=reject will take time, I
would agree.  But allowing a large organization
allow sp=none but np=reject is a huge help.  (This also means organizations
need to cull the DNS data, but some of us
are a bit too obsessive about this)

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Proposal part 2)

[Douglas Foster]

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 owner has never authorized the name for use with
>From addressing.

-  Which produces no false positives after domain owners have taken
necessary compliance measures

-  Which requires a minimum of compliance effort by the domain owner

-  Which minimizes false negatives as much as possible.

The universe of all possible domain names can be partitioned as follows:

-  Names which are used for both SMTP and RFC5322.From.

-  Names which are used for SMTP only, not for RFC5322.From

-  Names which are used for RFC5322.From only, not for SMTP

-  Names which are no used at all for email.

Names used for both SMTP and From

For the first group, assume that this occurs because some outbound messages
have the same domain for RFC5321.MailFrom and RFC5322.From.   How do we
detect names used for RFC5321.MailFrom?

-  SPF is the first indicator, because SPF explicitly affirms that
the domain name is used as a MailFrom address.

-  MX is a secondary indicator, because it explicitly affirms that
the domain name accepts mail.

-  A/ does not explicitly affirm anything about mail usage, but
it may be used for mail without being explicitly identified.   Treating
A/ as equivalent to MX will cause a high number of false negatives,
weakening the effectiveness of the NP test.   So we need to evaluate
whether its inclusion is necessary.

Names used for SMTP only

We currently have no way to detect domain names that are only used for
SMTP.   Unless we add an indicator for this purpose, we are forced to
assume that all SMTP names are also FROM names.   This creates some false
negatives, but we have said that some false negatives are tolerable even
though they are not desirable.

Names used for RFC5322.From only

In the context of DMARC, names that are not used for SMTP Mail should be
protected with a DKIM signature.  Additionally, email is the primary use
case for DKIM signatures, so the existence of a DKIM public key is at least
suggestive that the name is used for email.   DNS does not provide a simple
way to identify all DKIM signatures on a domain name, so we are limited to
checking only those names that are found within DKIM signatures on the
message being evaluated.

If a message has a DKIM signatures, and a public key exists in DNS for the
specified scope, we can reasonably conclude that the domain owner intends
to sign some messages with that signature, and that the most likely domain
name for which it will be used is the exact match name.   Consequently, the
recommended test for this situation is the existence of a DKIM public key
which matches a DKIM signature in the message.   The NP test is only
applicable when the message does not produce DMARC PASS, so the signature
itself has tested as unverified, but the presence of the public key
indicates that the name is used for email sometimes, even if this
particular signature is a forgery.

Of course, a message can be DMARC PASS using relaxed alignment on a DKIM
signature.   This is the reason that an RFC5322.From domain name can be
invisible in DNS.  To allow any unverified signature key to match any
aligned domain name would create too many false negatives.  Domain owners
will need to take compliance action to ensure that names used only for
RFC5322.From are able to comply with the NP test by one of the defined
methods.   To address this need, it seems appropriate to assume that the
existence of an exact-match DMARC policy is also an indicator that the name
is used for RFC5322.From messaging.

Names which are not used for any email purpose

These domain names are identified when all of the other tests have not
produced a match, and these produce NP=TRUE as the result.

Refining the test:  Should A/ be included in the test rule?

The NP test is not applicable to all mail, it is only applicable to domains
that have published a DMARC policy with an NP clause.   Publishing a NP
policy, other than NONE, is an assertion that the domain owner has
voluntarily undertaken compliance with the NP test.   The DMARC policy also
suggests that the domain owner has a general interest in making his
outbound messages DMARC compliant.   The A/ test is needed to avoid
false positives only when:

-  The name is actually used for SMTP mail, and

-  No SPF record has been published, and

-  No MX record has been published.

For domains that are participating in DMARC, the absence of an SPF record
would be surprising, and the absence of both MX and SPF would be even more
surprising.   Treating an implicit MX as if it was an explicit MX
introduces a large number of false positives, si

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Scott Kitterman]

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
> > conclusion from those words.
> 
> Then my mistake.
> 
> > 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".   I am willing to say that if NP=TRUE produces an accurate result,
> > I
> > will block the message and I can see no reason why anyone else would do
> > otherwise.
> > 
> > DMARC FAIL is an ambiguous result, which was your point.  DMARC PASS is
> > not ambiguous.   NP=TRUE should be ambiguous if at all possible, otherwise
> > it adds no value.
> > 
> > But back to the actual topic:
> > - Do you believe the NP test can be useful?  If so, for what purpose?
> > - What is the optimal test to evaluate NP?  How did you reach that
> > conclusion?
> 
> I see the NP tag being useful for mid to large organizations that have a
> regular amount of organizational change (mergers, acquisitions, etc).
> A large mostly static organization will not deploy the np tag, because "p
> == sp", where the domain tag = the subdomain tag.
> Larger organizations deploying DMARC usually run into the problem of not
> knowing all the mail flows from all the change, and they end up
> with "p != sp" for some period of time.  In these cases, np is really
> useful in preventing attack vectors using subdomains (log4j.example.com)
> from
> being used.
> 
> I am sure there are folks who track DMARC record changes over time, but
> back in mid 2020 I pulled a bunch of DMARC records of some alexa top 10K,
> and noticed the number of domains where "p != sp".  Doing a quick pull of
> those domains and checking now I see a number of them now show "p == sp",
> which means they feel they have a better understanding of their mail
> flows.
> 
> I worked for a large organization which had to set "p != sp" for a period
> of time as they understood things better. They are now a "p == sp"
> organization now, which is good. But having the added bonus of blocking
> invalid subdomains during that migration period I am sure would have
> made folks feel better.
> 
> (the other use case for the np tag is around TLDs and also the SLDs like
> co.uk, and Scott is all over that).

Actually .gov.uk.  I'd expect that .co.uk has similar challenges to what we'd 
expect with .com.  

What you describe is something that was in my mind when we defined np=, despite 
the focus on PSD at the time.  I think that np= has potentially broad utility 
as a gap filler during the deployment process for large organizations.

I think p=reject will be a problem of a lot of organizations for a long time, 
so I think anything we can do to make it easier to have some set of mail 
covered by a reject policy is a good thing.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Tim Wicinski]

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 stated domain", and NP=TRUE means "This name cannot
> represent the stated domain because the domain owner never uses that
> name".   I am willing to say that if NP=TRUE produces an accurate result, I
> will block the message and I can see no reason why anyone else would do
> otherwise.
>
> DMARC FAIL is an ambiguous result, which was your point.  DMARC PASS is
> not ambiguous.   NP=TRUE should be ambiguous if at all possible, otherwise
> it adds no value.
>
> But back to the actual topic:
> - Do you believe the NP test can be useful?  If so, for what purpose?
> - What is the optimal test to evaluate NP?  How did you reach that
> conclusion?
>
>
I see the NP tag being useful for mid to large organizations that have a
regular amount of organizational change (mergers, acquisitions, etc).
A large mostly static organization will not deploy the np tag, because "p
== sp", where the domain tag = the subdomain tag.
Larger organizations deploying DMARC usually run into the problem of not
knowing all the mail flows from all the change, and they end up
with "p != sp" for some period of time.  In these cases, np is really
useful in preventing attack vectors using subdomains (log4j.example.com)
from
being used.

I am sure there are folks who track DMARC record changes over time, but
back in mid 2020 I pulled a bunch of DMARC records of some alexa top 10K,
and noticed the number of domains where "p != sp".  Doing a quick pull of
those domains and checking now I see a number of them now show "p == sp",
which means they feel they have a better understanding of their mail
flows.

I worked for a large organization which had to set "p != sp" for a period
of time as they understood things better. They are now a "p == sp"
organization now, which is good. But having the added bonus of blocking
invalid subdomains during that migration period I am sure would have
made folks feel better.

(the other use case for the np tag is around TLDs and also the SLDs like
co.uk, and Scott is all over that).


tim



>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Douglas Foster]

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".   I am willing to say that if NP=TRUE produces an accurate result, I
will block the message and I can see no reason why anyone else would do
otherwise.

DMARC FAIL is an ambiguous result, which was your point.  DMARC PASS is not
ambiguous.   NP=TRUE should be ambiguous if at all possible, otherwise it
adds no value.

But back to the actual topic:
- Do you believe the NP test can be useful?  If so, for what purpose?
- What is the optimal test to evaluate NP?  How did you reach that
conclusion?

Doug

On Fri, Dec 17, 2021 at 6:38 PM Tim Wicinski  wrote:

>
>
> 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 a design appears to be
>> logically consistent, we do data analysis to validate our design.   The
>> criteria for DMARC PASS (the identity is authentic) and NP (the identity
>> cannot be authentic) should be aligned so that they produce results that
>> are not in direct conflict.   We seem to have an obvious design hole, with
>> an obvious solution, which is what I proposed.
>>
>>
> DMARC PASS != "this email is legit"
>
> You are looking for a specific test that an email can go through which
> will turn a crank and at the end of it says "Yes" or "no".
>
> The text in -04 version is pretty clear:
>
>A DMARC pass indicates *only* that the RFC5322 
> .From domain has been
>authenticated for that message.  *Authentication does not carry an
>explicit or implicit value assertion about that message or about the
>Domain Owner. *
>
>
> You read "PASS" as "legit email" while I have always read it as "this 
> variable is true".
>
>
> What the vendors like Agari, Valimail, Proofpoint, et al, is to collect all 
> the variables (SPF, DKIM, DMARC, plus organization specific info) and allow 
> the
>
> organization to tweak as needed.
>
>
> You are looking to solve the problem of legitimate email. DMARC is not trying 
> to solve that.
>
>
> tim
>
>> As to examples, my data set is large enough to be informative but not
>> large enough to be determinative.   I see very little forwarded mail, so my
>> data set is not expected to answer your specific question.   I do see
>> legitimate messages using From domains that are not in DNS.  The existence
>> of legitimate non-DNS names, and the lack of a suitable compliance
>> mechanism for those names, is what got me concerned about this test
>> definition.I have provided the group with examples, as has someone
>> else.   Yet, the test specification has not been modified to address that
>> concern.   How do you think that makes me feel?
>>
>> A year after raising my concerns, I am still trying to get a
>> collaborative discussion started about what the optimal test looks like.
>> In a collaborative discussion, those who are happy with the status quo
>> convince the skeptics to come on board, listen to their concerns,
>> acknowledge them, and do what they can to accommodate those concerns so
>> that consensus can be achieved.I am willing to be convinced, but I am
>> skeptical and I am looking for some collaboration.
>>
>> Doug
>>
>> On Fri, Dec 17, 2021 at 11:00 AM Murray S. Kucherawy 
>> wrote:
>>
>>> 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 modifications, such as the
 ubiquitous "this message received from an external source".   Of course, it
 could be a mailing list modification also.

>>>
>>> Yes, I'm aware of this aspect of message authentication.  That wasn't my
>>> question.
>>>
>>> The point of an NP test was, in my understanding, to identify names that
 were never valid in any circumstance, like 'junk.junk.ietf.com",
 without any dependencies on message path.Why would we want to create a
 duplicate of the mailing list problem?

>>>
>>> I understand the first sentence.  I do not see how the second follows.
>>>
>>> However, if MX/A/ is really the right test for fraudulent
 identifiers, then we need to open a CVE against all implementations of
 RFC7489, because implementations based on that spec have been confidently
 asserting honest identifiers without checking the MX/A/ condition.

>>>
>>> I don't follow this either.
>>>
>>> Why do I need to prov

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Tim Wicinski]

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 a design appears to be
> logically consistent, we do data analysis to validate our design.   The
> criteria for DMARC PASS (the identity is authentic) and NP (the identity
> cannot be authentic) should be aligned so that they produce results that
> are not in direct conflict.   We seem to have an obvious design hole, with
> an obvious solution, which is what I proposed.
>
>
DMARC PASS != "this email is legit"

You are looking for a specific test that an email can go through which will
turn a crank and at the end of it says "Yes" or "no".

The text in -04 version is pretty clear:

   A DMARC pass indicates *only* that the RFC5322
.From domain has been
   authenticated for that message.  *Authentication does not carry an
   explicit or implicit value assertion about that message or about the
   Domain Owner. *


You read "PASS" as "legit email" while I have always read it as "this
variable is true".


What the vendors like Agari, Valimail, Proofpoint, et al, is to
collect all the variables (SPF, DKIM, DMARC, plus organization
specific info) and allow the

organization to tweak as needed.


You are looking to solve the problem of legitimate email. DMARC is not
trying to solve that.


tim

> As to examples, my data set is large enough to be informative but not
> large enough to be determinative.   I see very little forwarded mail, so my
> data set is not expected to answer your specific question.   I do see
> legitimate messages using From domains that are not in DNS.  The existence
> of legitimate non-DNS names, and the lack of a suitable compliance
> mechanism for those names, is what got me concerned about this test
> definition.I have provided the group with examples, as has someone
> else.   Yet, the test specification has not been modified to address that
> concern.   How do you think that makes me feel?
>
> A year after raising my concerns, I am still trying to get a collaborative
> discussion started about what the optimal test looks like.  In a
> collaborative discussion, those who are happy with the status quo convince
> the skeptics to come on board, listen to their concerns, acknowledge them,
> and do what they can to accommodate those concerns so that consensus can be
> achieved.I am willing to be convinced, but I am skeptical and I am
> looking for some collaboration.
>
> Doug
>
> On Fri, Dec 17, 2021 at 11:00 AM Murray S. Kucherawy 
> wrote:
>
>> 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 modifications, such as the
>>> ubiquitous "this message received from an external source".   Of course, it
>>> could be a mailing list modification also.
>>>
>>
>> Yes, I'm aware of this aspect of message authentication.  That wasn't my
>> question.
>>
>> The point of an NP test was, in my understanding, to identify names that
>>> were never valid in any circumstance, like 'junk.junk.ietf.com",
>>> without any dependencies on message path.Why would we want to create a
>>> duplicate of the mailing list problem?
>>>
>>
>> I understand the first sentence.  I do not see how the second follows.
>>
>> However, if MX/A/ is really the right test for fraudulent
>>> identifiers, then we need to open a CVE against all implementations of
>>> RFC7489, because implementations based on that spec have been confidently
>>> asserting honest identifiers without checking the MX/A/ condition.
>>>
>>
>> I don't follow this either.
>>
>> Why do I need to provide case studies?Isn't the burden of proof on
>>> the team that told us that MX/A/AAA was absolutely the best possible test
>>> to use?
>>>
>>
>> Because I'm trying to understand your concern.  Sure, it's reasonable for
>> us to question our assumptions.  But if I don't understand how you get your
>> premises, or how your premises lead to your conclusions, am I being
>> unreasonable when I ask for clarification or concrete examples?
>>
>> -MSK
>>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Douglas Foster]

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
criteria for DMARC PASS (the identity is authentic) and NP (the identity
cannot be authentic) should be aligned so that they produce results that
are not in direct conflict.   We seem to have an obvious design hole, with
an obvious solution, which is what I proposed.

As to examples, my data set is large enough to be informative but not large
enough to be determinative.   I see very little forwarded mail, so my data
set is not expected to answer your specific question.   I do see legitimate
messages using From domains that are not in DNS.  The existence of
legitimate non-DNS names, and the lack of a suitable compliance mechanism
for those names, is what got me concerned about this test definition.I
have provided the group with examples, as has someone else.   Yet, the test
specification has not been modified to address that concern.   How do you
think that makes me feel?

A year after raising my concerns, I am still trying to get a collaborative
discussion started about what the optimal test looks like.  In a
collaborative discussion, those who are happy with the status quo convince
the skeptics to come on board, listen to their concerns, acknowledge them,
and do what they can to accommodate those concerns so that consensus can be
achieved.I am willing to be convinced, but I am skeptical and I am
looking for some collaboration.

Doug

On Fri, Dec 17, 2021 at 11:00 AM Murray S. Kucherawy 
wrote:

> 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 modifications, such as the
>> ubiquitous "this message received from an external source".   Of course, it
>> could be a mailing list modification also.
>>
>
> Yes, I'm aware of this aspect of message authentication.  That wasn't my
> question.
>
> The point of an NP test was, in my understanding, to identify names that
>> were never valid in any circumstance, like 'junk.junk.ietf.com", without
>> any dependencies on message path.Why would we want to create a
>> duplicate of the mailing list problem?
>>
>
> I understand the first sentence.  I do not see how the second follows.
>
> However, if MX/A/ is really the right test for fraudulent identifiers,
>> then we need to open a CVE against all implementations of RFC7489, because
>> implementations based on that spec have been confidently asserting honest
>> identifiers without checking the MX/A/ condition.
>>
>
> I don't follow this either.
>
> Why do I need to provide case studies?Isn't the burden of proof on the
>> team that told us that MX/A/AAA was absolutely the best possible test to
>> use?
>>
>
> Because I'm trying to understand your concern.  Sure, it's reasonable for
> us to question our assumptions.  But if I don't understand how you get your
> premises, or how your premises lead to your conclusions, am I being
> unreasonable when I ask for clarification or concrete examples?
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Alessandro Vesely]

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 interpretations in a manner that
does not exist in the standard.


Thank you Michael, for reminding me of this.DMARC provides a result
based on a collection of tests, and it is up to the receiver of the email
whether they choose to accept the email or to reject it.



Yet, honesty and legitimacy are somewhat similar, and we do foremost consider 
the latter aspect:


   DMARC is designed to prevent bad actors from sending mail that claims
   to come from legitimate senders, particularly senders of
   transactional email (official mail that is about business
   transactions).

Of course, if the From: domain doesn't exist at all, it cannot have a DMARC 
record.  However, according to the formal definition of Section 3.6.2, a 
non-existing domain can pass all DMARC tests.  IMHO, that is a gray area which, 
together with the null MX case, deserves being mentioned somewhere, in the same 
section, in Security Considerations or in an appendix.


Another difficulty of this subject might lay in the distinction between 
non-existing addresses and non-existing domains.  The SPF side of DMARC 
conflates those concept; and indeed "call" tests —part of other legitimacy 
assessments— are usually performed of the envelope address.  No-reply From: 
addresses have now become part of everyday life, but AFAIUI some hold that 
non-existent From: domains are legit too.  Does that such concern touch the 
question too?



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Tim Wicinski]

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 exist in the standard.
>
>
Thank you Michael, for reminding me of this.DMARC provides a result
based on a collection of tests, and it is up to the receiver of the email
whether they choose to accept the email or to reject it.

tim
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Dotzero]

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 DMARC PASS, the
> RFC5322.From address is confidently judged to be "Honestly identified"
>  DMARC checks SPF and DKIM, but not MX or A/.
>
> But then it is forwarded and loses its credentials during forwarding.
>
> On reception, because of DMARC FAIL, it is tested against NP.NP checks
> MX and A/ but does not check SPF or DKIM.   The message fails this test
> and is confidently judged to be "Fraudulently identified".
>
> Which is true?   Was the message From address always fraudulent or always
> honest?
>
>


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 exist in the standard.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Murray S. Kucherawy]

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 modifications, such as the ubiquitous
> "this message received from an external source".   Of course, it could be a
> mailing list modification also.
>

Yes, I'm aware of this aspect of message authentication.  That wasn't my
question.

The point of an NP test was, in my understanding, to identify names that
> were never valid in any circumstance, like 'junk.junk.ietf.com", without
> any dependencies on message path.Why would we want to create a
> duplicate of the mailing list problem?
>

I understand the first sentence.  I do not see how the second follows.

However, if MX/A/ is really the right test for fraudulent identifiers,
> then we need to open a CVE against all implementations of RFC7489, because
> implementations based on that spec have been confidently asserting honest
> identifiers without checking the MX/A/ condition.
>

I don't follow this either.

Why do I need to provide case studies?Isn't the burden of proof on the
> team that told us that MX/A/AAA was absolutely the best possible test to
> use?
>

Because I'm trying to understand your concern.  Sure, it's reasonable for
us to question our assumptions.  But if I don't understand how you get your
premises, or how your premises lead to your conclusions, am I being
unreasonable when I ask for clarification or concrete examples?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Douglas Foster]

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
mailing list modification also.

The point of an NP test was, in my understanding, to identify names that
were never valid in any circumstance, like 'junk.junk.ietf.com", without
any dependencies on message path.Why would we want to create a
duplicate of the mailing list problem?

However, if MX/A/ is really the right test for fraudulent identifiers,
then we need to open a CVE against all implementations of RFC7489, because
implementations based on that spec have been confidently asserting honest
identifiers without checking the MX/A/ condition.

Why do I need to provide case studies?Isn't the burden of proof on the
team that told us that MX/A/AAA was absolutely the best possible test to
use?



On Thu, Dec 16, 2021 at 1:46 AM Murray S. Kucherawy 
wrote:

> 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 DMARC PASS, the
>> RFC5322.From address is confidently judged to be "Honestly identified"
>>  DMARC checks SPF and DKIM, but not MX or A/.
>>
>> But then it is forwarded and loses its credentials during forwarding.
>>
>> On reception, because of DMARC FAIL, it is tested against NP.NP
>> checks MX and A/ but does not check SPF or DKIM.   The message fails
>> this test and is confidently judged to be "Fraudulently identified".
>>
>
> The nearest thing I can imagine that would cause this is a From of "
> f...@example.com" when that domain advertises a public key that verifies
> the message, so it has a TXT at "selector._domainkey.example.com", but
> has no MX, A, or  for "example.com".  On relay, a mutation causes the
> signature validation to fail at the final recipient.
>
> Are you seeing cases like this?
>
> -MSK
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Murray S. Kucherawy]

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 DMARC PASS, the
> RFC5322.From address is confidently judged to be "Honestly identified"
>  DMARC checks SPF and DKIM, but not MX or A/.
>
> But then it is forwarded and loses its credentials during forwarding.
>
> On reception, because of DMARC FAIL, it is tested against NP.NP checks
> MX and A/ but does not check SPF or DKIM.   The message fails this test
> and is confidently judged to be "Fraudulently identified".
>

The nearest thing I can imagine that would cause this is a From of "
f...@example.com" when that domain advertises a public key that verifies the
message, so it has a TXT at "selector._domainkey.example.com", but has no
MX, A, or  for "example.com".  On relay, a mutation causes the
signature validation to fail at the final recipient.

Are you seeing cases like this?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Tim Wicinski]

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 DMARC PASS, the
> RFC5322.From address is confidently judged to be "Honestly identified"
>  DMARC checks SPF and DKIM, but not MX or A/.
>
> But then it is forwarded and loses its credentials during forwarding.
>

It sounds like you're rewriting the message header and sending it back out,
like a mailing list would do.
It's two different mail sessions.

This problem space is what ARC attempts to solve.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Douglas Foster]

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 and DKIM, but not MX or A/.

But then it is forwarded and loses its credentials during forwarding.

On reception, because of DMARC FAIL, it is tested against NP.NP checks
MX and A/ but does not check SPF or DKIM.   The message fails this test
and is confidently judged to be "Fraudulently identified".

Which is true?   Was the message From address always fraudulent or always
honest?

To produce consistent results, do we change DMARC to require messages to
evaluate MX/A/ or do we change NP to integrate SPF and DKIM?

Doug


On Wed, Dec 15, 2021 at 6:50 PM Scott Kitterman 
wrote:

> 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 to say that we shouldn't listen to
> > you.
> >
> > > 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 is not sufficiently defined.
> >
> > It *is* reasonable to expect you to review earlier discussions, rather
> > than to ask the working group to revisit them without a sense of how
> > you're adding new information.
>
> Thanks.  Yes, that was my intent.
>
> To give a short summary, in the interests of moving forward:
>
> The domain owner publishing the DMARC record knows and controls what
> exists
> and what doesn't.  They don't have to guess.  The question was,
> particularly
> in the context of PSD, but not exclusively, would record publishers find
> it
> useful to be able to publish a different (and presumably more strict)
> policy
> for non-existent domains.  More p=reject equals more bad stuff not getting
> delivered.
>
> I think we can say it's an pretty unqualified yes in the PSD realm:
>
> $ dig +short txt _dmarc.gov
> "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:
> dotgov_dm...@cisa.dhs.gov"
>
> $ dig +short txt _dmarc.mil
> "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc_repo...@mail.mil
> "
>
> $ dig +short txt _dmarc.gov.uk
> "v=DMARC1;p=reject;sp=none;np=reject;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-
> r...@dmarc.service.gov.uk"
>
> $ dig +short txt _dmarc.police.uk
> "v=DMARC1;p=none;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-
> r...@dmarc.service.gov.uk;ruf=mailto:dmarc-...@dmarc.service.gov.uk";
>
> All of the current PSDs that have published records with any policy other
> than
> none have different sp= and np= policies.
>
> Scott K
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Scott Kitterman]

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 least 
as much work as the technical piece.  I don't have any internal insight, but 
given they're new to the game I'm not surprised they are in data collection 
mode.

Scott K

On Wednesday, December 15, 2021 7:27:15 PM EST Tim Wicinski wrote:
> 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, 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 to say that we shouldn't listen to
> > > you.
> > > 
> > > > 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 is not sufficiently defined.
> > > 
> > > It *is* reasonable to expect you to review earlier discussions, rather
> > > than to ask the working group to revisit them without a sense of how
> > > you're adding new information.
> > 
> > Thanks.  Yes, that was my intent.
> > 
> > To give a short summary, in the interests of moving forward:
> > 
> > The domain owner publishing the DMARC record knows and controls what
> > exists
> > and what doesn't.  They don't have to guess.  The question was,
> > particularly
> > in the context of PSD, but not exclusively, would record publishers find
> > it
> > useful to be able to publish a different (and presumably more strict)
> > policy
> > for non-existent domains.  More p=reject equals more bad stuff not getting
> > delivered.
> > 
> > I think we can say it's an pretty unqualified yes in the PSD realm:
> > 
> > $ dig +short txt _dmarc.gov
> > "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:
> > dotgov_dm...@cisa.dhs.gov"
> > 
> > $ dig +short txt _dmarc.mil
> > "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc_repo...@mail.mil
> > "
> > 
> > $ dig +short txt _dmarc.gov.uk
> > "v=DMARC1;p=reject;sp=none;np=reject;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-
> > r...@dmarc.service.gov.uk"
> > 
> > $ dig +short txt _dmarc.police.uk
> > "v=DMARC1;p=none;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-
> > r...@dmarc.service.gov.uk;ruf=mailto:dmarc-...@dmarc.service.gov.uk";
> > 
> > All of the current PSDs that have published records with any policy other
> > than
> > none have different sp= and np= policies.
> > 
> > Scott K
> > 
> > 
> > ___
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Tim Wicinski]

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, 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 to say that we shouldn't listen to
> > you.
> >
> > > 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 is not sufficiently defined.
> >
> > It *is* reasonable to expect you to review earlier discussions, rather
> > than to ask the working group to revisit them without a sense of how
> > you're adding new information.
>
> Thanks.  Yes, that was my intent.
>
> To give a short summary, in the interests of moving forward:
>
> The domain owner publishing the DMARC record knows and controls what
> exists
> and what doesn't.  They don't have to guess.  The question was,
> particularly
> in the context of PSD, but not exclusively, would record publishers find
> it
> useful to be able to publish a different (and presumably more strict)
> policy
> for non-existent domains.  More p=reject equals more bad stuff not getting
> delivered.
>
> I think we can say it's an pretty unqualified yes in the PSD realm:
>
> $ dig +short txt _dmarc.gov
> "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:
> dotgov_dm...@cisa.dhs.gov"
>
> $ dig +short txt _dmarc.mil
> "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc_repo...@mail.mil
> "
>
> $ dig +short txt _dmarc.gov.uk
> "v=DMARC1;p=reject;sp=none;np=reject;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-
> r...@dmarc.service.gov.uk"
>
> $ dig +short txt _dmarc.police.uk
> "v=DMARC1;p=none;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-
> r...@dmarc.service.gov.uk;ruf=mailto:dmarc-...@dmarc.service.gov.uk";
>
> All of the current PSDs that have published records with any policy other
> than
> none have different sp= and np= policies.
>
> Scott K
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Scott Kitterman]

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 to say that we shouldn't listen to
> you.
> 
> > 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 is not sufficiently defined.
> 
> It *is* reasonable to expect you to review earlier discussions, rather
> than to ask the working group to revisit them without a sense of how
> you're adding new information.

Thanks.  Yes, that was my intent.

To give a short summary, in the interests of moving forward:

The domain owner publishing the DMARC record knows and controls what exists 
and what doesn't.  They don't have to guess.  The question was, particularly 
in the context of PSD, but not exclusively, would record publishers find it 
useful to be able to publish a different (and presumably more strict) policy 
for non-existent domains.  More p=reject equals more bad stuff not getting 
delivered.

I think we can say it's an pretty unqualified yes in the PSD realm:

$ dig +short txt _dmarc.gov
"v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dotgov_dm...@cisa.dhs.gov";

$ dig +short txt _dmarc.mil
"v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc_repo...@mail.mil";

$ dig +short txt _dmarc.gov.uk
"v=DMARC1;p=reject;sp=none;np=reject;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-
r...@dmarc.service.gov.uk"

$ dig +short txt _dmarc.police.uk
"v=DMARC1;p=none;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:dmarc-
r...@dmarc.service.gov.uk;ruf=mailto:dmarc-...@dmarc.service.gov.uk";

All of the current PSDs that have published records with any policy other than 
none have different sp= and np= policies.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Barry Leiba]

> 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 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 is not sufficiently
> defined.

It *is* reasonable to expect you to review earlier discussions, rather
than to ask the working group to revisit them without a sense of how
you're adding new information.

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Douglas Foster]

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 is not sufficiently defined.

However, I do understand that your original case was to control misuse of
unregistered organization domains.   I have asked repeatedly for an
explanation of why the PSD team believes that MX/A/ is the optimal
algorithm for that problem, since that information was not in your RFC.  I
am still waiting.   If the topic had been thoroughly vetted in the
committee, this should not have been a difficult request.

Nonetheless, this WG is not re-documenting the PSD experiment, we are
generalizing it to all DMARC policies.   I consider NP to be the most
important part of this document, because it is significant new
functionality to protect recipients and name owners.   But because we are
adding it during the standards track phase, we have to get it right on the
first try.   The only way to get it right is to analyze it thoroughly,
which I have been trying to do, with little cooperation, for about a year.

Once we have the correct algorithm for the general case, we can return to
the PSD case to determine if it requires special handling.  My current
opinion is that the optimal rule will work well for all cases.

As you probably suspect, I think the PSD group messed up on the most
important part of its tasking.   Either prove me wrong or let me help you
improve what you started.

Doug Foster



On Tue, Dec 14, 2021 at 11:40 PM Scott Kitterman 
wrote:

>
>
> On December 15, 2021 4:16:13 AM UTC, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> 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 let's make it clear:
> >
> >A failed MX/A/ test is a very reliable indicator that the From address
> >does not have a mailbox, because the associated domain does not have a
> mail
> >server which accepts messages.  “Does not exist” means that the message
> >does not exist as a destination mailbox.
> >
> >But is that result information useful, and if so, how?   What problem does
> >it resolve?
> >
> >I estimate that 70% of the legitimate mail entering my organization is
> >unidirectional – messages which do not expect a reply by email.
> >Unidirectional traffic does not require an inbox.  When we determine that
> a
> >message does not have an inbox, we determine that it is definitely part of
> >the 70%.   I don't find anything actionable in that information.
> >
> >The RFC5322.From identifier is an abstraction which represents a message
> >stream from a single entity acting as author.   Everything that the author
> >mails can be done through agents, where the agent is the  SMTP From
> >address.  A review of actual mail messages will show that legitimate
> >messages come from domains that do not have a mail server.
> >
> >In the general case, an author account or domain exists simply because the
> >domain owner (or PSD) authorizes someone or something to use that name.
> >Our goal needs to be a test which identifies domain names which have never
> >been authorized by the domain owner or PSD.   We need a different test.
>
> None of that is at all related to why we added the np= tag.  I'd suggest a
> review of the WG archives might be useful.
>
> Scott K
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

[Scott Kitterman]

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 let's make it clear:
>
>A failed MX/A/ test is a very reliable indicator that the From address
>does not have a mailbox, because the associated domain does not have a mail
>server which accepts messages.  “Does not exist” means that the message
>does not exist as a destination mailbox.
>
>But is that result information useful, and if so, how?   What problem does
>it resolve?
>
>I estimate that 70% of the legitimate mail entering my organization is
>unidirectional – messages which do not expect a reply by email.
>Unidirectional traffic does not require an inbox.  When we determine that a
>message does not have an inbox, we determine that it is definitely part of
>the 70%.   I don't find anything actionable in that information.
>
>The RFC5322.From identifier is an abstraction which represents a message
>stream from a single entity acting as author.   Everything that the author
>mails can be done through agents, where the agent is the  SMTP From
>address.  A review of actual mail messages will show that legitimate
>messages come from domains that do not have a mail server.
>
>In the general case, an author account or domain exists simply because the
>domain owner (or PSD) authorizes someone or something to use that name.
>Our goal needs to be a test which identifies domain names which have never
>been authorized by the domain owner or PSD.   We need a different test.

None of that is at all related to why we added the np= tag.  I'd suggest a 
review of the WG archives might be useful.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] 3.2.6 The meaning of non-existence

[Douglas Foster]

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 indicator that the From address
does not have a mailbox, because the associated domain does not have a mail
server which accepts messages.  “Does not exist” means that the message
does not exist as a destination mailbox.

But is that result information useful, and if so, how?   What problem does
it resolve?

I estimate that 70% of the legitimate mail entering my organization is
unidirectional – messages which do not expect a reply by email.
Unidirectional traffic does not require an inbox.  When we determine that a
message does not have an inbox, we determine that it is definitely part of
the 70%.   I don't find anything actionable in that information.

The RFC5322.From identifier is an abstraction which represents a message
stream from a single entity acting as author.   Everything that the author
mails can be done through agents, where the agent is the  SMTP From
address.  A review of actual mail messages will show that legitimate
messages come from domains that do not have a mail server.

In the general case, an author account or domain exists simply because the
domain owner (or PSD) authorizes someone or something to use that name.
Our goal needs to be a test which identifies domain names which have never
been authorized by the domain owner or PSD.   We need a different test.

Doug Foster
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc