On Jul 14, 2014, at 5:15 PM, Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:
On Mon, Jul 14, 2014 at 04:47:19PM -0400, Scott Kitterman wrote:
However, DMARC is problematic for mail that does not flow from
operators having a relationship with the domain owner, directly to
receivers operating the destination mailbox. Examples of such
"indirect" flows are mailing lists, publish-to-friend functionality,
mailbox forwarding (".forward"), and third-party services that send
on behalf of clients. The working group will explore possible updates
and extensions to the specifications in order to address limitations
and/or add capabilities. It will also provide technical
implementation guidance and review possible enhancements elsewhere in
the mail handling sequence that could improve could DMARC
compatibility.
This is a solved problem, the "Rfc822.Sender" field should have
from the outset trumped the "Rfc822.From" field when determining
message origin, and the DMARC policy should be that of the "Sender"
domain. Some MUAs already expose "Sender != From" by displaying
"From <sender> on behalf of <author>". This needs to become standard
MUA behaviour.
Viktor,
You are right, but this provides a domain not always seen by recipients. Only
the From header field is surely displayed.
The TPA-Label scheme can permit exceptions for specific domains and require
Sender header field/source-alignment as a means to avoid spoofing. The burden
of making exceptions is carried by the DMARC domain within a single, small, and
cacheable DNS transaction. While it is a minor change to include display of
Sender header fields, its alignment is normally ignored. Its display might
invite confusion or spoofing when necessary source alignment is not confirmed.
Even if the DMARC could assert Sender header field alignment has priority over
that of the From, recipients would still not know which to trust. While such a
scheme might be simpler to manage, the TPA-Label scheme offers an agile
transitional strategy for both Sender header fields as well as new
authentication schemes, such as those enabled by DANE.
Regards,
Douglas Otis