Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

My expectations of what is feasible have collapsed greatly.  My numbers
were unique domains.

I was hoping that the boundary between existent and non-existent would
align along a natural boundary, and as a result would require little or no
effort for domain owners to ensure that their legitimate mail was in the
"existent" category.   If so, the NP=reject policy could be deployed
early.  Instead, it seems that ensuring "existence" becomes just another
burden on the DMARC implementation process, and N{=reject will be the final
step in the deploymnent process.

Because we do not have a natural boundary, we need to create a signalling
system to define the SP/NP boundary.  The signal must be purposefully
implemented by the domain owner, so any signalling system could be chosen.
MX/A/ has an obvious advantage, because pre-existing compliance rates
are high.   But when MX/A/AAA records do not exist, they do not exist
because an ESP-based mail source does not need them.   Any invented
MX/A/AAA record will need an IP address, but the choice of IP address
becomes arbitrary and possibly problematic.   MX, A, , and SPF are all
used to communicate meaning into the SMTP context, so we may have
unexpected consequences from adding one of those records where they are not
needed.

Consequently, I think the search list should be MX/A/AAA/TXT.   The
TXT record content seems unimportant, and it could be as simple as
TXT="This Domain Exists".The domain owner simply needs a way to provide
an "existent" signal without affecting other functions.  TXT seems like the
appropriate way to do this.

Doug Foster









On Tue, May 25, 2021 at 3:39 PM Murray S. Kucherawy 
wrote:

> On Sun, May 23, 2021 at 12:25 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> [...]
>> 145 of 169 (86%) of non-verified domains had MX or A records,
>> Of the 24 without MX or A records, 23 were spam and 1 was legitimate
>> For 20 of the 24 , SPF on the From address returned NXDomain and were
>> obvious spam without checking NS
>> All of the remaining 4 domains had NS records
>>
>
> I believe this means that for 2.4% of the non-verified domains, or 0.65%
> of the total domains, the proposed NS check yielded useful signal beyond
> the standard checking of MX/A/.
>
> One surprise for me:
>> NS lookup on email3.reachmd.com returns NXDomain, but NS lookup on
>> sg.email3.reachmd.com returns NS data.
>> I thought that the existence of a subdomain would be sufficient for a
>> domain to return NS data.
>>
>
> Right, it isn't.
>
> Summary:
>> - MX/A produced 11 false positives
>>
>
> Is that 11 false positive messages, or 11 false positive unique domains?
> If the former, we're talking about around 0.3%.  If the latter, we're
> talking about 1.8%.
>
> So based on the data you collected, what conclusion are you proposing?
>
> -MSK
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Sun, May 23, 2021 at 12:25 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> [...]
> 145 of 169 (86%) of non-verified domains had MX or A records,
> Of the 24 without MX or A records, 23 were spam and 1 was legitimate
> For 20 of the 24 , SPF on the From address returned NXDomain and were
> obvious spam without checking NS
> All of the remaining 4 domains had NS records
>

I believe this means that for 2.4% of the non-verified domains, or 0.65% of
the total domains, the proposed NS check yielded useful signal beyond the
standard checking of MX/A/.

One surprise for me:
> NS lookup on email3.reachmd.com returns NXDomain, but NS lookup on
> sg.email3.reachmd.com returns NS data.
> I thought that the existence of a subdomain would be sufficient for a
> domain to return NS data.
>

Right, it isn't.

Summary:
> - MX/A produced 11 false positives
>

Is that 11 false positive messages, or 11 false positive unique domains?
If the former, we're talking about around 0.3%.  If the latter, we're
talking about 1.8%.

So based on the data you collected, what conclusion are you proposing?

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

Murray, here is some data:   (I only receive IP4 data and my tool did not
check )

Sample size:
 3643 messages from 780 unique From domains
  611 domains (78%) passed validation using DMARC criteria  (DMARC policies
were not checked)

599 of 611 (98%) DMARC-verified domains also had MX or A records
12 DMARC-verified domains did not have MX or A records.  Of these 12:
- 8 had NS records and were judged legitimate,
- 2 lacked NS records but were judged legitimate
- 2 were judged spam but had NS records.

145 of 169 (86%) of non-verified domains had MX or A records,
Of the 24 without MX or A records, 23 were spam and 1 was legitimate
For 20 of the 24 , SPF on the From address returned NXDomain and were
obvious spam without checking NS
All of the remaining 4 domains had NS records

One surprise for me:
NS lookup on email3.reachmd.com returns NXDomain, but NS lookup on
sg.email3.reachmd.com returns NS data.
I thought that the existence of a subdomain would be sufficient for a
domain to return NS data.

Summary:
- MX/A produced 11 false positives
- NS lookup produced only 3 false positives
- For messages that originate with DMARC-compliance, false positives only
matter if the message path causes the DMARC-validation to be lost.
- The reachmd.com situation suggests that neither lookup can prevent all
false positives.

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

It all depends on what problem this is trying to solve, Murray.

"Name exists", as defined by NS data/nxdomain, provides a clear and simple
boundary between names that are in use and names that are not in use.
This is based on the principle that when a name is created in DNS, the
domain administrator has the opportunity to protect it with SPF and DMARC
policies if desired.   A name that has never been used for any purpose
cannot be protected, except with SP=reject, because all other defenses make
the name used, and the scope of possible names is infinite.   The purpose
of the NP test is to allow domain owners to deploy NP=reject early in the
DMARC process, long before they are willing to deploy SP=reject.

I do not see that MX/A/AAA creates a useful and well-defined boundary
between two risk categories, which is why I asked for a justification from
someone who did understand the theoretical foundation.   What I hear is
that nobody knows with any certainty how this test relates to a real-world
boundary problem.

As best I can tell, thd MX/A/ test is creating and attempting to
enforce a rule that "any mail domain used in a FROM address must also have
a physical server for receiving messages to that mail domain."   I do not
see that such a requirement is either necessary or appropriate, and I do
not believe that it will be true that 100% of all legitimate messages will
meet this requirement.

As for filtering characteristics of the two tests:

   - If MX/A/ produces pass and SP, then the NS test will also produce
   pass and SP.

   - If NS produces fail and NP, then the MX/A/AAA test will also produce
   fail and NP

   - There is a bunch of stuff in the middle where NS produces a pass
   because the name is used, but MX/A/AAA produces fail because the required
   types of RR types are not used.If the middle area could be scored
   reliably, it would exclude some additional threat vectors, but I don't see
   reliability.   The A/ test is so broad that it will allow many names
   that are not actually mail servers, allowing the attempted enforcement to
   be easily defeated.I expect it will also produce false positives, as
   the volume of no-reply messages from ESPs is large, and such messages
   simply do not need an MX for the FROM domain.   As I tried to observe in
   the previous note, the MX/A/ test could score "host1.div1.example.com"
   as exists/SP, but "div1.example.com" as does-not-exist/NP.I just
   don't see any value in that level of scrutiny.

In short, MX/A/AAA involves more complexity for less usable results.  That
is a big double negative for me.

We have no data submitted on either test rule, so it is not yet a
distinguishing characteristic.   I think I can build filters to
begin collecting that data, but my data set is relatively small.

Doug Foster


On Tue, May 18, 2021 at 2:19 AM Murray S. Kucherawy 
wrote:

> On Mon, May 17, 2021 at 10:19 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Fatal flaws with the MX/A/ test
>>
>>- During DMARC policy evaluation, the process may have retrieved an
>>SPF policy or a DKIM public key which is associated with the RFC5322.From
>>domain or one of its descendants, even though the SPF test did not pass 
>> and
>>any relevant DKIM tests did not verify.   Obtaining such data provides
>>evidence that the domain name is in use by the domain owner and therefore
>>the failure should be handled as SP rather than NP.   But adding this
>>condition into the evaluation means that the evaluation is no longer
>>deterministic, since the pool of supplementary information can vary from
>>one message to the next..
>>
>>
> In what way does the SPF and DKIM information fetched for one message
> taint the resolution of the message coming after it from the same domain?
>
>
>>
>>- If the RFC5321.MailFrom domain is a parent of, or unrelated to, the
>>RFC5322.From domain,. then the DMARC evaluation will not have checked for
>>an SPF policy on the From domain.   The presence of an SPF policy 
>> indicates
>>that the domain does exist and that the domain owner has implemented this
>>sender authentication mechanism.If SPF is present, the policy
>>evaluation should be SP, not NP, but the SPF policy is not considered by
>>the MX/A/ rule.
>>
>> The same is true for an unaligned DKIM signature.
>
> To me, this just means trying to piggyback the MX/A/ semantics off of
> the presence of DKIM and SPF results is fallible.
>
> Problematic ambiguity, depending on the presumed justification for the
>> MX/A/ test
>>
>>- Both MX and SPF can be used to allow or block traffic.   MX can
>>block message delivery using a host name of "." (RFC 7505) or any other
>>invalid or non-routable name.   SPF can be used to block traffic if the
>>policy is "-ALL".   If the selection of MX is intended to score the domain
>>for a probability that it is used

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

Then please explain yourself, John.




On Tue, May 18, 2021 at 12:28 PM John Levine  wrote:

> It appears that Murray S. Kucherawy   said:
> >-=-=-=-=-=-
> > [ various things ]
>
> I have reread this ticket and found nothing actionable, and a lot of
> misconceptions aboout how the DNS works.
>
> There is nothing to fix.  We can close it now.
>
> R's,
> John
>
> ___
> 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] Ticket #111 - MX/A/AAAA test needs justification

