On Jul 14, 2014, at 5:15 PM, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> 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