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

[Dave Crocker <[e-mail]>]

>> 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