Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Alessandro Vesely <[e-mail]>]

On 2020-06-21 7:32 p.m., Dave Crocker wrote:
> On 6/18/2020 12:46 AM, Alessandro Vesely wrote:
>> "Authoring" can have subtly different acceptations, though.  The
>> exact sentence is:
>>
>>              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.
>> [https://tools.ietf.org/html/rfc5322#section-3.6.2]
>>
>> That is not so far from real.  The term "writing" sounds ambiguous,
>> as it is not clear whether it means "typing" or "publishing", in the
>> case of public mailing lists.  Given that Sender: is dedicated to
>> the typist, I'd opt for the latter interpretation.
> 
> In simple terms, author is the creator of the content and sender is
> the agent for getting the content processed.  The latter was
> distinguished to provide a means of improving accountability if there
> were problems.  When SMTP was created, later, MailFrom was added as an
> address for sending message handling reports.
> 
> When first specified, Sender: was to cover the case of someone doing
> the online work, on behalf of  authors who weren't online, or at least
> not online for processing the message.  Back in those days, that was
> not uncommon.  Even if the author officially had an online presence,
> they often did not do the typing.
> 
> (To underscore this a bit: in most of the business world, knowing how
> to type was deemed a menial, secretarial skill and not appropriate for
> an executive. To carry this a bit further: around the time RFC733 was
> developed, in 1977, I managed to get the person in charge of
> department administration functions to authorize my getting a desk
> with a right-hand return, where a secretary's typewriter would go, and
> where I put my terminal. This was extremely unusual and the immediate,
> similar requests from all the other staff like me were rejected. Also,
> when I announced my departure, the next year, the admin was instantly
> flooded with requests for my desk...)


Thank you for sharing the above historic perspective.


> [...]
> 
> So, in abstract terms, if I go to a greeting card site and have it
> send a greeting on my behalf, the From: field should be my own email
> address and Sender: should an address at the greeting card company. 
> But I said 'abstract' because current realities mean this isn't as
> useful an arrangement as the theory intended.


Agreed.  I'd derive it's time to revise the theory, however slightly.


> I believe this is because Sender: is not reliably present. Hence, it
> literally cannot be relied upon.  The Sender field is not created
> reliably to indicate such distinctions and the receive side does not
> reliable note the distinctions.


The fact that it cannot be set by a MUA implies Sender: already lost
its menial meaning.  So it became a Mediator sort of thing.  This list
sets it to "dmarc" <[e-mail]>.  Does anybody use it, or
ever happened o take a look at it?

See below for an alternative arrangement.


>> For a newspaper, if you pardon the analogy, the masthead is more
>> visible than columnist signatures at the end of the articles.  For a
>> mailing list, publisher visibility used to be provided by subject
>> tags, leaving the From: intact.  Why?  Presumably, because it just
>> worked that way.  However, if the MLM is the system responsible for
>> writing, not modifying From: should be considered a violation.
> 
> If a Mediator makes 'substantial' changes to a message, then it can be
> considered a new and different message?  Yes, but note that we have no
> objective criteria for this.  That's why I class this reference to
> 'publisher' as a business issue rather than a technical one.  (And an
> ethical one, as some wayward journalists discover when they claim to
> be quoting someone but it turns out the reporter invented the content.)


You certainly recall the level of sophistication described in Nelson's
Literary Machines.  Email is nowhere near that precision, therefore we
/have/ to relegate such issues to ethical or business ones.

As you say, an add-on to check quotation authenticity would require
access to the whole thread, and even then it wouldn't be trivial to
get it done.


> However I think that referencing the role of an MLM as 'publisher' can
> be helpful to remind us that MLMs have their own agency and can,
> legitimately, make all sorts of changes.  Whether authors and
> recipients like those changes is a non-technical matter.
> 
> The practical problem with From: field munging by MLMs that are
> otherwise trying to relay a largely-unmodified messages, is that they
> effective destroy author information, by putting in a different email
> address.
> 
> In practical terms, today, the MLMs arguably don't have a choice.  But
> it still can be helpful to understand the problems created by this
> alternation.


IMHO, the choice is how to do rewriting given the constraint that the
domain of From:'s addr-spec must match d= in MLM's signature.


>>> My understanding of the meaning that DMARC added was, "The
>>> author of this message, as expressed in the From: field, always
>>> has their messages properly signed by the domain in the From:
>>> address." You seem to be saying that, no, what DMARC did was
>>> changed the semantic to be, "The From: field now represents the
>>> transmitter of the message (as used to be expressed in the 
>>> Sender: field when present), not the author, and that
>>> transmitter always has their messages properly signed by the
>>> domain in the From: address".>
> For reference, I consider this an accurate summary of why I say that
> the From: field semantic is changed as a result of DMARC. Specifically
> so that mailing list mail can be delivered.


Yes.


>> Sender: was not meant to be the transmitter in that sense.  It was
>> meant to be the secretary who writes on behalf of a responsible
>> person or system.
> RFC 5322 has preserved the semantic of the Sender: field:
> 
>      "The "Sender:" field specifies the mailbox of the agent
> responsible for the actual transmission of the message. "
> 
> I consider that to be exactly the role the MLM is performing.


Sender ID already tried that path.  It didn't work.  Why insist?

For the rationale, that quoted sentence of RFC 5322 is followed by an
example which doesn't seem to match a Mediator role.  Why not use the
Resent-From: field and its companions instead?


>> RFC 5322 says display names are "associated" to a mailbox.
> 
> I don't see such language in RFC 5322.  In fact, other than the ABNF
> for display-name, I don't see any explanation of its semantic.


    Note: Some legacy implementations used the simple form where the
    addr-spec appears without the angle brackets, but included the
    name of the recipient in parentheses as a comment following the
    addr-spec.  Since the meaning of the information in a comment is
    unspecified, implementations SHOULD use the full name-addr form of
    the mailbox, instead of the legacy form, to specify the display
    name *associated* with a mailbox.  Also, because some legacy
    implementations interpret the comment, comments generally SHOULD
    NOT be used in address fields to avoid confusing such
    implementations.
                    [https://tools.ietf.org/html/rfc5322#section-3.4]
                    [(my emphasis)]


>> Certainly, changing just the addr-spec breaks the association and
>> wreaks havoc to address books. 
> 
> Exactly.


Here's an alternative arrangement for the fields:

An author composes a message and submits it to the MLM.  The publisher
can accept it or not.  It's their business policy whether to moderate,
blindly trust (some) authors, or whatever.  If they accept the
article, then they send it back to the author, accompanied by the
MLM's marks of acceptance for publication.  Hence, From: the MLM, To:
the author, Bcc: the rest of subscribers.

That arrangement saves the association and the ability to reply all.

There is an unusual MLM option to individually send messages To: each
recipient, which neither supports the above arrangement nor advanced
sending schemes, such as Courier-MTA's VERP SMTP extension.


Best
Ale
--