-----Original Message-----
From: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Yoav Nir
Sent: Thursday, April 17, 2014 9:27 AM
To: mrex(_at_)sap(_dot_)com
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: (DMARC) Why mailing lists are only sort of special
On Apr 17, 2014, at 4:11 PM, Martin Rex <mrex(_at_)sap(_dot_)com> wrote:
Yoav Nir wrote:
On Apr 17, 2014, at 9:35 AM, Dave Cridland <dave(_at_)cridland(_dot_)net>
wrote:
Right now, my MUA treats this as a message "From John R Levine
<johnl(_at_)taugh(_dot_)com>". This means that any policy on the message
origination comes from looking solely at the taugh.com domain. We'll
pretend it has a DMARC policy. Herein lies the Yahoo/DMARC issue,
because unless your policy essentially stipulates that the IETF is
allowed to spoof you, we're stuck.
Then perhaps this is what needs to change. John R Levine did not send
you a message. He sent a message to the list. It is the list software
that sent you a message. So perhaps the From field should have been
?From: IETF Mailing list on behalf of John R Levine
<ietf(_at_)ietf(_dot_)org>?.
But that is EXACTLY what the IETF mailing list exploder *IS* doing
exactly as it has been specified for ages:
https://tools.ietf.org/html/rfc822#section-4.4.2
https://tools.ietf.org/html/rfc822#appendix-A.2
https://tools.ietf.org/html/rfc5322#section-3.6.2
The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message.
From: Yoav Nir <ynir(_dot_)ietf(_at_)gmail(_dot_)com>
Subject: Re: (DMARC) Why mailing lists are only sort of special
Errors-To: ietf-bounces(_at_)ietf(_dot_)org
Sender: ietf <ietf-bounces(_at_)ietf(_dot_)org>
Date: Thu, 17 Apr 2014 13:50:30 +0300
Message-ID: <B3467912-BDCA-4AE8-9939-60013DA99267(_at_)gmail(_dot_)com>
To: Dave Cridland <dave(_at_)cridland(_dot_)net>
CC: "ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>
Something as old as Outlook 2003 will properly display a message that
is received with a "Sender:" as "<Sender> on behalf of <From>"
A client as new as Mail.app on Mac OS X 10.9 does not.
Obviously the Sender: field is not where the DMARC implementations use
for checking policy.
Yoav, this is by design.
There is no reliable way to determine the relationship between the Sender:field
and the From: field from an authentication and authorization perspective at the
domain level unless both are within the same domain space. Other than "I say
so", how do we know that the Sender IS truly acting on behalf of the author in
the From field where they are not both in the same domain space? This is the
crux of the debate that has been going on for quite a few years. As a receiver,
on what basis can I trust the sender is authorized in this circumstance? John
says, "trust the mail (is on behalf of the author because you trust me". This
actually has worked in the real world for some time but has been under
increasing pressure due to abuse. While mailing lists have not been a
significant vector in the past (John says never, I say I have seen abusive mail
passed through lists so never is not true), that is not to say they will not be
a significant vector.
Some people are unhappy that DMARC ties identity to the From:field. Identity
could just as easily have been tied to the Mail From:field but there still
would have been a need for alignment ( going the other way) and ultimately
there still would have been an issue with the Sender:field if the goal is to
provide a model for authentication/authorization that does not have significant
defects allowing abuse (and again we are only talking about the problem space
of direct domain abuse, not phishing or spam in general). The only reason for
alignment is because of the use of both IP based (transport layer) and message
based (requiring examination of the message body) authentication.
The problem with an approach of trying to identify trust relationships between
domains (let alone authors and domains acting on behalf of individual authors
at other domains) is that it is not a linear relationship. That is, the
complexity of potential trust relationships does not increase in a linear
fashion as we add more users and domains to the equation. There are
other/easier ways of approaching the stated goal of
authentication/authorization.
In going back and re reading RFC 822 (1982), RFC 2822 (2001) and RFC 5322
(2008), I notice a small but important change between RFC 822 and RFC 2822. RFC
822 actually specified "This field contains the authenticated identity..." for
both the From:field and Sender:field among others. I followed the discussion
for RFC2822 but was not an active participant. I don't remember significant
discussion on this change but there may have been some. If this requirement had
been maintained AND had been implemented, it is quite possible we would be
having a different discussion today.
In the examples given in RFC822 for use of Sender:Field, where a domain name is
used, all of the Sender:field email address Domains (someone please validate
this as I went through the "A." examples once and somewhat quickly) were the
same as the From:field email address domains although there were examples where
the Sender:Field display name domain was different. On a side note, for the
next update it might be appropriate to drop the word "secretary" and substitute
"assistant" in the example given - a nit but appropriate nonetheless.
So it's clear that contrary to some assertions that we have today's issues with
email because authentication/security was not thought of, there was in fact
some consideration given to authentication/security in the original
specification.
Just a few thoughts.
Mike