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.
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.
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.
I don't understand how the HELO domain name is relevant to this
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)
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/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
