Subject: Re: Upcoming change to announcement email header fields (using old header)

From: John C Klensin <[email-masked]>
Date: Thu, 09 Jan 2014 12:24:33 -0500

--On Thursday, January 09, 2014 06:00 -0800 The IESG
<[email-masked]> 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 <[email-masked]>
>    To: IETF-Announce:;
>    Reply-To: IETF Discussion List <[email-masked]>
> 
> and the message sent using the New header fields will also be 
> Bcc-ed to <[email-masked]>

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

---

From: Dave Cridland <[email-masked]>
Date: Thu, 9 Jan 2014 17:39:26 +0000

> Three observations based on some small experience with Internet
I'll add one.

Much as I adore the almost wonderful irony of "The IESG" having an address
of <[email-masked]> - especially in the light of John's closing comment
there - many MUAs will then cheerfully offer that as an address for "The
IESG".

If that is a dev-null address, as noreply@ often implies, it'll become a
self-fulfilling prophecy of sorts. You might want a different phrase, there
- "IESG Announcements", or something.

Dave.

---

From: SM <[email-masked]>
Date: Thu, 09 Jan 2014 10:59:35 -0800

Hi Dave,
At 09:39 09-01-2014, Dave Cridland wrote:
>Much as I adore the almost wonderful irony of "The IESG" having an 
>address of <[email-masked]> - especially in the light of John's 
>closing comment there - many MUAs will then cheerfully offer that as 
>an address for "The IESG".

:-)

http://www.ietf.org/mail-archive/web/ietf/current/msg78806.html

>If that is a dev-null address, as noreply@ often implies, it'll 
>become a self-fulfilling prophecy of sorts. You might want a 
>different phrase, there - "IESG Announcements", or something.

My guess about the problem is that people choose "Reply to 
All".  That generates more mail for iesg-secretary@.  Using a few 
(sieve) rules might alleviate the problem.

Regards,
-sm

---

From: [email-masked]
Date: Thu, 09 Jan 2014 14:22:47 -0800 (PST)

> (sieve) rules might alleviate the problem.

There's even a sieve draft in WGLC that may be relevant:

    draft-ietf-appsawg-sieve-duplicate-02.txt

				Ned

---

From: Pete Resnick <[email-masked]>
Date: Fri, 10 Jan 2014 00:36:34 -0600

On 1/9/14 11:24 AM, John C Klensin wrote:

> group syntax...

John, several people were spoken to, including myself, and my 
understanding along with what I heard of the current collective wisdom 
was that the number of such custom coded systems that would be adversely 
affected by an empty group address in the To: field and actual addresses 
in the From: and Reply-To: (albeit the From: containing a bit-bucket 
address) would be exceedingly small and at pretty low risk. So my 
recommendation to the tools team was to go ahead with the experiment.

(As you may have been aware, there was an earlier attempt to change the 
headers of announce messages, but it -- unfortunately -- happened 
without an experimental phase. But most of the problems there had to do 
with normal filters that were unprepared for the change. Hence the 
experimental step this time.)

If we discover problems, we'll figure out something differently. But 
there are downsides to including bogus addresses (as against empty 
groups) in To: fields, so I think this is worth the attempt.

> than the apparent "the IESG  decided on this and is announcing it to the community".
>    

