Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)

[Douglas Otis]

On 5/15/15 8:52 AM, Dave Crocker wrote:
> On 5/14/2015 11:27 PM, Terry Zink wrote:
>>> The Sender header field when present has been defined for decades
>>> to represent the sending agent!
>> Maybe, maybe not. 
>
> Sorry, but there isn't much maybe about it.
>
> The definition in the spec has been clear since the construct was
> invented, in 1977.
>
> /Usage/ has varied quite a bit, as with so much of email, with
> implementations re-purposing the field in various ways, thereby
> effectively defeating useful interoperability.
>
> And 'display' of the field is an entirely separate issue. Commentary
> about DMARC usually does cite 'display' as the essential requirement,
> which drives selection of the From field.
>
> IMO it continues to be a significantly misleading point, since end-user
> viewing of the From field is largely irrelevant to any real-world
> efficacy. This appears to be an indelicate point to raise, since it's
> being consistently ignored as discussions about DMARC continue
> (everywhere, not just here.)
>
> On the other hand, the rfc5322.From field is the only field with a
> content-related identifier that is /always/ present.
>
> Hence, a receiving filtering engine has a place that it always can
> always look, for a claim of authorship.  By its nature, a mechanism like
> DMARC must begin with an identifier selected by the receiving filtering
> engine.  Hence, there must (always) be an identifier reliably associated
> with the message.  Its semantics must pertain to something semantically
> interesting.  DMARC chose "content authorship", which is pretty
> obviously reasonable.
>
> With that claimed content responsibility, the engine can proceed with an
> analysis that relates the identifier to a reputation.  One aspect of
> reputation is "is the identifier authorized for use?"  DMARC answers
> that question.
>
> One could imagine a "handling responsibility" as being a reasonable
> alternative choice, too, but it's much weaker.  Worse, it invites a
> problematic disconnect between content responsibility and handling
> responsibility, which thereby invites gaming the system.
>
> Choosing content responsibility is therefore much more appealing, albeit
> simplistic in a way that causes problems with the entirely legitimate
> scenarios that the community has been seeing.  In particular, DMARC
> requires very tight coupling between content and handling
> responsibility, which differs from many, long-standing, legitimate
> scenarios.
>
> Choosing a properly-available Sender: field creates a much better
> semantic, in terms of pointing to the responsible operational agent.
>
> But it is not an operationally practical choice.  The problem is that
> when that identifier is different from the content identifier, we have
> the task of figuring out whether the identity in the Sender: field is
> 'authorized' to operate on behalf of the identity in the From: field.[*]
>
>
> d/
>
>
> [*] In case folk miss the point, the Sender identifier is /always/
> present, even when the Sender: field is not.  If this isn't clear to
> anyone, I encourage re-reading Section 3.4.2 of RFC 5322.
Dear Dave,

Also notice the attention to the Sender header field by
section 7.1 of RFC5321 in the following statement:
,--
Efforts to make it more difficult for users to set envelope
return path and header "From" fields to point to valid
addresses other than their own are largely misguided: they
frustrate legitimate applications in which mail is sent by
one user on behalf of another, in which error (or normal)
replies should be directed to a special address, or in which
a single message is sent to multiple recipients on different
hosts.  (Systems that provide convenient ways for users to
alter these header fields on a per-message basis should
attempt to establish a primary and permanent mailbox address
for the user so that Sender header fields within the message
data can be generated sensibly.)
'--

Operational practicality varies dramatically by domain based
on the type of email handled. For transactional email, with
some exceptions, policy based solely on the From can be
operationally convenient. When handling a normal range of
email configurations as typified for most ordinary users,
restrictive policy based solely on the From header field
domain will be highly disruptive of otherwise legitimate and
properly formed messages often supporting important
functions relied upon by a very large number of communities.

Unfortunately, DMARC removed admonishments on limiting the
types of email to be used by the domain asserting
restrictive policies and simply notes in Section 10.5
incompatibilities when mediators such as mailing-lists are
used.  This appears to indicate DMARC proponents have
entrenched into a view DMARC can force From header field
munging and abandonment of RFC5322 defined roles and the
functions defined by RFC5321, and submission practices
defined by RFC4409.  Rather than striking up the theme for
Frozen, the theme for Ja

Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)

[Hector Santos]

On 5/15/2015 11:52 AM, Dave Crocker wrote:


