Hi,
I hope I am not butting in on something here, but our Mailing List
Software (MLS) is among those that offers a "Reply-To: <list-address>"
list admin option for a submission distribution. This was done
primarily because early on most, if not all MUAs, had UI reply buttons
such as:
REPLY -> goes to Reply-To:, if any, otherwise From:
REPLY TO ALL -> goes to all originating fields, From:, Reply-To:, Cc:
So for the layman end-user whose natural response action was to click
a REPLY, the response went direct to the author and not the mailing
list which is what he probably wanted.
On the other hand, he had to be aware of this and click REPLY TO ALL
and now he had to be keen to the idea of multiple replies, whether to
edit the fields (reduce to the list address) or not, consider who does
it piss off, who doesn't care one bit about it, it varies here, or
whether he wanted to make sure the author got his response and not
depend on someone always reading the list, etc, etc.
So there was many "mail reply ergonomic" reasons for having special
Reply-To: feature in mailing list -- to better support the MUAs.
After all, a Mailing list is technically a kludge for using the
direct/private, one to one, mail system as opposed to NNTP which is
naturally a Groupware, one to many framework.
Having this feature was a god-send for us (for support mailing lists)
and for our customers using our MLS.
But it was a sensitive concept with some, who didn't like the idea
that an author defined Reply-To: header was effectively altered for a
list distribution. So there was pros and cons, and by far, IMO the
pros outweigh the cons.
Today, what I have noticed is that more and more updated MUAs are
supporting 5322.the List-* headers which most list distributions now
add. Now you see a third button with some of the modern MUAs:
REPLY TO LIST -> uses the list-post: header
I presume the REPLY TO LIST button would be disabled if the List-Post:
header is missing.
So perhaps the changes below should note that there are LIST-* headers
that modern RFC-based internet MUAS "SHOULD" be using.
Thanks
--
HLS
On 1/9/2014 12:24 PM, John C Klensin wrote:
--On Thursday, January 09, 2014 06:00 -0800 The IESG
<iesg-secretary(_at_)ietf(_dot_)org> wrote:
We will soon be changing the header fields used in IETF Last
Call messages sent to the IETF Announce mailing list.
...
This message will be repeated daily using both the old and new
header. This instance of the message was sent using the old
header. Please ensure you receive both versions.
These messages will cease, and all Last Call messages to this
list will switch to using the new header on or shortly after
2014-01-24.
...
The specific changes are:
...
New:
From: The IESG <noreply(_at_)ietf(_dot_)org>
To: IETF-Announce:;
Reply-To: IETF Discussion List <ietf(_at_)ietf(_dot_)org>
and the message sent using the New header fields will also be
Bcc-ed to <ietf-announce(_at_)ietf(_dot_)org>
Folks,
Three observations based on some small experience with Internet
mail and various MUAs.
(1) If someone is going to have or detect problems with this
change, it would be very useful to identify what you are putting
in the envelope, especially the backward-pointing parts of the
envelope. If someone had to start tracking through logs to
identify what happened to a missing message, knowing, e.g.,
whether ietf or AMS domains were being used in EHLO and MAIL
command arguments might be a big help.
(2) Especially given the history of configuration failures that
have periodically allowed random parties to post messages or
replies to IETF-Announce, the reasons for the change in "From:"
and "Reply-to;" fields are obvious and probably should have been
thought of and adopted years ago. The posting filters will
still be needed (I hope we are not going to rely on the security
through obscurity of a secret address), but this should at least
stop the accidents.
However, despite the fact that group syntax, including that for
empty lists, has been part of the mail header specs for well
over 30 years, we know that many systems have had trouble with
messages that contain only an empty group indication. Those
systems are not just non-conforming MUA or mailstore
implementations (or MTAs that violate the SMTP spec and look at
headers in transit) or antispam systems of various qualities.
They including a variety of coded and ad hoc mail classification
and filtering arrangements that may require special arrangements
for such addresses. Given the risks and potential problems,
I'd like to hear a little more justification for switching to
group syntax than the apparent "the IESG decided on this and is
announcing it to the community".
(3) If someone actually does discover that they have a problem
and are dependent on a third-party supplier to get it patched, 2
1/2 weeks are unlikely to be sufficient.
I hope this comment doesn't turn into a distraction, but, when
announcements like this appear with no prior discussion with the
community, I wonder what the process was that produced the
decision and whether we've abandoned the principle that the IESG
is supposed to be steering and determining and reflecting
community consensus, not making decisions and pronouncements in
secret and top-down.
best,
john
--
HLS