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

[Hector Santos <[e-mail]>]

On 6/4/2019 10:29 AM, Vladimir Dubrovin wrote:
>
> 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.

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:<[e-mail]>
  C: MAIL FROM:<[e-mail]>
  C: MAIL FROM:<[e-mail]>

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