Re: (DMARC) We've been here before, was Why mailing lists

Martin Rex <mrex(_at_)sap(_dot_)com> wrote:
    >> Every attempt to create a signing scheme that is flexible enough to deal
    >> with all the routine stuff that lists do (e.g., reorder, discard, or
    >> flatten MIME parts while adding the usual subject tags and body footers)
    >> while being robust enough to prevent bad guys from replacing the message
    >> with spam has completely failed.  We can try again, but I don't see any
    >> reason to think that the result would be any different.


    > I fail to understand where the problem comes from.  The idea/architecture
    > of the rfc822 "sent on behalf of" (Sender:) seems clear.  If anything
    > should be authenticated at all, then it is what _the_sender_ decides
    > to send.

    > The sender might be asserting the authorship of the message (plus or
    > minus a few bits) to someone else by including the authors name in
    > a From: field that differs from the Sender: field.

So, the bug is that Yahoo/DMARC/ are authenticating the From:, when it should
really be authenticating the Sender:. DMARC should key it's policy from
Sender: rather than From, and if it did that then:
  1) we could leave the From: intact, which is what's good for the end
     users.
  2) the list would change the Sender:, which is what we would establish
     the reputation of the list, not the From:
  3) MUAs would compare the From: and Sender:, and if they differed,
     could say useful things like:

     "From: Mrex(_at_)sap(_dot_)com via ietf(_at_)ietf(_dot_)org".

(I was also wondering this morning on my commute if a layer of message/rfc822
added by the mailing list might be a useful interim hack)

    > A technology that is obsessed about the contents of the From:-Field
    > of an rfc822/2822/5322 Email message that ignores the semantics of
    > the Sender: field appears broken to me.  A sender that received
    > the original EMail with a signature might indicate so (and authenticate
    > this indication), but unless the original message is included verbatim
    > an opaque blob, the original signature may no longer work -- such as
    > when a mailing list software cleans/streamlines submissions, so the
    > original signature should be stripped.

    > MUAs which are not implementing the rfc822/2822/5322 "on behalf of"
    > semantics of a message that carries both From: and Sender: header
    > fields ought to be FIXED.  Standards that build on rfc822/2822/5322
    > and do not respect "on behalf of" semantics of messages with
    > both "Sender:" and "From:" also need to be FIXED.

Is "on behalf of" part of the specification...  not literally using those
words, which is a shame, because I think that it's really good wording.
section 3.3.6 says:

   The resent originator fields indicate the mailbox of the person(s) or
   system(s) that resent the message.  As with the regular originator
   fields, there are two forms: a simple "Resent-From:" form, which
   contains the mailbox of the individual doing the resending, and the
   more complex form, when one individual (identified in the "Resent-
   Sender:" field) resends a message on behalf of one or more others
   (identified in the "Resent-From:" field).

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr(_at_)sandelman(_dot_)ca  http://www.sandelman.ca/        |   ruby on 
rails    [



--
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

pgp7gh_9VSzHY.pgp
Description: PGP signature