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

[Pete Resnick <[e-mail]>]

On 1/9/14 11:24 AM, John C Klensin 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...

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.

> (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.
>    

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. - [phone]