[John Levine]

It appears that Murray S. Kucherawy   said:
>-=-=-=-=-=-
> [ various things ]

I have reread this ticket and found nothing actionable, and a lot of 
misconceptions aboout how the DNS works.

There is nothing to fix.  We can close it now.

R's,
John

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Mon, May 17, 2021 at 10:19 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Fatal flaws with the MX/A/ test
>
>- During DMARC policy evaluation, the process may have retrieved an
>SPF policy or a DKIM public key which is associated with the RFC5322.From
>domain or one of its descendants, even though the SPF test did not pass and
>any relevant DKIM tests did not verify.   Obtaining such data provides
>evidence that the domain name is in use by the domain owner and therefore
>the failure should be handled as SP rather than NP.   But adding this
>condition into the evaluation means that the evaluation is no longer
>deterministic, since the pool of supplementary information can vary from
>one message to the next..
>
>
In what way does the SPF and DKIM information fetched for one message taint
the resolution of the message coming after it from the same domain?


>
>- If the RFC5321.MailFrom domain is a parent of, or unrelated to, the
>RFC5322.From domain,. then the DMARC evaluation will not have checked for
>an SPF policy on the From domain.   The presence of an SPF policy indicates
>that the domain does exist and that the domain owner has implemented this
>sender authentication mechanism.If SPF is present, the policy
>evaluation should be SP, not NP, but the SPF policy is not considered by
>the MX/A/ rule.
>
> The same is true for an unaligned DKIM signature.

To me, this just means trying to piggyback the MX/A/ semantics off of
the presence of DKIM and SPF results is fallible.

Problematic ambiguity, depending on the presumed justification for the
> MX/A/ test
>
>- Both MX and SPF can be used to allow or block traffic.   MX can
>block message delivery using a host name of "." (RFC 7505) or any other
>invalid or non-routable name.   SPF can be used to block traffic if the
>policy is "-ALL".   If the selection of MX is intended to score the domain
>for a probability that it is used for email, then the block signals should
>be considered as indicators of NP, and the non-blocking signals should be
>considered as SP.   But then what to do if the signals are not in the same
>direction?
>
> I don't follow this at all.  A "." MX is an indication that the domain
exists but wishes to publish that it offers no way to receive mail.  It
might send perfectly legitimate and possibly even desirable email.  An SPF
"-all" is an indication that the sender handles all of its own mail (or at
least thinks it does).  It, too, might send perfectly legitimate and
possibly even desirable mail.  Neither of those strike me as equivalent to
"this domain doesn't exist for the purposes of email".


>-
>
> Constraints imposed by DNS
>
> DNS Queries for a specific RR type produce one of three results
>
>- Data:  An entry matches the requested name, exactly or by wildcard,
>and also matches the requested RR type.
>- NoData:   An entry matches the requested name, exactly or by
>wildcard, but the requested RR type cannot be matched
>- NXDomain:  No entry exists for the name, either exactly or wildcard,
>for any RR type.
>
> When multiple query types are checked for the same domain name, the
> multiple three-way results must be consolidated into a single binary
> conclusion: SP or NP.That conclusion will be heavily influenced by
> assumptions about how domain administrators will configure their domains,
> and such assumptions are difficult to apply globally.
>

DMARC is clear about this, in my opinion: RFC 7489, Appendix A.4, says
NXDOMAIN and NODATA are equivalent because in both cases "no such records
were published".  If you're arguing that this definition is hurting DMARC's
efficacy, I'd love to see some data.

The one exception to this problem is the NS query.   It acts as a query for
> type=ANY with the specific results discarded.   As a result, it has only
> two outcomes:
>
>- Data:  The name is used in DNS (policy applied = SP)
>- NXDomain:  The name is not used in DNS.(policy used = NP)
>
> Interesting.  Are there any data to suggest this is more effective or
accurate than the MX/A/ test?

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

Fatal flaws with the MX/A/ test


   - During DMARC policy evaluation, the process may have retrieved an SPF
   policy or a DKIM public key which is associated with the RFC5322.From
   domain or one of its descendants, even though the SPF test did not pass and
   any relevant DKIM tests did not verify.   Obtaining such data provides
   evidence that the domain name is in use by the domain owner and therefore
   the failure should be handled as SP rather than NP.   But adding this
   condition into the evaluation means that the evaluation is no longer
   deterministic, since the pool of supplementary information can vary from
   one message to the next..
   - If the RFC5321.MailFrom domain is a parent of, or unrelated to, the
   RFC5322.From domain,. then the DMARC evaluation will not have checked for
   an SPF policy on the From domain.   The presence of an SPF policy indicates
   that the domain does exist and that the domain owner has implemented this
   sender authentication mechanism.If SPF is present, the policy
   evaluation should be SP, not NP, but the SPF policy is not considered by
   the MX/A/ rule.

Problematic ambiguity, depending on the presumed justification for the
MX/A/ test

   - Both MX and SPF can be used to allow or block traffic.   MX can block
   message delivery using a host name of "." (RFC 7505) or any other invalid
   or non-routable name.   SPF can be used to block traffic if the policy is
   "-ALL".   If the selection of MX is intended to score the domain for a
   probability that it is used for email, then the block signals should be
   considered as indicators of NP, and the non-blocking signals should be
   considered as SP.   But then what to do if the signals are not in the same
   direction?

Constraints imposed by DNS

DNS Queries for a specific RR type produce one of three results

   - Data:  An entry matches the requested name, exactly or by wildcard,
   and also matches the requested RR type.
   - NoData:   An entry matches the requested name, exactly or by wildcard,
   but the requested RR type cannot be matched
   - NXDomain:  No entry exists for the name, either exactly or wildcard,
   for any RR type.

When multiple query types are checked for the same domain name, the
multiple three-way results must be consolidated into a single binary
conclusion: SP or NP.That conclusion will be heavily influenced by
assumptions about how domain administrators will configure their domains,
and such assumptions are difficult to apply globally.

The one exception to this problem is the NS query.   It acts as a query for
type=ANY with the specific results discarded.   As a result, it has only
two outcomes:

   - Data:  The name is used in DNS (policy applied = SP)
   - NXDomain:  The name is not used in DNS.(policy used = NP)

This query has no dependencies on other mail message attributes, so it is
deterministic.
It directly addresses the stated question:   "Has the domain administrator
configured this name into DNS, and therefor has been given the opportunity
to implement sender authentication controls?"
It does not attempt to guess whether the domain configuration indicates
mail system participation or not.
If eliminates the possible need to evaluate specific RR types for allow or
block signals.
It is simple to define and simple to implement.

Doug Foster



On Fri, May 7, 2021 at 5:43 PM Murray S. Kucherawy 
wrote:

> On Thu, May 6, 2021 at 8:14 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> My argument is that that A//MX has no useful relevance to determining
>> whether the RFC5322.FROM address of a message should be evaluated based on
>> SP or NP. NP is described as testing "non-existent", rather than "possibly
>> able to receive mail". We need a test that evaluates whether the domain
>> exists or not, and is maximally protected from false positives caused by
>> host names and wildcards.
>>
>> If this group is convinced that A//MX is meaningful for the distinction 
>> between SP and NP, I am asking someone to provide the justification and 
>> define the algorithm.  Right now I have seen neither.
>>
>>
> I continue to be unclear on why you think that test suite against a name
> is inadequate.  Can you demonstrate a live case of a false positive or
> false negative?  Perhaps an actual example will help to move this from the
> abstract to the concrete.
>
> In the meantime, here's what I think is the justification: If you try to
> send me mail apparently from a domain that appears to have no email-related
> presence in the DNS, that strikes me as a reasonable situation in which to
> bounce such a message, and accordingly, a viable test for DMARC to use.
> It's also relatively cheap, given that the DNS is a globally distributed
> highly resilient database specifically built to answer such questions.  An
> "email-related presence" is the three RRTYPEs that SMTP specifically uses
> in trying to make use of a reverse path, and sinc

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

