Subject: [dmarc-ietf] Endless Loops with DKIM reports

From: Дилян Палаузов <[email-masked]>
Date: Tue, 04 Jun 2019 12:27:52 +0300

Hello,

the reporting per RFC 6651 can also cause endless email loops:

A DKIM failure report is sent, on which a bounce is generated and the bounce contains DKIM-Signature: r=y with invalid signature. So a new DKIM failure report is generated. The signature does not have to be invalid, having broken validator also messes the situation.

Regards
  Дилян

---

From: Dave Crocker <[email-masked]>
Date: Tue, 4 Jun 2019 11:41:46 +0200

On 6/4/2019 11:27 AM, Дилян Палаузов wrote:
> A DKIM failure report is sent, on which a bounce is generated

The rule for mail-handling notification messages has been that they do 
not contain a return address, in order to avoid looping.  Shouldn't that 
apply to DMARC reports, too?  If not, why?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Vladimir Dubrovin <[email-masked]>
Date: Tue, 4 Jun 2019 14:48:32 +0300

Reports are not sent to Return-Path address, empty return path does not
prevents report from being sent. Actually, report with empty
envelope-from has higher chances to generate a reverse report, because
in this case SPF is checked against HELO and, in practice, many seders
do not have SPF configured for HELO name and SPF failure can trigger a
report.

04.06.2019 12:41, Dave Crocker пишет:
> not contain a return address, in order to avoid looping.  Shouldn't
> that apply to DMARC reports, too?  If not, why?
>
> d/
>

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Dave Crocker <[email-masked]>
Date: Tue, 4 Jun 2019 14:08:35 +0200

> prevents report from being sent. Actually, report with empty

My comment was meant about the DMARC report being sent without a return 
(envelope from) address, the same as is already true for other email 
infrastructure control messages.

> envelope-from has higher chances to generate a reverse report, because

I don't understand how it is possible to send a report when there is no 
address to send it to.

> do not have SPF configured for HELO name and SPF failure can trigger a

I don't understand how the HELO domain name is relevant to this 
discussion, since it isn't a full email address.

d/

---

From: Vladimir Dubrovin <[email-masked]>
Date: Tue, 4 Jun 2019 15:27:11 +0300

04.06.2019 15:08, Dave Crocker пишет:
> My comment was meant about the DMARC report being sent without a
> return (envelope from) address, the same as is already true for other
> email infrastructure control messages.
>

DMARC reports are triggered based on the domain in RFC5322.From address
and are sent to DMARC reporting address from DMARC record for
RFC5322.From address. If one DMARC reports triggers another DMARC
reports, the second report will be sent to DMARC reporting address, not
to return-path.

> I don't understand how it is possible to send a report when there is
> no address to send it to.

Report destination address is different from return-path or the message
which triggers a report, so message with empty return-path
(envelope-from) can trigger a valid DMARC report and it will be
delivered to DMARC reporting address.

> discussion, since it isn't a full email address.

DMARC reporting can report and SPF or SPF alignment failure (RFC 7598
sections 4.2, 6.3) . According to section 2.4 of RFC 7208 (SPF)

      2.4 <https://tools.ietf.org/html/rfc7208#section-2.4>. The "MAIL
      FROM" Identity

...

   [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in [RFC5321] <https://tools.ietf.org/html/rfc5321#section-4.5.5>).  In this case, there is no explicit sender mailbox, and
   such a message can be assumed to be a notification message from the
   mail system itself.  When the reverse-path is null, this document
   defines the "MAIL FROM" identity to be the mailbox composed of the
   local-part "postmaster" and the "HELO" identity (which might or might
   not have been checked separately before).

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Дилян Палаузов <[email-masked]>
Date: Tue, 04 Jun 2019 16:19:26 +0300

Hello Validimir,

the point is that answers can be sent to the (DKIM) report and receiving the answers can trigger sending a new report to the address published in DNS.

Empty return path prevents sending an answer to the report.

What to do if a site sends a report that does not validate DMARC/DKIM, then a new (reverse) report by the other host is sent and this report again does not validate DMARC/DKIM, so it triggers a new report? This is a concern of improperly configured site pairs. The target for the recommendation to use MAIL FROM:<>/NOTIFY=NEVER are properly configured sites, that deal with improperly configured sites.

Regards
Дилян

---

From: Dave Crocker <[email-masked]>
Date: Tue, 4 Jun 2019 15:37:44 +0200

> reports, the second report will be sent to DMARC reporting address, not 

That's an issue only if the report is sent from an address that has a 
DMARC record.  Which might be a good reason NOT to send from such an 
address.

The high-level point I'm trying to make is that control messages -- such 
as DMARC reports -- need to be handled in a fashion that works 
automatically and at scale.  Since looping is a well-known problem for 
such messages, they need to be generated and handled in a way that 
prevents the problem.

> sections 4.2, 6.3) . According to section 2.4 of RFC 7208 (SPF)