But it is not an operationally practical choice.  The problem is that
when that identifier is different from the content identifier, we have
the task of figuring out whether the identity in the Sender: field is
'authorized' to operate on behalf of the identity in the From: field.[*]


and one way to get that authorization bit is to hash bind the 5322.Sender:


[*] In case folk miss the point, the Sender identifier is /always/
present, even when the Sender: field is not.  If this isn't clear to
anyone, I encourage re-reading Section 3.4.2 of RFC 5322.


There are defaults and overrides.  RFC4407 "Purported Responsible 
Address (PRA)" has done some project research work in this area:


   https://tools.ietf.org/html/rfc4407

   Abstract

   This document defines an algorithm by which, given an e-mail message,
   one can extract the identity of the party that appears to have most
   proximately caused that message to be delivered.  This identity is
   called the Purported Responsible Address (PRA).

and the steps to get the PRA is outlined:

   https://tools.ietf.org/html/rfc4407#section-2


--
HLS


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)

[Dave Crocker]

On 5/15/2015 12:35 PM, Murray S. Kucherawy wrote:
> On Fri, May 15, 2015 at 8:52 AM, Dave Crocker  > wrote:
> 
> [*] In case folk miss the point, the Sender identifier is /always/
> present, even when the Sender: field is not.  If this isn't clear to
> anyone, I encourage re-reading Section 3.4.2 of RFC 5322.
> 
> 
> Did you mean 3.6.2?

wtf.

I read 3.6.2.  I thought 3.6.2.  I proofread 3.6.2.

How the heck did 3.4.2 show up?

grrr.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)

[Murray S. Kucherawy]

On Fri, May 15, 2015 at 8:52 AM, Dave Crocker  wrote:

>
> [*] In case folk miss the point, the Sender identifier is /always/
> present, even when the Sender: field is not.  If this isn't clear to
> anyone, I encourage re-reading Section 3.4.2 of RFC 5322.
>

Did you mean 3.6.2?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)

[Dave Crocker]

On 5/14/2015 11:27 PM, Terry Zink wrote:
>> The Sender header field when present has been defined for decades
>> to represent the sending agent!
> 
> Maybe, maybe not. 


Sorry, but there isn't much maybe about it.

The definition in the spec has been clear since the construct was
invented, in 1977.

/Usage/ has varied quite a bit, as with so much of email, with
implementations re-purposing the field in various ways, thereby
effectively defeating useful interoperability.

And 'display' of the field is an entirely separate issue. Commentary
about DMARC usually does cite 'display' as the essential requirement,
which drives selection of the From field.

IMO it continues to be a significantly misleading point, since end-user
viewing of the From field is largely irrelevant to any real-world
efficacy. This appears to be an indelicate point to raise, since it's
being consistently ignored as discussions about DMARC continue
(everywhere, not just here.)

On the other hand, the rfc5322.From field is the only field with a
content-related identifier that is /always/ present.

Hence, a receiving filtering engine has a place that it always can
always look, for a claim of authorship.  By its nature, a mechanism like
DMARC must begin with an identifier selected by the receiving filtering
engine.  Hence, there must (always) be an identifier reliably associated
with the message.  Its semantics must pertain to something semantically
interesting.  DMARC chose "content authorship", which is pretty
obviously reasonable.

With that claimed content responsibility, the engine can proceed with an
analysis that relates the identifier to a reputation.  One aspect of
reputation is "is the identifier authorized for use?"  DMARC answers
that question.

One could imagine a "handling responsibility" as being a reasonable
alternative choice, too, but it's much weaker.  Worse, it invites a
problematic disconnect between content responsibility and handling
responsibility, which thereby invites gaming the system.

Choosing content responsibility is therefore much more appealing, albeit
simplistic in a way that causes problems with the entirely legitimate
scenarios that the community has been seeing.  In particular, DMARC
requires very tight coupling between content and handling
responsibility, which differs from many, long-standing, legitimate
scenarios.

Choosing a properly-available Sender: field creates a much better
semantic, in terms of pointing to the responsible operational agent.

But it is not an operationally practical choice.  The problem is that
when that identifier is different from the content identifier, we have
the task of figuring out whether the identity in the Sender: field is
'authorized' to operate on behalf of the identity in the From: field.[*]


d/


[*] In case folk miss the point, the Sender identifier is /always/
present, even when the Sender: field is not.  If this isn't clear to
anyone, I encourage re-reading Section 3.4.2 of RFC 5322.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc