Re: Strong objection to draft-ietf-WG-*.all noise levels

Robert Sparks <> Mon, 09 February 2015 20:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 03D921A886E for <>; Mon, 9 Feb 2015 12:12:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LkTL9RT5FjOI for <>; Mon, 9 Feb 2015 12:12:15 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F3C01A8736 for <>; Mon, 9 Feb 2015 12:11:42 -0800 (PST)
Received: from unnumerable.local ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id t19KBfgD098880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Mon, 9 Feb 2015 14:11:42 -0600 (CST) (envelope-from
X-Authentication-Warning: Host [] claimed to be unnumerable.local
Message-ID: <>
Date: Mon, 09 Feb 2015 14:11:36 -0600
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
Subject: Re: Strong objection to draft-ietf-WG-*.all noise levels
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Feb 2015 20:12:17 -0000

Hi Brian:

There are a couple of moving targets in what you're objecting to that I 
think we need to be careful to tease apart.

Here's a bit of detail to help with that (I hope):

1) the .all alias includes any address that is covered by any other 
generated alias (currently that's .authors, .chairs, .ad, and .notify)

2) the .notify alias is populated directly from the Notify field for a 
draft in the tracker. You can see what that's currently set to for a 
draft by looking at the "Send notifications to" line on the document's 
main page.

3) The IESG directed that when a working group draft begins IESG 
processing, the working group be added to the notify field by default. See

So, I _think_ the conversation you need to be having to address your 
objection is with the IESG on the decision to add the group to the 
default notification list.

That said, there are some things we're doing to the aliases to make 
where things are coming from easier to figure out. None of what's below 
will change whether a working group gets the state-change notifications, 
but it may help explain other aspects of what you've been recently seeing.

4) We're working on providing pages that show the expansions of the 
aliases at similar to the pages that are at 
This isn't happening immediately because the mail processing systems are 
different, and there are some extra gears that we're having to incorporate.

5) The most recent datatracker releases have made incremental changes to 
the way the aliases are used. In particular, mail sent through the 
aliases should end up with fully expanded To header fields at this 
point. We are also working on adding the fields (already present when 
using aliases) that make it easy to see exactly what 
alias got invoked.

6) From the links above, you'll see that part of the  original 
implementation was to add .all to the Notify field (in addition to the 
working group). That led to some trouble since .all contains .notify - 
there's an include loop, and some of the dynamics of integrating with 
the mail handling at vs led to not catching 
that loop in the right place (this was affecting a few drafts last 
week). This has been addressed, both by more careful loop protection, 
and by changing what gets put in Notify to not use .all directly.

Again, those last 3 items are just part of the context - they don't 
affect the primary concern you're raising. That lives solidly with 
spirit of the decision at item 3) above.


On 2/9/15 1:00 PM, Brian E Carpenter wrote:
> Hi,
> I see that the tracker has started using email aliases of the
> form draft-ietf-WG-* to report on state changes,
> and that these aliases now apparently include the WG as well
> as the interested parties.
> This is highly obnoxious. One problem is that for most recipients
> the messages are pure noise (and any follow-up messages whose CC
> list isn't manually pruned are additional noise). Another problem
> is that they are in effect BCC'ed to the WG, so existing filters
> don't catch these messages. A consequent problem of that is that
> many people are likely to do what I'm about to do: figure out how
> to spam filter all this noise, thereby risking to miss any such messages
> that actually matter.
> Please please please remove the WG lists from these aliases.
> If something really needs to be brought to the WG's attention,
> there are people who know they should do that.
> Regards
>     Brian Carpenter