Yes, but how is that relevant to the problem of DMARC report looping? 
It's merely one of the causes of a DMARC failure, but sources of failure 
isn't the issue with respect to report looping.

d/

---

From: Vladimir Dubrovin <[email-masked]>
Date: Tue, 4 Jun 2019 17:29:51 +0300

I see your point, but actually empty return-path doesn't guarantee the
DKIM/DMARC report to not receive the answer either, because e.g.
out-of-office autoreplies usually ignore return-path and send response
to RFC5322.Reply-To/RFC5322.From. It's quite common case human-readable
mailbox is set as a DMARC reporting address.

I believe, valid recommendations here is to follow RFC 3834 for both
sender and recipient, that is, to add

Auto-Submitted: auto-generated

header (Precedence: bulk may also be used, though not standardized)

Recommendation to use empty envelope-from / return-path is doubtful,
because this recommendation is usually applied to mail transport-level
application and DMARC reporting does not belong to transport level. In
practice, this recommendation will increase loop probability for DMARC
reports due to quite common SPF misconfiguration.

04.06.2019 16:19, Дилян Палаузов пишет:
> Hello Validimir,
>
> the point is that answers can be sent to the (DKIM) report and
> receiving the answers can trigger sending a new report to the address
> published in DNS.
>
> What to do if a site sends a report that does not validate DMARC/DKIM,
> then a new (reverse) report by the other host is sent and this report
> again does not validate DMARC/DKIM, so it triggers a new report? This
> is a concern of improperly configured site pairs. The target for the
> recommendation to use MAIL FROM:<>/NOTIFY=NEVER are properly
> configured sites, that deal with improperly configured sites.
>
> Regards
> Дилян
>
>         The rule for mail-handling notification messages has been that
>         they do not contain a return address, in order to avoid
>         looping.  Shouldn't that apply to DMARC reports, too?  If not,
>         why? d/ 
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Hector Santos <[email-masked]>
Date: Tue, 04 Jun 2019 11:21:29 -0400

> reports due to quite common SPF misconfiguration.

So with what protocol transport mechanism are DMARC reports sent?

The basic design question I see here is what return path to use for a 
DMARC report. The considerations would be:

  C: MAIL FROM:<>
  C: MAIL FROM:<unique-non-null-return-path>

The first format is known as the NULL return path.

 From what I see in my quick check of May and June logs, I did not see 
any NULL return path usage, but I do see the following style from 
three big ISPs:

  C: MAIL FROM:<[email-masked]>
  C: MAIL FROM:<[email-masked]>
  C: MAIL FROM:<[email-masked]>

Two of them are using non-standard "noreply" user-id string, 
sub-string concept in a non-standard attempt to expose the idea the 
receiver (or user) should not attempt to reply/bounce the messages.

Google has recognized this "noreply" tag and they made it not fail a 
CBV (Call Back Verification) check.

Yahoo will fail a CBV check and thus its dmarc reports are not 
received by my commercial package by default, out of the box.  I just 
added a local white list for this, but this points out the need to 
conform to a practice known to help prevent "responses" to a 
notification by using NULL return path address.  Otherwise, in the 
future DMARC reporting document, it needs to specify a new "special 
user-id" (left hand side of address) that will tell up-to-par 
compliant DMARC report receivers to not reply to it.

We can't presume that a general idea of using a "noreply" string or 
substring of a user id signifies a valid report or notification.  It 
can be a "loop hole" for bad guy mail entry abuse when it begins to 
pre-empt return path validity checking.

All this is another reason why we should consider splitting DMARC PS 
work into two documents.  Policy and Reporting.

--
HLS

---

From: "John Levine" <[email-masked]>
Date: 5 Jun 2019 22:06:18 +0200

>such messages, they need to be generated and handled in a way that 

Right.  you can give all the advice you want about sending stuff in
ways that's intended to prevent responses, but since some people will
always ignore your good advice, and any single party only controls one
leg of the loop, the only unlateral way to limit the damage is rate
limiting.

It's fine to tell people to use null bounce addresses and from:
addresses that don't ask for dmarc reports, but you need to rate limit
anyway.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 6 Jun 2019 09:03:26 +0200

