04.06.2019 15:08, Dave Crocker пишет:
> On 6/4/2019 1:48 PM, Vladimir Dubrovin wrote:
>> Reports are not sent to Return-Path address, empty return path does not
>> 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.
>
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.
>
>> 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.
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.
>
>
>> 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)
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).
>
> d/
>
>
>
--
Vladimir Dubrovin
@Mail.Ru
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
