Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[Douglas Foster]

This is a useful point for discussion.

MX checks are a valid tool for assessing SMTP MailFrom addresses, since the
sender is supposed to be ready to accept non-delivery reports and other
automated messages.   Of course, this has applicability if (but only if)
the RFC5322.From domain is the same as the RFC5321.MailFrom domain. As far
as I know, DMARC is the only established tool for evaluating the
RFC5322.From address when it differs from the RFC5321.MailFrom address.  So
to my thinking, the NP test is new territory without precedent.

I am looking for a test that says decisively, "The domain owner has never
authorized the use of this name for any mail-related purposes." There
are many reasons why an acceptable message may fail DMARC verification.
 One of those reasons is that the message is an impersonation, but the
impersonation is acceptable, typically because it is sent for the benefit
of an account user.   But acceptable messages will always use a domain name
that is already in use by the domain owner, never one that they invented.
  The use of a never-authorized name will always be an unacceptable form of
impersonation, and should be blocked.   I thought that the whole WG had
consensus on this point.

The question then becomes, "How do we construct a decisive test?"   We need
a test that has very little possibility of a false positive that would
cause a message to be blocked.   My primary target is the educational
segment, where everyone assumes that they will always use P/SP=NONE.
because they never want their legitimate messages, including mailing list
messages to be blocked.   They should be willing to use NP=Reject if they
are confident that NP will never block a legitimate message.

A weak algorithm is acceptable if it blocks some but not all messages from
never-used domains;   false negatives are undesirable but tolerable.   A
result of DMARC FAIL with NP=FALSE will leave the evaluator in the same
risk posture as if the NP test had not been performed.

The only method we have for evaluating NP is the DNS, so the weakest
possible rule is to block on NXDOMAIN.   Unfortunately, even that test
returns false positives.   They occurs when messages sent by email service
providers use the provider's SMTP address, and this is the norm.  For these
mailings, the only constraints on the RFC5322.From address are the ones
imposed by the provider (you will not impersonate my other clients) and by
the client itself (via DMARC).   With relaxed alignment, the client can
invent and use domain names that are not in DNS.Consequently, any NP
test will likely require a participating organization to implement some
compliance measures, such as creating DNS entries for those that do not
exist at present.   Those measures should be as simple and error-free as
possible, or the risk-averse organization will simply not participate.

To implement the NP tests, we devise DNS queries which indicate that the
name exists.   When a DATA result is not obtained by any of those queries,
we return NP=TRUE.To minimize false positives, we want to use an
expansive set of DNS queries.   MX+A+ gives one set of in-use names.
 Adding SPF will add another set of in-use names.   Adding exact-match
DMARC and DKIM will add another set of in-use names.  The only reason to
omit these tests is if you can demonstrate that one of them is always
superfluous because it will only include names obtained from other sources,
or because it misleads.

A+ may belong because it adds to the inclusive list, but it weakens the
rule a lot.  So I ask whether an acceptable result can be produced without
it, a direct challenge to my previous sentence.   This is a tricky one, and
best left for another stage in the analysis.

Doug

On Fri, Dec 17, 2021 at 7:01 PM Scott Kitterman 
wrote:

>
>
> On December 17, 2021 11:26:38 PM UTC, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> ..
> >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.
> >
> It may be that this is a cultural issue then.  In the IETF, where there is
> an established consensus (rough or not), the burden is on those seeking to
> overturn the consensus to convince people.  If you think about it, if a
> working group were obligated to rehash things whenever new people show up,
> it would be difficult to accomplish anything in an open environment where
> new people can show up anytime.
>
> I suspect you might have more luck if you first consulted Chesterton's
> Fence.  I think you'd have more luck with questions about why things are
> the way 

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

[dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

[Scott Kitterman]

On December 17, 2021 11:26:38 PM UTC, Douglas Foster 
 wrote:
..
>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.
>
It may be that this is a cultural issue then.  In the IETF, where there is an 
established consensus (rough or not), the burden is on those seeking to 
overturn the consensus to convince people.  If you think about it, if a working 
group were obligated to rehash things whenever new people show up, it would be 
difficult to accomplish anything in an open environment where new people can 
show up anytime.

I suspect you might have more luck if you first consulted Chesterton's Fence.  
I think you'd have more luck with questions about why things are the way they 
are than immediate assertions that they are wrong.

Scott K

P.S. At least as I understand it.  I'm relatively new too.

___
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 lack of meaning of non-existence

[John Levine]

It appears that Alessandro Vesely   said:
>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. ...

DMARC lets a domain owner say "if mail with my name on it doesn't have
these features, it's not from me." The org domain hack lets it say
similar things about its subdomains which may or may not exist.

But other than that, domains that do not exist do not have DMARC policies,
and DMARC has nothing to say about them.  Please stop trying to make it
into a FUSSP.

There are good reasons that a mail system might refuse mail from domains
that don't have an MX, A, or , but they have notthing to do with DMARC.

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

[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