On 6/5/2019 10:06 PM, John Levine wrote:
> limiti

Taking your note's plain language, you appear to be of the rather 
peculiar view that specifying standards doesn't matter, since people 
won't follow them.

Looping is a classic problem.  It has classic solutions.  Getting the 
details of one specified for this case is, of course, different from 
getting people to adopt it, but the start is with specifying it.

Having additional, ad hoc mechanisms for dealing with non-compliance is 
quite a separate matter.

> addresses that don't ask for dmarc reports, but you need to rate limit

I looked at the rest of this thread, to see where this point had already 
been made, since your note seems to have a tone implying it's an 
established point, but I couldn't find it.  So again, ad hoc mechanisms 
might also be useful, but they are separate.

d/

---

From: "John R Levine" <[email-masked]>
Date: 6 Jun 2019 10:08:44 +0200

> Taking your note's plain language, you appear to be of the rather peculiar 
> view that specifying standards doesn't matter, since people won't follow 
> them.
>
> Looping is a classic problem.  It has classic solutions.  Getting the details 
> of one specified for this case is, of course, different from getting people 
> to adopt it, but the start is with specifying it.

If people follow the spec there will be fewer loops, but it won't reduce 
the number to zero.  Partly it's because not everyone follows the spec, 
partly because it is hard to anticipate all of the paths that can lead to 
indirect loops a->b->c->a or a->b->c->d->a.

This is hardly limited to mail loops.  The DNS specs say not to create 
CNAME loops, but indirect loops happen all the time so every resolver that 
follows CNAMEs needs loop breaking code.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Thu, 6 Jun 2019 10:27:47 +0200

On 6/6/2019 10:08 AM, John R Levine wrote:
> the number to zero.

Forgive me, but I believe there is currently no spec to follow.  Yet.  I 
took this thread as raising the issue that there needs to be an effort 
that specifies how to avoid dmarc report loops.

d/

---

From: "John R Levine" <[email-masked]>
Date: 6 Jun 2019 12:38:54 +0200

> Forgive me, but I believe there is currently no spec to follow.  Yet.  I took 
> this thread as raising the issue that there needs to be an effort that 
> specifies how to avoid dmarc report loops.

As I thought I already said a few times, it would be a fine idea to offer 
advice to make DMARC reports less loop-prone.  No, that will not prevent 
all loops so you need to do rate limiting, too.

Regards,

---

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 7 Jun 2019 19:03:19 -0400

Suggestions for eliminating loops:
  
 Best (sender controlled)
 The report-sending account should be from a non-reportable domain or 
subdomain.   Authority to report on behalf of another domain/sub-domain can 
be established with a DKIM signature of the reporting domain.   Of course, 
if the report-sending domain is a subdomain of a reportable domain, the 
sub-domain needs its own DMARC policy to disable inheritance and to disable 
reporting.
  
 The report-sending account could be placed in a domain/sub-domain which is 
send-only (SPF policy but no MX records).   This prevents out-of-office 
messages, NDRs, or spam from being sent to the report-sending account. 
  
 A null sender would be one way of producing this result, but it may be 
difficult to implement in some configurations.   Additionally, messages 
from the null sender are more likely to be rejected by BATV filtering.
  
 Alternate (sender controlled)
  If the report-sending account is in a domain/sub-domain that collects 
feedback, messages sent to the report-sending account must be excluded from 
feedback data collection.

 Backup (recipient controlled)
 Option 1:  The recipient account should be in a domain/subdomain that does 
not collect DMARC feedback.
 Option 2:  If the recipient account domain does collect feedback data, the 
recipient account must be excluded from feedback data collection.
  
 Since the sender cannot know whether the recipient domain collects DMARC 
feedback, he should not rely on the sender being able to prevent looping.
  
 I think these methods will eliminate the need for rate limiting.
  
 Doug Foster

----------------------------------------
 From: "Dave Crocker" <[email-masked]>
Sent: Thursday, June 6, 2019 4:28 AM
To: "John R Levine" <[email-masked]>, [email-masked]
Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports   

d/

---

From: "John R Levine" <[email-masked]>
Date: 8 Jun 2019 16:56:08 +0200

...

These are all fine.

> I think these methods will eliminate the need for rate limiting.

BTDT.  Really, I have been doing various forms of autoresponders for 
thirty years, and no matter what you do, someone will loop back anyway, 
most likely from an address different from the one you sent the report to.

Regards,