Most of the IESG was not involved in "deciding" this. The tools team 
worked with Barry and I, and we all consulted with other folks (well 
known to you) and recommended the experiment go forward. And to address 
your later comment: We don't want tools work (or other administrative 
activities) to require open IETF list discussions for every change, so 
sometimes the admin folks will consult with senior and experienced 
members of the community and go ahead with experiments of this sort. 
That it came out as an "IESG" announcement in this case is really 
accidental: The tools team asked the IESG for its approval (and the Apps 
ADs' advice) because the email messages at issue were IESG 
announcements. But this was far from some sort of super-secret top-down 
pronouncement. I'm sorry that it appeared that way.

> 1/2 weeks are unlikely to be sufficient.

Fair enough. I think extending the experiment would not be a big deal.

On 1/9/14 12:59 PM, SM wrote:
> My guess about the problem is that people choose "Reply to All".  That 
> generates more mail for iesg-secretary@.  Using a few (sieve) rules 
> might alleviate the problem.

It's not just a "more mail for iesg-secretary@" problem. Email to that 
address goes directly into a ticketing system, which unfortunately 
generates a new ticket if the subject line does not contain the correct 
ticket number. Then the secretariat has to go back and combine the 
tickets if the replies were relevant to the secretariat, or toss them if 
they were replies intended for the IETF list. Furthermore, you get 
bounces generated from the announce list (which persist when you get 
replies to replies), though sometimes you get the random message slip 
through to the announce list because of accidental non-moderation of the 
message. Not all of these can be handled (easily) with a simple sieve 
script.

Again, if the experiment flops, we'll re-group. But I'm somewhat hopeful.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Jan 2014 05:17:22 -0500

--On Friday, January 10, 2014 00:36 -0600 Pete Resnick
<[email-masked]> wrote:

>> 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...
> 
> understanding along with what I heard of the current
> collective wisdom was that the number of such custom coded
> systems that would be adversely affected by an empty group
> address in the To: field and actual addresses in the From: and
> Reply-To: (albeit the From: containing a bit-bucket address)
> would be exceedingly small and at pretty low risk. So my

If this is an experiment, the announcement doesn't make that
clear.  There is no statement of how to report issues that can't
easily be fixed, etc., just a date certain for the switchover.

As to "exceedingly small", are you measuring percentages?
Absolute numbers?  How many contributors and reviewers is the
IESG prepared to lose if they can't get announcements with a
reasonable amount of effort?  A few hundred (a small number
relative to the size of the IETF-Announce distribution)?  A few
dozen (an "exceedingly small" number on the same scale)?  Ten?

> Most of the IESG was not involved in "deciding" this. The
> tools team worked with Barry and I, and we all consulted with
> other folks (well known to you) and recommended the experiment
> go forward. And to address your later comment: We don't want
> tools work (or other administrative activities) to require
> open IETF list discussions for every change, so sometimes the
> admin folks will consult with senior and experienced members
> of the community and go ahead with experiments of this sort.
> That it came out as an "IESG" announcement in this case is
> really accidental: The tools team asked the IESG for its
> approval (and the Apps ADs' advice) because the email messages
> at issue were IESG announcements. But this was far from some
> sort of super-secret top-down pronouncement. I'm sorry that it
> appeared that way.
 
>> and are dependent on a third-party supplier to get it
>> patched, 2 1/2 weeks are unlikely to be sufficient.

> Fair enough. I think extending the experiment would not be a

Again, the announcement didn't imply an experiment to me, only a
"here it comes, get ready or be prepared to lose" declaration.

>> All".  That  generates more mail for iesg-secretary@.  Using
>> a few (sieve) rules  might alleviate the problem.
> 
> It's not just a "more mail for iesg-secretary@" problem. Email
> to that address goes directly into a ticketing system, which
> unfortunately generates a new ticket if the subject line does
> not contain the correct ticket number. Then the secretariat
> has to go back and combine the tickets if the replies were
> relevant to the secretariat, or toss them if they were replies
> intended for the IETF list. Furthermore, you get bounces
> generated from the announce list (which persist when you get
> replies to replies), though sometimes you get the random
> message slip through to the announce list because of
> accidental non-moderation of the message. Not all of these can
> be handled (easily) with a simple sieve script.

It also creates the impression that the IESG Secretary is
responsible for the announcement and that messages questioning
the contents of the announcement should be sent to that address.
No accidents involved.  As you may know, I made that assumption
after a perceived problem some days ago and, assuming that "IESG
Secretary" was actually a human (she certainly was the last time
I talked with her), even copied the "action" address, thereby
generating two tickets.   So putting that particular address
there is clearly a bad idea.  But that conclusion justifies the
new "noreply" address and an ingress filter at ietf.org which
discards any mail sent to that address, not the rest of the
changes.

> Again, if the experiment flops, we'll re-group. But I'm

Thanks for the reply.

   best,
     john

---

From: Hector Santos <[email-masked]>
Date: Fri, 10 Jan 2014 11:56:41 -0500

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

-- 
HLS