Justification and Implementation of the NP Policy

The NP Policy is used to hinder attacks of type “Invention”, as defined
below:

· *Impersonation* attacks utilize an existing subdomain of the
parent.  The domain owner can hinder impersonation attacks using DMARC and
SPF policies published on the subdomain, as well as with the SP clause of
the parent domain’s DMARC policy.   The number of existing subdomains is
finite, although it may be a large number in some cases.

· *Invention* attacks utilize a non-existent subdomain of the
parent.   Therefore, no SPF or DMARC policy is available on the
subdomain.   The domain owner can hinder impersonation attacks by
converting them to existing domains, or by publishing a parent domain DMARC
policy with SP>none (in the current specification) or NP>none (in the
proposed specification.)The number of non-existent subdomains is
essentially infinite, limited only by the available character set, the
64-character length of a segment, and the 255-character limit of a full
domain.

Most recipient systems operate on a default-open basis, meaning that
messages which have no negative indicators are allowed through.   Attackers
using false identity will choose a parent domain with a favorable
reputation, so that the parent domain will be unlikely to cause a message
to be blocked.

However, recipient systems will also learn from messages received, so the
feasibility of false-identity attacks will diminish with repeated use of
any single identity.Since invention attacks draw from an essentially
infinite pool of possible identifiers, the possibility of an
invention-based attacks is of significant concern to the recipient.

When a DMARC policy uses SP>none, both impersonation and invention attack
types are hindered.   However, operational reports indicate that SP>none is
often the last step in a long DMARC implementation process.   Without an NP
policy, invention attacks remain viable as long as SP=none.

The new NP policy reverses this process.   Once all subdomains are
considered to exist in DNS, the organization policy can be set to NP>none,
hindering invention attacks.Since unused domains have no users,
organizational resistance to setting NP=reject should be minimal.
 Hindering invention attacks can now become one of the first steps in the
DMARC rollout process, rather than one of the last.
Test Design Considerations One-sided error curve

When designing a non-existent test, the test needs to have a one-sided
error curve.  The test must be trusted to produce no false classifications
of existing domains as non-existent, because such errors will lead to an
abandonment of the test and a return to infinite possibilities.
Operators should be able to accept a test which sometimes accepts a
non-existent domain as existent, because such events can be handled by
exception as needed.
Ambiguous Results – the A/ query type

The A and  tests are examples of an ambiguous test.   When a result is
returned, the result could be one of two things:

1.   The first segment represents a host record in a parent domain
.parentdomain, or

2.   The first segment represents a null host name so that the host
name is the domain name
.parentdomain

When the goal is to determine whether a specific identifier represents a
DNS domain, the A record must be coupled with another test to resolve the
ambiguity.
Ambiguous Results - Wildcards

Wildcards are another source of ambiguity.  If a query for
“subdomain.parentdomain” returns a result, it may be appropriate to requery
using “*.parentdomain”.  If the wildcard does not exist, then the subdomain
is confirmed to exist.  If a wildcard is confirmed, then the results are
ambiguous and disposition must be made based on the unresolved ambiguity.
Testing for non-existence:  The TXT test

One way to test for non-existent domain is to type for type=TXT,
query=domainname.   If the query returns NXDOMAIN, non-existence is fully
confirmed.   If the test returns NODATA or result data, then the domain is
tentatively confirmed to exist.A wildcard test is recommended to
determine whether existence is fully confirmed (no wildcard) or ambiguous
(wildcard detected.)

The elegance of this test is that it is simple and lightweight, requiring
at most 2 DNS lookups.   Result possibilities are:

· NXDOMAIN – domain does not exist

· Confirmed – domain existence is confirmed without wildcard

· Ambiguous – domain existence is confirmed with wildcard.

· TempError – any DNS error, including DNS SEC failures that cause
server error.
Testing for non-existence:  The Mail Enabled Test

An alternative test examines DNS for the presence of MX, A/, and
possibly SPF records.  If any of these are found, the domain is assumed to
exist, and if none are found, the domain is assumed to not exist.This
test is based on the assumption that any domain used in a FROM domain must
also have a server infrastructure for r

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Fri, May 7, 2021 at 7:53 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> My problem with MX/A/AAA is that it IS a "mail enabled" test, which is
> exactly the concept that you rejected in a recent previous post.
>

I don't know how to answer that, since I don't know what "mail enabled"
means.

It is also an SMTP-dependent test.  Since SMTP addressing is independent of
> Message addressing, it is a poor fit at best for distinguishing between NP
> and SP.
>

I don't know what those middle two terms mean either.

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

Murray, thank you for attempting to answer the question.

My problem with MX/A/AAA is that it IS a "mail enabled" test, which is
exactly the concept that you rejected in a recent previous post.   It is
also an SMTP-dependent test.  Since SMTP addressing is independent of
Message addressing, it is a poor fit at best for distinguishing between NP
and SP.

NP and SP do provide us with the opportunity to begin distinguishing
between two classes of threats.Explaining the two classes requires a
longer post than I can provide right now.  Time for bed, and tomorrow is a
busy day for me.

