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