Martin Rex <mrex@xxxxxxx> 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@xxxxxxx via ietf@xxxxxxxx".
(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@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
pgptkdBXsDnsJ.pgp
Description: PGP signature