On Fri, May 7, 2021 at 5:43 PM Murray S. Kucherawy 
wrote:

> On Thu, May 6, 2021 at 8:14 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> My argument is that that A//MX has no useful relevance to determining
>> whether the RFC5322.FROM address of a message should be evaluated based on
>> SP or NP. NP is described as testing "non-existent", rather than "possibly
>> able to receive mail". We need a test that evaluates whether the domain
>> exists or not, and is maximally protected from false positives caused by
>> host names and wildcards.
>>
>> If this group is convinced that A//MX is meaningful for the distinction 
>> between SP and NP, I am asking someone to provide the justification and 
>> define the algorithm.  Right now I have seen neither.
>>
>>
> I continue to be unclear on why you think that test suite against a name
> is inadequate.  Can you demonstrate a live case of a false positive or
> false negative?  Perhaps an actual example will help to move this from the
> abstract to the concrete.
>
> In the meantime, here's what I think is the justification: If you try to
> send me mail apparently from a domain that appears to have no email-related
> presence in the DNS, that strikes me as a reasonable situation in which to
> bounce such a message, and accordingly, a viable test for DMARC to use.
> It's also relatively cheap, given that the DNS is a globally distributed
> highly resilient database specifically built to answer such questions.  An
> "email-related presence" is the three RRTYPEs that SMTP specifically uses
> in trying to make use of a reverse path, and since this is an email
> application, that also strikes me as reasonable.
>
> You could (and some have) go one step further and attempt to make a
> connection to whatever address that test resolved, on port 25, and see if
> something answers.  You could go even further and try to interact via SMTP
> with the server you find there, and test to see if the RFC5322.From address
> responds 250 to RCPT.  But those are far more heavyweight tests, which can
> add substantial time to DMARC processing, and such tests can get you
> blocked from further interaction with those sites as they look like
> address  harvesting probes.
>
> Wildcards are a fact of life.  We will make no progress asserting that
> everyone has to stop using them because they muddy DMARC's waters.  DMARC
> could confirm on getting a positive MX reply that there is (or is not) a
> wildcard MX in play, but I don't know how you would use that information
> because the answer is the same both for "real" names and "fake" ones.  Is
> this the basis for your position that the triple query done today is
> inadequate?
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Thu, May 6, 2021 at 8:14 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> My argument is that that A//MX has no useful relevance to determining
> whether the RFC5322.FROM address of a message should be evaluated based on
> SP or NP. NP is described as testing "non-existent", rather than "possibly
> able to receive mail". We need a test that evaluates whether the domain
> exists or not, and is maximally protected from false positives caused by
> host names and wildcards.
>
> If this group is convinced that A//MX is meaningful for the distinction 
> between SP and NP, I am asking someone to provide the justification and 
> define the algorithm.  Right now I have seen neither.
>
>
I continue to be unclear on why you think that test suite against a name is
inadequate.  Can you demonstrate a live case of a false positive or false
negative?  Perhaps an actual example will help to move this from the
abstract to the concrete.

In the meantime, here's what I think is the justification: If you try to
send me mail apparently from a domain that appears to have no email-related
presence in the DNS, that strikes me as a reasonable situation in which to
bounce such a message, and accordingly, a viable test for DMARC to use.
It's also relatively cheap, given that the DNS is a globally distributed
highly resilient database specifically built to answer such questions.  An
"email-related presence" is the three RRTYPEs that SMTP specifically uses
in trying to make use of a reverse path, and since this is an email
application, that also strikes me as reasonable.

You could (and some have) go one step further and attempt to make a
connection to whatever address that test resolved, on port 25, and see if
something answers.  You could go even further and try to interact via SMTP
with the server you find there, and test to see if the RFC5322.From address
responds 250 to RCPT.  But those are far more heavyweight tests, which can
add substantial time to DMARC processing, and such tests can get you
blocked from further interaction with those sites as they look like
address  harvesting probes.

Wildcards are a fact of life.  We will make no progress asserting that
everyone has to stop using them because they muddy DMARC's waters.  DMARC
could confirm on getting a positive MX reply that there is (or is not) a
wildcard MX in play, but I don't know how you would use that information
because the answer is the same both for "real" names and "fake" ones.  Is
this the basis for your position that the triple query done today is
inadequate?

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Thu, May 6, 2021 at 4:19 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I was referring to this section of RFC 7208, which I have interpreted as a
> replacement for the older language of RFC 5321.
> Perhaps I overgeneralized, and it is acceptable/desirable to send NDRs if
> the system is confident that the return-path target is not forged.
> My perception has been that NDRs are widely ignored even when they are
> sent.  Is your experience different?
>

I interpret the cited RFC 7208 text to mean: "If you do SPF checking, then
don't generate an NDR to an address that has failed the SPF test."  It
doesn't supersede the more general guidance of RFC 5321, to which SPF is
basically an add-on.

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Fri, May 7, 2021 at 1:03 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> *The existence / non-existence test:*
>
> Given an identifier which is presumed to be a DNS domain name, perfrom a
> DNS lookup based on that name.
> The query may:
> [...]
> - return results using data from a parent domain
>

Can you give an example?  Otherwise I don't know what distinction you're
trying to make.

Is there a query or collection of queries that can ensure that we only
> accept results from the identifier domain and not from the parent?
>

I don't understand.  In the "answer" portion of a DNS record, you either
get what you asked for (or something matching it like a wildcard), or you
don't.  Anything else you might get is "glue" data, which as I recall is
easy to identify and exclude.


> *Wildcard DNS:*
>
> Wildcard entries create intentional ambiguity.   How do we suggest that
> wildcard results should be factored into the evaluation?
>

