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. - +1 (858)651-4478