Douglas Otis writes:
> There are serious concerns being ignored regarding email captured in
> DMaRC feedback. Things like Intuit invoices or mailing-list
> conversations are being misdirected simply because DMaRC incorrectly
> assumes a sender/recipient relationship when general use email
> providers assert restrictive DMaRC policies.
So do you propose something like
Author Domains which impose policies that can result in failure
reports being sent MUST have Terms of Service in which mailbox
users agree that content of messages which fail DMARC checks may
be forwarded to the Author Domain as part of failure reports.
This includes messages that they have originated which are
unauthorized according to the definition of DMARC.
Or however you say that in IETF-ese?
> DMaRC policies that require From header field alignment with the
> sender inhibit the forwarding of email and dismiss Sender header
> field contents as being potentially deceptive to justify ignoring
> this field in the determination of direct "mail flows".
Isn't that backward? DMARC focuses on From alignment *because* in
typical MUA configurations Sender is not visible to the receiving
user, and in any case would be unlikely to be useful in counteracting
phishing and recommended-by-a-friend spam. That is, I don't see how
verifying Sender would be useful. True, if you verify Intuit as the
sender of mail on behalf of a billing company, the user seeing Intuit
in Sender would likely come to an appropriate conclusion. But if you
verify example.com as Sender, the user doesn't know who they are, and
in most cases I would expect them to simply ignore that information
and rely on From and any clues in the message content.
> However this often relied upon agility is seriously damaged by
> DMaAC's short-cut of ignoring the defined role of the Sender header
> field.
It's not a shortcut. Sender has the wrong semantics for combatting
phishing and recommended-by-friend spam.
> this does not include redirecting accepted messages to destinations
> neither specified by senders nor recipients.
This is not a problem restricted to DMARC. Any protocol that involves
forwarding a message to a third party (eg, the Sender field or
Return-Path) raises this issue (eg, in the case of a typo in the
recipient mailbox name). It's true that DMARC seems designed to cause
such problems.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
