--On Saturday, December 17, 2016 08:39 -0800 S Moonesamy
<sm+ietf@xxxxxxxxxxxx> wrote:
> Hi Ted,
> At 07:56 17-12-2016, Ted Lemon wrote:
>> Yes. And changing it to the mailing list also has problems
>> in terms of readability. How about:
>>
>> For First Last via Listname <listaddress@xxxxxxxxxxx>
>>
>> This is brief, avoids the autocomplete fail, and gets the job
>> done.
>
> The above adds a string to prevent the auto-complete feature
> from adding an email address which is not the author's email
> address. At this stage it is worthwhile to consider the idea.
>
> The bounce problem [1] is a case of the IETF violating an IETF
> "standard".
Maybe this is what you meant by the scare quotes, but the IETF
has been fairly clear -- in RFC 5321 and 5322 and elsewhere--
that
(1) Mailing lists can be handled at MTA level, in which case the
backward-pointing envelope address is changed to point to the
list but that, other than adding trace information (including
List identification), the headers and message body should be
unchanged.
(2) Mailing lists can also be handled at MUA level, in which
case "Resent-" fields are added, possibly also with List
information, but the header "From:" and "Sender:" fields are to
be unchanged.
(3) Because we deliberately do not have standards about what an
MUA can do -- precisely because it is ultimately an agent acting
on behalf of the end user -- such a system can plausibly
construe such a message as being received, modified as desired,
and then forwarded to a list of others. Again, there is no
standard, but treating mailing list traffic that way opens up a
whole series of potential attacks because, if the "MUA can make
changes" model is applied, nothing prevents such an MUA from,
e.g., changing every instance of "black" in the message body to
"white".
(4) We have never encouraged anything that attributes semantics
to either a name phrase (<display-name> in RFC 5322-speak).
While we have never taken a position about auto-complete and
populating address books based on those fields, doing the latter
is fraught with risks, particularly if all I need to do to
divert mail from Ted to you to an attacker is to send him a
message with a "From:" header field of
S Moonesamy <evil-SM@xxxxxxxxxxx>
See my other message about the principle at work here.
john