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:<[email protected]>
C: MAIL FROM:<[email protected]>
C: MAIL FROM:<[email protected]>
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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