You can't, as far as I know.  That's the nature of wildcard records.

*The mail-enabled test:*
>
> Once existence / non-existence is determined, is it desirable to test for
> "mail enabled"?
>

It may be, but it's historically an expensive test with false negatives, as
far as I recall from my time working on mailing list software.  Those sorts
of probes get you into block lists if you do them a lot.

If so, what role should parent-domain results play in answering this
> question?
> If "Mail Enabled" is relevant, why is the existence of an SPF policy
> irrelevant?
>

I don't understand the purpose of the latter question.

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Tim Wicinski]

Folks that deploy wildcard MX usually have a reason.   It may not be a
reason that makes sense to others,
but there's usually a reason.

In those cases, np won't work.  We should perhaps spell that out in the
text a bit more clearly.

On Fri, May 7, 2021 at 5:13 PM John Levine  wrote:

> It appears that Douglas Foster  
> said:
> >Is there a query or collection of queries that can ensure that we only
> >accept results from the identifier domain and not from the parent?
>
> This is a meaningless question.  DNS queries ask about a specific name
> and RRTYPE and you get back the answer for that name and RRTYPE.
>
> >*Wildcard DNS:*
> >
> >Wildcard entries create intentional ambiguity.
>
> That is simply false.  Wildcards are perfectly well defined.  I have
> occasionally found wildcard MX records to be useful.
>
> I have taken another look at ticket #111 and found that the questions
> it asks misunderstand both the way that the DNS works and the way that
> SMTP has used the DNS since RFC 1123 over 30 years ago.
>
> Please close this ticket, there is nothing to fix.
>
> R's,
> John
>
> ___
> 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] Ticket #111 - MX/A/AAAA test needs justification

[John Levine]

It appears that Douglas Foster   said:
>Is there a query or collection of queries that can ensure that we only
>accept results from the identifier domain and not from the parent?

This is a meaningless question.  DNS queries ask about a specific name
and RRTYPE and you get back the answer for that name and RRTYPE.

>*Wildcard DNS:*
>
>Wildcard entries create intentional ambiguity.

That is simply false.  Wildcards are perfectly well defined.  I have
occasionally found wildcard MX records to be useful.

I have taken another look at ticket #111 and found that the questions
it asks misunderstand both the way that the DNS works and the way that
SMTP has used the DNS since RFC 1123 over 30 years ago.

Please close this ticket, there is nothing to fix.

R's,
John

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

Here are the tests that I am looking to define:


*The existence / non-existence test:*
Given an identifier which is presumed to be a DNS domain name, perfrom a
DNS lookup based on that name.
The query may:
- return results using data from the identifier domain
- return results using data from a parent domain
- return NXDOMAIN

If the result is definitely from the identifier domain, the domain name
exists
If the result is NXDOMAIN, the domain does not exists
If the result is from the parent domain, the results are uncertain.

Is there a query or collection of queries that can ensure that we only
accept results from the identifier domain and not from the parent?


*Wildcard DNS:*

Wildcard entries create intentional ambiguity.   How do we suggest that
wildcard results should be factored into the evaluation?


*The mail-enabled test:*

Once existence / non-existence is determined, is it desirable to test for
"mail enabled"?
If so, what role should parent-domain results play in answering this
question?
If "Mail Enabled" is relevant, why is the existence of an SPF policy
irrelevant?

If "mail enabled" is used, this creates implicit DNS configuration
requirements on the domain owner.  New requirements should be stated quite
explicitly.



On Fri, May 7, 2021 at 3:06 PM Murray S. Kucherawy 
wrote:

> On Thu, May 6, 2021 at 5:02 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> I have begun data collection on the effectiveness of the MX and A tests.
>>  Wildcard DNS entries increase the frequency of false positives and reduce
>> the usability of the test.   For example, "msaqq189.ford.com" returns a
>> set of MX results, but I rather doubt that I made a lucky guess and found a
>> mail domain that Ford Motor actually uses.
>>
>
> There's no need to guess.  You can query for wildcard records:
>
> $ host -t mx '*.ford.com'
> *.ford.com mail is handled by 10 cluster4.us.messagelabs.com.
> *.ford.com mail is handled by 20 cluster4a.us.messagelabs.com.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Fri, May 7, 2021 at 9:06 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I objected vigorously during the PSD review, but the Area Director
> directed me to defer the discussion so the experiment could move forward.
>

Can you please cite what I said to give you this impression?  I don't
remember saying anything that rose to the level of "directed".

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Murray S. Kucherawy]

On Thu, May 6, 2021 at 5:02 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I have begun data collection on the effectiveness of the MX and A tests.
>  Wildcard DNS entries increase the frequency of false positives and reduce
> the usability of the test.   For example, "msaqq189.ford.com" returns a
> set of MX results, but I rather doubt that I made a lucky guess and found a
> mail domain that Ford Motor actually uses.
>

There's no need to guess.  You can query for wildcard records:

$ host -t mx '*.ford.com'
*.ford.com mail is handled by 10 cluster4.us.messagelabs.com.
*.ford.com mail is handled by 20 cluster4a.us.messagelabs.com.

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

I objected vigorously during the PSD review, but the Area Director directed
me to defer the discussion so the experiment could move forward.

Nonetheless, repeating inadequate language does not render it adequate.

Separating NP from SP should enable a significant improvement in threat
management if we can get the test right.  Unfortunately, a test that is
prone to both false positives and false negatives does not serve the
purpose well, especially if those problems are swept under the rug rather
than being articulated.



On Fri, May 7, 2021, 10:55 AM Todd Herr  wrote:

> On Thu, May 6, 2021 at 11:13 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> This is about
>> Section 3.8. Non-existent Domains
>>
>>For DMARC purposes, a non-existent domain is a domain for which there
>>is an NXDOMAIN or NODATA response for A, , and MX records.  This
>>is a broader definition than that in [RFC8020].
>>
>> My argument is that that A//MX has no useful relevance to determining 
>> whether the RFC5322.FROM address of a message should be evaluated based on 
>> SP or NP.  NP is described as testing "non-existent", rather than "possibly 
>> able to receive mail".   We need a test that evaluates whether the domain 
>> exists or not, and is maximally protected from false positives caused by 
>> host names and wildcards.
>>
>> If this group is convinced that A//MX is meaningful for the distinction 
>> between SP and NP, I am asking someone to provide the justification and 
>> define the algorithm.  Right now I have seen neither.
>>
>>
>>
> For what it's worth, the text in question was copied directly from
> draft-ietf-dmarc-psd
>   (Section 2.7 of
> that document, to be precise). As I understand it, draft-ietf-dmarc-psd
> imposes some requirements on the text in DMARCbis, and so to support
> satisfying those requirements, other bits of text were imported, too.
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *e:* todd.h...@valimail.com
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> ___
> 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] Ticket #111 - MX/A/AAAA test needs justification

[Todd Herr]

On Thu, May 6, 2021 at 11:13 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> This is about
> Section 3.8. Non-existent Domains
>
>For DMARC purposes, a non-existent domain is a domain for which there
>is an NXDOMAIN or NODATA response for A, , and MX records.  This
>is a broader definition than that in [RFC8020].
>
> My argument is that that A//MX has no useful relevance to determining 
> whether the RFC5322.FROM address of a message should be evaluated based on SP 
> or NP.  NP is described as testing "non-existent", rather than "possibly able 
> to receive mail".   We need a test that evaluates whether the domain exists 
> or not, and is maximally protected from false positives caused by host names 
> and wildcards.
>
> If this group is convinced that A//MX is meaningful for the distinction 
> between SP and NP, I am asking someone to provide the justification and 
> define the algorithm.  Right now I have seen neither.
>
>
>
For what it's worth, the text in question was copied directly from
draft-ietf-dmarc-psd
  (Section 2.7 of
that document, to be precise). As I understand it, draft-ietf-dmarc-psd
imposes some requirements on the text in DMARCbis, and so to support
satisfying those requirements, other bits of text were imported, too.
-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

This is about
Section 3.8. Non-existent Domains

   For DMARC purposes, a non-existent domain is a domain for which there
   is an NXDOMAIN or NODATA response for A, , and MX records.  This
   is a broader definition than that in [RFC8020].

My argument is that that A//MX has no useful relevance to
determining whether the RFC5322.FROM address of a message should be
evaluated based on SP or NP.  NP is described as testing
"non-existent", rather than "possibly able to receive mail".   We need
a test that evaluates whether the domain exists or not, and is
maximally protected from false positives caused by host names and
wildcards.

If this group is convinced that A//MX is meaningful for the
distinction between SP and NP, I am asking someone to provide the
justification and define the algorithm.  Right now I have seen
neither.


On Thu, May 6, 2021 at 9:52 PM Seth Blank  wrote:

> On Thu, May 6, 2021 at 18:47 John Levine  wrote:
>
>> It appears that Douglas Foster  
>> said:
>> >My perception has been that NDRs are widely ignored even when they are
>> >sent.  Is your experience different?
>>
>> Yes.  We are not going to rewrite RFC 5321 here.  Please stop.
>
>
> Doug, I don’t understand what textual consideration within the DMARCbis
> documents you are discussing.
>
> Please reference the text in question and your proposed modifications, or
> move on to a topic which is material to driving this bis documents to
> completion, which is our current work item.
>
> Seth, as Chair
> --
>
> *Seth Blank* | VP, Product
> *e:* s...@valimail.com
> *p:* 415.273.8818
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> ___
> 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] Ticket #111 - MX/A/AAAA test needs justification

[Seth Blank]

On Thu, May 6, 2021 at 18:47 John Levine  wrote:

> It appears that Douglas Foster  
> said:
> >My perception has been that NDRs are widely ignored even when they are
> >sent.  Is your experience different?
>
> Yes.  We are not going to rewrite RFC 5321 here.  Please stop.


Doug, I don’t understand what textual consideration within the DMARCbis
documents you are discussing.

Please reference the text in question and your proposed modifications, or
move on to a topic which is material to driving this bis documents to
completion, which is our current work item.

Seth, as Chair
-- 

*Seth Blank* | VP, Product
*e:* s...@valimail.com
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[John Levine]

It appears that Douglas Foster   said:
>My perception has been that NDRs are widely ignored even when they are
>sent.  Is your experience different?

Yes.  We are not going to rewrite RFC 5321 here.  Please stop.

R's,
John

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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Hector Santos]

On 5/6/2021 8:02 PM, Douglas Foster wrote:
I have begun data collection on the effectiveness of the MX and A 
tests.   Wildcard DNS entries increase the frequency of false 
positives and reduce the usability of the test.   For example, 
"msaqq189.ford.com " returns a set of MX 
results, but I rather doubt that I made a lucky guess and found a 
mail domain that Ford Motor actually uses.


You are adding an human element to this that doesn't exist.

At best, all you can do is enforce the protocol requirements, the MUST 
semantics for sure, the SHOULD, most of the time (it is not a MUST) 
and the possible MAYS.   You have to be ready for all that independent 
of reputation.


The beauty of the DKIM Policy-based Model that began with DomainKeys, 
extended with DKIM which included SSP, reduced to ADSP when splitting 
SSP from DKIM-BASE, then abandoned and now DMARC which brought it back 
to life by adding Reporting, is the DOMAIN now giving the world a hint 
about its operations.


DMARC is very limited to three policies: reject, quarantine & none.

Reject and Quarantine is equivalent to an exclusive, restrictive 
policy which gives SMTP transport rejection authorization. Otherwise, 
you did nothing with a "none" policy.


There are the protocol rules.  The restrictive policies has alignment 
rules and there are procedures to getting to these results, like 
lookup DNS requirements.


Independent of DMARC,  MX is a SHOULD for a domain, you can still send 
mail to a domain that does not have MX records.    is obviously a 
SHOULD because not everyone is TCP6 ready.  Everyone is not going to 
have a DMARC record, nor a DKIM record.  SSP, ADSP and now DMARC are 
the only way to get a DOMAIN policy above and beyond standard SMTP.  
SPF is also an extension to SMTP with its own independent requirements 
that DMARC MUST match.


So whats the easiest for a domain not to have any trouble with any of 
this?


Don't support it.  Don't pretend to support it.  Just ignore SPF, DKIM 
and its add-ons.


SMTP Receivers are not at a point where we can enforce what may not 
exist - a domain policy extractable at two points:


SMTP.MAIL FROM:  for SPF
SMTP.DATA.FROM: for DMARC

I have proposed that we exploit the SUBMITTER protocol and optimized 
this high overhead protocol, by passing the 5322.FROM field to the 
MAIL FROM: line


MAIL FROM:  submitter=5322.from


Now SMTP has the ability to check for the DMARC policy to see how 
strong SPF SHOULD be and if its fails or not.


This will allow for the short circuiting and optimization of MAIL data 
I/O which today is increasingly getting larger with multi-media data 
transfer.



--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos



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

Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

I have begun data collection on the effectiveness of the MX and A tests.
 Wildcard DNS entries increase the frequency of false positives and reduce
the usability of the test.   For example, "msaqq189.ford.com" returns a set
of MX results, but I rather doubt that I made a lucky guess and found a
mail domain that Ford Motor actually uses.



On Thu, May 6, 2021 at 6:32 PM Jeremy Harris  wrote:

> On 05/05/2021 12:28, Douglas Foster wrote:
> > Non-delivery reports are officially discouraged
>
> RFC 5321 Section 6.2 says the reverse.
>
> --
> Cheers,
>Jeremy
>
> ___
> 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] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

I was referring to this section of RFC 7208, which I have interpreted as a
replacement for the older language of RFC 5321.
Perhaps I overgeneralized, and it is acceptable/desirable to send NDRs if
the system is confident that the return-path target is not forged.
My perception has been that NDRs are widely ignored even when they are
sent.  Is your experience different?

Doug Foster


2.5 .  Location of Checks

   The authorization check SHOULD be performed during the processing of
   the SMTP transaction that receives the mail.  This reduces the
   complexity of determining the correct IP address to use as an input
   to check_host() and allows errors to be returned directly to the
   sending MTA by way of SMTP replies.  Appendix D of [RFC7001]
 provides
   a more thorough discussion of this topic.

   The authorization check is performed during the SMTP transaction at
   the time of the MAIL command, and uses the MAIL FROM value and the
   client IP address.  Performing the check at later times or with other
   input can cause problems such as the following:

   o  It might be difficult to accurately extract the required
  information from potentially deceptive headers.

   o  Legitimate email might fail the authorization check because the
  sender's policy has since changed.

   Generating non-delivery notifications to forged identities that have
   failed the authorization check often constitutes backscatter, i.e.,
   nuisance rejection notices that are not actionable.  Operators are
   strongly advised to avoid such practices.  Section 2 of [RFC3834]

   describes backscatter and the problems it causes.



On Thu, May 6, 2021 at 6:32 PM Jeremy Harris  wrote:

> On 05/05/2021 12:28, Douglas Foster wrote:
> > Non-delivery reports are officially discouraged
>
> RFC 5321 Section 6.2 says the reverse.
>
> --
> Cheers,
>Jeremy
>
> ___
> 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] Ticket #111 - MX/A/AAAA test needs justification

[Jeremy Harris]

On 05/05/2021 12:28, Douglas Foster wrote:

Non-delivery reports are officially discouraged


RFC 5321 Section 6.2 says the reverse.

--
Cheers,
  Jeremy

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

[dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster]

The MX/A/ test is an appropriate tool for verifying the probable
existence of a return-path based on the RFC5321.MailFrom address. In the
early days, the requirement to send and receive non-delivery reports meant
that all mail systems had to participate bi-directionally. This is no
longer the case. Non-delivery reports are officially discouraged, and many
messages announce that the return-path is unusable with a NoReply username.
For testing RFC5321.MailFrom, SPF is now a necessary part of the
calculation, so its absence from the proposed test is baffling.
Additionally, use of MX/A/ as a substitute for a missing SPF policy is
now discouraged in some circles.

The A/ portion of the test reflects a necessary transition process to
MX, but that process should be complete for any domain with enough
sophistication to publish DMARC policies. As defined in RFC 5321, the
A/ test does not even require that the A/ record be a domain-level
name. We know that there are many more A/ records than mail systems, so
we can be certain that the test will produce false positives.

Equally important, the RFC5322.From address has no necessary connection to
an actual mail server, since the From address can be used exclusively for
messages sent by an EMail Service Provider (ESP) using the ESP's identity
for the RFC5321.MailFrom? address. Consequently, the relevance of the
MX/A/ test for distinguishing between SP and NP is lacking.

In sum, the test will produce both false positives and false negatives,
making its value doubtful, and it has at best a tenuous connection to the
way that RFC5322.From addresses are actually used.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc