Subject: subject_prefix on IETF Discuss?

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Aug 2011 12:22:04 -0400

Hi all,

I seem to remember discussions about this a long time ago, but searching through archives gets no love...

How do folk feel about having asking for subject_prefix to be set on the IETF Discussion List (AKA this one!) - this will prefix mail sent to this list with something like "[Discussion]" or "[IETF]" or something [0].

Background: I used to just filter this list into a mailbox / folder (based upon List-Id:), but then I would forget to read it, so I have removed that procmail rule. Having a prefix would make it easier to tell at a glance what list the mail is associated with, what it might be about, etc. Yes, I *could* just make a procmail rule to munge the subject myself, but that seems icky, and solving it for the general case (and making Discussions more like the other IETF lists feels better).

W

[0]: Let the bike-shedding on actual prefix used begin...

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Aug 2011 09:35:16 -0700

> How do folk feel about having asking for subject_prefix to be set on the IETF Discussion List (AKA this one!) - this will prefix mail sent to this list with something like "[Discussion]" or "[IETF]…

+1

The visual cue this convention provides is helpful and it's an extremely 
widespread convention.

[Discussion] could apply to any group, anywhere, whereas  [IETF] nicely 
identifies exactly this list.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Aug 2011 10:37:00 -0600

On 8/3/11 10:35 AM, Dave CROCKER wrote:
> 
>> How do folk feel about having asking for subject_prefix to be set on
>> the IETF Discussion List (AKA this one!) - this will prefix mail sent
>> to this list with something like "[Discussion]" or "[IETF]" or
>> something [0].
> 
> 
> +1
> 

Yes please!

/psa

---

From: Peter Koch <[email-masked]>
Date: Wed, 3 Aug 2011 18:40:34 +0200

On Wed, Aug 03, 2011 at 09:35:16AM -0700, Dave CROCKER wrote:
> 
> >How do folk feel about having asking for subject_prefix to be set on the 
> >IETF Discussion List (AKA this one!) - this will prefix mail sent to this 
> >list with something like "[Discussion]" or "[IETF]" or something [0].

> The visual cue this convention provides is helpful and it's an extremely 

maybe we should eat our own dog food as served in RFC 2919 or,
to touch another popular issue, declare 2919 "Historic"?

-Peter

PS: <http://tools.ietf.org/html/draft-koch-subject-tags-considered-00>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Aug 2011 10:48:48 -0600

> PS: <http://tools.ietf.org/html/draft-koch-subject-tags-considered-00>

Given that almost all of the WG lists have subject prefixes, it seems
most folks find your arguments less than compelling.

/psa

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Aug 2011 09:56:06 -0700

> to touch another popular issue, declare 2919 "Historic"?

Peter,

That's a rather odd suggestion to make

    *  in a message that conforms to that RFC

    *  with many of us using mail software (such as Thunderbird) that detects 
List-* fields and adapts, such as offering a "Reply List" command when present

So...

    -1.

d/

ps.  Besides its being benign to have redundant indication of list handling, the 
different conventions serve different purposes.

-- 

   Dave Crocker

---

From: David Morris <[email-masked]>
Date: Wed, 3 Aug 2011 10:13:58 -0700 (PDT)

On Wed, 3 Aug 2011, Warren Kumari wrote:

> IETF Discussion List (AKA this one!) - this will prefix mail sent to
> this list with something like "[Discussion]" or "[IETF]" or something
> [0].

I'd REALLY like such a tag ... almost all the other lists I subscribe to
use such a prefix. [IETF] would be my preference. Short is good. I'm
happy to let those who prefer to not have such a prefix setup their
procmail rules to remove it. <-:)

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 03 Aug 2011 20:17:24 +0300

03.08.2011 20:13, David Morris wrote:
> procmail rules to remove it.<-:)

+1.  I approve of such idea.  Mykyta

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 03 Aug 2011 19:20:54 +0200

> procmail rules to remove it.<-:)

s/procmail rules/sieve filter/

:-)

/rolf

---

From: todd glassey <[email-masked]>
Date: Wed, 03 Aug 2011 10:55:49 -0700

>> The visual cue this convention provides is helpful and it's an extremely
This would allow the IETF mailers to identify and for the rest of us to 
better setup SUBJECT Filters for our mailing so this makes sense and is 
an easy fix which has been requested several times over the last couple 
of years.

todd
> PS:<http://tools.ietf.org/html/draft-koch-subject-tags-considered-00>

-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

---

From: [email-masked]
Date: Wed, 03 Aug 2011 10:53:08 -0700 (PDT)

> to touch another popular issue, declare 2919 "Historic"?

The IETF list already inserts the all the proper list- headers:

 List-Id: IETF-Discussion <ietf.ietf.org>
 List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>,
  <mailto:[email-masked]?subject=unsubscribe>
 List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
 List-Post: <mailto:[email-masked]>
 List-Help: <mailto:[email-masked]?subject=help> 
 List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
  <mailto:[email-masked]?subject=subscribe>

It's all I need for sorting and, for that matter, I can trivially set up rules
to add the [ietf] or whatever tag myself if I prefer that. As others have
pointed out, we even have a standard for doing this stuff.

OTOH, I can also remove the [ietf] tag if the list starts putting it in there.
So count me as mildly disliking this proposal.

> PS: <http://tools.ietf.org/html/draft-koch-subject-tags-considered-00>

Pretty much agree with the points raised in this draft.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 3 Aug 2011 18:21:23 -0000

>> procmail rules to remove it.<-:)

Gee, I was about to say I was happy for people who want a subject tag
to add one using procmail or whatever.

I'm not unalterably opposed to subject tags, but I believe that the
IETF's dogfood is of the List-ID: flavor.

R's,
John

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Aug 2011 12:28:29 -0600

> IETF's dogfood is of the List-ID: flavor.

Which WG list do you suggest should be the guinea pig? Or shall we
change them all at once to remove the dreaded subject prefix? :)

/psa

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 3 Aug 2011 21:44:16 +0300

> IETF's dogfood is of the List-ID: flavor.

Yes.  It follows the same construction, and rationale, of not messing around with the Reply-To: field, when enough information is available in list software-specific headers to build whatever user indications or reply functionality is required.

But I do understand people's desire of these sorts of tags, and I know for a fact that many commonly-used UAs simply have neither the filtering nor display capabilities to resist them.  So I would not oppose a general motion to make this change.  It's one less nice thing about the ietf list, though.

-1 +/- 0.25

Cheers,
Sabahattin

---

From: "John R. Levine" <[email-masked]>
Date: 3 Aug 2011 14:47:32 -0400

> change them all at once to remove the dreaded subject prefix? :)

I said I'm not unalterably opposed.  My advice would be to leave well 
enough alone.

If the IETF used a better list manager, the subject tag would be a 
per-user option, but noooo ...

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Aug 2011 21:26:39 +0200 (MEST)

Peter Saint-Andre wrote:
> John Levine wrote:

What exactly are you discussing?  List-Id: is present on this list
already, and the WG mailing lists I'm subscribed to have both,
List-Id: and subject_prefix.

subject_prefix will work even with very ancient MUAs, such as the
one I use, so I'm OK.  But the subject_prefix does not scale well
when multiple IETF mailings lists are CC-ed and discussion ensues
(replying to all lists).

Will a subject_prefix confuse MUAs that support "threading" for
cross-posted discussions?

-Martin

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 03 Aug 2011 21:46:54 +0200

* Warren Kumari wrote:
>Background: I used to just filter this list into a mailbox / folder
>(based upon List-Id:), but then I would forget to read it, so I have
>removed that procmail rule. Having a prefix would make it easier to tell
>at a glance what list the mail is associated with, what it might be
>about, etc. Yes, I *could* just make a procmail rule to munge the
>subject myself, but that seems icky, and solving it for the general case
>(and making Discussions more like the other IETF lists feels better).

If you would like your mail client to identify the mailing list next to
the subject header, then it seems your client should just do that, which
would avoid all the problems munging the subject header entails. Seems
to be a popular feature aswell, so I'd think clients support this...
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Aug 2011 14:45:12 -0600

> when multiple IETF mailings lists are CC-ed and discussion ensues

"Doctor, it hurts when I do that."

/psa

---

From: Tony Hansen <[email-masked]>
Date: Wed, 03 Aug 2011 17:44:27 -0400

> How do folk feel about having asking for subject_prefix to be set on the IETF Discussion List (AKA this one!) - this will prefix mail sent to this list with something like "[Discussion]" or "[IETF]…

-1 cause it breaks signatures

This might be mitigated if authentication-results support were added.

     Tony Hansen

PS. I do my sorting based on the To/Cc field as much as anything.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 03 Aug 2011 23:39:35 +0100

> PS. I do my sorting based on the To/Cc field as much as anything.

I do Sieve to assign IMAP keywords based on the List-Id header field  
which my MUA then uses to colourize differently in the summary  
listing based on the settings it finds in ACAP.

Do I win?

(I'm largely against subject prefixes, but not sufficient to jump up  
and down about).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Doug Barton <[email-masked]>
Date: Wed, 03 Aug 2011 15:40:26 -0700

> IETF's dogfood is of the List-ID: flavor.

+1 on both counts.

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: SM <[email-masked]>
Date: Wed, 03 Aug 2011 15:48:14 -0700

>most folks find your arguments less than compelling.

Not really, it's the default setting for the WG lists and nobody 
bothered changing the setting.  As mentioned in 
draft-koch-subject-tags-considered-00, the tag is ambiguous when used 
for list identification.

Discussions about subject tagging are rarely about compelling 
arguments; it's a religious debate.  The tagging was introduced due 
to the inability of a well-known MUA to implement RFC 2919 for 
messages sorting.  As time went by, people viewed it as the norm.

As this is a matter of local preference, it is better to leave it to 
the subscriber to add the subject tag if he/she believes that it is useful.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Wed, 03 Aug 2011 19:06:36 -0400

Dave Cridland wrote:
> which my MUA then uses to colourize differently in the summary listing 
> based on the settings it finds in ACAP.
> 
> Do I win?
> 
> (I'm largely against subject prefixes, but not sufficient to jump up and 
> down about).

+1, In theory I am against any mail alterations. But the list tag has 
helped MUAs that do not have rules filtering or the user is not savvy 
enough to figure out.  We avoided it for a long time in our list 
server product, and when it was finally added, it became and remain 
very popular. It is now the default setup for a new list.

I will say today, more MUA are aware of mailing list with automated 
unsubscribe features (by looking at the 5322.List-XXXXX added 
headers).  I personally use these to separate folders since the 
subject tag may be turned off by the server.

Some Negatives:

When DKIM was introduced, a mail integrity technology, now needed to 
work with a natural mail integrity breaking system. Even though DKIM 
offered a body tag (l=) feature to help exclude list footer text in 
the body hash verification process, changing the subject tag broke 
original signatures.

List resigners help alleviate this issue, but at the expense of losing 
original DKIM integrity information opening a loop hole for security 
concerns and potential interoperability issues with submission 
downlinks (members) with DKIM security support.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Keith Moore <[email-masked]>
Date: Wed, 3 Aug 2011 19:33:19 -0400

> How do folk feel about having asking for subject_prefix to be set on the IETF Discussion List (AKA this one!) - this will prefix mail sent to this list with something like "[Discussion]" or "[IETF]…

My preference is to not have these prefixes.  I have all of my list mail go to a separate folder for each list.  The subject prefixes just add clutter. 

That said, I realize a lot of people don't use mail folders and have dysfunctional user agents.  I'll be annoyed if a subject prefix is added, but I'll cope.

Keith

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 3 Aug 2011 16:41:18 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
> Sent: Wednesday, August 03, 2011 4:33 PM
> To: IETF list
> Subject: Re: subject_prefix on IETF Discuss?
> 
> My preference is to not have these prefixes.  I have all of my list
> mail go to a separate folder for each list.  The subject prefixes just
> add clutter.
> 
> That said, I realize a lot of people don't use mail folders and have
> dysfunctional user agents.  I'll be annoyed if a subject prefix is
> added, but I'll cope.

That about sums up my view as well.

---

From: Nathaniel Borenstein <[email-masked]>
Date: Thu, 4 Aug 2011 09:25:56 -0400

Yes.  No.  No.  Yes.  Maybe.  Let me elaborate.

On Aug 3, 2011, at 12:35 PM, Dave CROCKER wrote:

> The visual cue this convention provides is helpful and it's an extremely widespread convention.

+1.  The effect on users is completely different, even though the same information is in there somewhere.  And the least fortunate users are both stuck with unhelpful user agents AND not in a position to do the kind of processing that would add the tag automatically.  So adding the tag is good from a usability perspective.

On Aug 3, 2011, at 1:53 PM, [email-masked] wrote:

> .......It's all I need for sorting .....

Yes, this is step back from standards to informal practice, so adding the tag is bad from an IETF/formal perspective, though perhaps only mildly so.

> -1 cause it breaks signatures

It's certainly bad if it breaks signatures.  On the other hand, if we can preserve the authentication results so that we have confidence in both the sender and the list exploder -- including the different forms of the Subject: field -- that would be a nice technical exercise/demonstration and a reference DKIM-handling example for other list software.

So I think this largely depends on how hard someone is willing to work on it.    -- Nathaniel

---

From: Richard Kulawiec <[email-masked]>
Date: Wed, 3 Aug 2011 19:21:51 -0400

-1.

This list complies with RFC 2919, which alleviates the need for the
horrible, unscalable, obsolete, ugly kludge of Subject-line tags.
I suggest that anyone who really, *really* wants them on their copies
of messages arrange to have them added locally (perhaps by procmail or
similar) and not force them on those of us who have chosen mail processing
software that correctly uses List-Id.

---rsk

---

From: Warren Kumari <[email-masked]>
Date: Fri, 5 Aug 2011 12:45:06 -0400

> software that correctly uses List-Id.

Still a little confused how this morphed into a religious war on RFC 2919 / List-Id.  I *did* mention in the original post that I had been using List-Id to organize mail -- which would lead to folders with a few thousands of unread mails, which I would then unceremoniously dump, because it was just too much to deal with..

Subject-line tags allow me to just drop everything in the inbox and then, at a glance figure out what to read, and in what order. I then move the read stuff (and that that I don't care about) into separate mailboxes.

For those who want to do the same (regardless of whether your religious views), this little bit of procmail woks for me, ymmv:

# Add an [IETF] to messages to the IETF list.
:0 fw
* ^List-Id:[ ].*\<ietf\.ietf\.org\>
|/bin/sed -e 's/^Subject:[ ]*/Subject: [IETF] /'

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Aug 2011 17:25:39 -0400

--On Friday, August 05, 2011 12:45 -0400 Warren Kumari
<[email-masked]> wrote:

>> This list complies with RFC 2919, which alleviates the need
>> for the horrible, unscalable, obsolete, ugly kludge of
>> Subject-line tags. I suggest that anyone who really, *really*
>> wants them on their copies of messages arrange to have them
>> added locally (perhaps by procmail or similar) and not force
>> them on those of us who have chosen mail processing software
>> that correctly uses List-Id.
> 
> Still a little confused how this morphed into a religious war
> on RFC 2919 / List-Id.  I *did* mention in the original post
> that I had been using List-Id to organize mail -- which would
> lead to folders with a few thousands of unread mails, which I
> would then unceremoniously dump, because it was just too much
> to deal with..
> 
> Subject-line tags allow me to just drop everything in the
> inbox and then, at a glance figure out what to read, and in
> what order. I then move the read stuff (and that that I don't
> care about) into separate mailboxes.

Warren,

I don't want to participate in the religious war, partially
because what I do is in the "something else" category.  But what
you are describing could easily be modeled, perhaps even more
efficiently, in terms of a search or classification that uses a
combination of List-ID (and maybe even the identified list name)
and the subject line (and maybe other information) in a boolean
or even weighted-score-based search to organize mail.  We know
how to do those things -- e.g., they lie at the core of
so-called Bayesian anti-spam procedures.  

The problem, religion-independent, is that many of our MUAs
don't provide good capabilities for doing anything like that
because they don't present interfaces for any of compound
boolean search, weighted factor search, effective "like this
one" heuristic  search, or successive refinement search --
especially in conjunction with an easy-to-use "take everything
found and either tag it in a special way or put it in a separate
folder" mechanism.  Most or all of the bits for some of these
are in the SIEVE collection, but MUAs and servers that are good
at using them and make them easy for users are not widely
available, especially for users who have other requirements
(like good, conforming, IMAP support).

To take the current debate as an example, if a user has to
choose between filtering or organizing mail using List-ID and
using subject lines, something is fundamentally broken
regardless of which choice is made.

Singling you out only because you made the comment, I would
remind you that your employer's public mail system is a major
offender in concentrating on search, rather than folder
management, but not providing sophisticated or iterative
refinement search procedures (nor supporting SIEVE).  I would
encourage you to encourage the responsible folks to clean up
their act, both in the interests of those users and to set a
good example for the industry.

     john

---

From: Doug Barton <[email-masked]>
Date: Fri, 05 Aug 2011 14:56:50 -0700

> Subject-line tags allow me to just drop everything in the inbox and then, at a glance figure out what to read, and in what order. I then move the read stuff (and that that I don't care about) into…

To me it boils down to you saying in effect, "Here is my way of working
with e-mail, and I'd like the IETF to support it." If there was a way
that we could do that which had no impact on people who don't work that
way (such as the List-Id header) then I'd say go for it! But for those
of us who already filter our mail into folders these [tags] are useless
clutter that take up valuable screen real estate. If they break dkim
that's a whole 'nother category of problems. Personally I'd love to see
us be conservative in what we send, but I recognize that my view on this
is biased.

On some level I have sympathy for people who feel that they are stuck
with clients that don't have advanced features, but there are so many
competent clients available for free that it's hard for me to sympathize
with the view that "I need you to do this for me so that I can manage my
workflow better." When you add to that "If I filter to folders then I
just ignore the mail" it starts to sound a lot more like a personal
problem. :)

Doug

--

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Aug 2011 20:11:59 -0700

On 8/5/2011 2:56 PM, Doug Barton wrote:
> clutter that take up valuable screen real estate.

Doug,

Perhaps you missed the part about this being common practice, including for 
other IETF mailing lists?

You are already suffering with the useless clutter.  The incremental pain for 
you is going to be nil.

> If they break dkim that's a whole 'nother category of problems.

DKIM is designed for to deal with one posting and one delivery.  Mailing lists 
take delivery and re-post.  For almost all scenarios, DKIM was not intended to 
survive re-posting.

d/
-- 

   Dave Crocker

---

From: Doug Barton <[email-masked]>
Date: Mon, 08 Aug 2011 17:16:20 -0700

On 08/05/2011 20:11, Dave CROCKER wrote:
> Perhaps you missed the part about this being common practice, including
> for other IETF mailing lists?

Why yes Dave, this is my first time writing an e-mail, or participating
in a, what do you call them? Mailing list? So thanks for pointing that
out to me.

> You are already suffering with the useless clutter.  The incremental
> pain for you is going to be nil.

That's the argument of someone who thinks that the thing proposed is a
good idea. If you believed it to be a bad idea I'm sure that you
wouldn't be suggesting that we add to the incremental pain.

> DKIM is designed for to deal with one posting and one delivery.  Mailing
> lists take delivery and re-post.  For almost all scenarios, DKIM was not
> intended to survive re-posting.

I wasn't referring to the post from the originator to the list, I was
referring to the message posted from the list.

Doug

--

---

From: "John Levine" <[email-masked]>
Date: 9 Aug 2011 03:08:23 -0000

>referring to the message posted from the list.

The list signs the message on the way out, so the ietf.org signature
verifies.  If the original sender signed the message, his signature
won't verify but (to collapse several years of flamage on the DKIM
list) that's not a problem.

I still don't think we should add subject tags for the aforementioned
autotrofigiaskylousphagic reasons, but DKIM signs perfectly well
either way.

R's,
John

---

From: Doug Barton <[email-masked]>
Date: Mon, 08 Aug 2011 20:16:07 -0700

> autotrofigiaskylousphagic reasons, but DKIM signs perfectly well

Thank you for clarifying that.

--

---

From: Richard Kulawiec <[email-masked]>
Date: Mon, 8 Aug 2011 11:35:46 -0400

On Fri, Aug 05, 2011 at 12:45:06PM -0400, Warren Kumari wrote:
> Still a little confused how this morphed into a religious war on RFC 2919 / List-Id. 

I don't think it's a religious war: I think it's long since been
demonstrated that RFC 2919 (and 2369) including List-Id are not only
good ideas, but best practices, and that subject-line tags should
be deprecated/avoided/discouraged, because they're just a kludge.

That is, this is an issue of technical merit, not arbitrary whim.
So instead of bringing back the obsolete idea of subject-line tags, we
should instead be encouraging (a) all IETF lists *not* to use them, but to
use List-Id et.al. instead (b) all (relevant) mail software providers to
support them and (c) all (relevant) mail server providers to support them.
These mechanisms neatly solve a number of problems, and that better
positions everyone to tackle those that remain.

---rsk

---

From: Keith Moore <[email-masked]>
Date: Tue, 9 Aug 2011 12:04:56 -0400

+1

---

From: Martin Rex <[email-masked]>
Date: Tue, 9 Aug 2011 19:16:39 +0200 (MEST)

Richard Kulawiec wrote:
> should instead be encouraging (a) all IETF lists *not* to use them,

-2

List-Id: can be used to automatically archive EMails for mailing
list or other distributions which one reads only casually -- there
it saves manual work.

> but to

If one intends to actually *process* close to all of the Emails hitting
one's inbox in near real time, then List-Id:, and any pre-sorting based
on it, will _always_ slow down processing (unless the MUA or the processing
is flawed).

Whereas a subject prefix significantly facilitates tracking of stuff
in a single large inbox.  I'm getting 300+/day Emails and try to read >95%
of it (my company internal Email is completely seperate at ~30/day, though).

-Martin

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Aug 2011 14:56:55 -0400

> of it (my company internal Email is completely seperate at ~30/day, though).

This makes no sense to me, Martin.  Please explain why sorting based
on a subject prefix will work, while sorting based on a List-ID header
field will not.

Barry

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 10 Aug 2011 01:42:42 +0300

> on a subject prefix will work, while sorting based on a List-ID header
I think the idea is that having the Subject prefix will allow sorting by visual inspection of one folder - the Inbox - where List-id will not.  I'm guilty of that habit, too, I won't deny it.  But this is a  red herring - of course, if you can sort matching messages into a folder, you can visually tag them, too.  And you can sort them using headers not usually displayed as with those that are.  Using an existing header that's already displayed in an index is just a hack, (from majordomo days, not surprisingly, and meant as an aid to broken or ineffectual mail software) and the trick is to upgrade your MUA and list software, or make do with list folders otherwise.

Cheers,
Sabahattin

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Aug 2011 07:00:29 +0200 (MEST)

> on a subject prefix will work, while sorting based on a List-ID header

I do not sort EMail at all (my MUA does not support sorting).
subject_prefix _obviates_ sorting.

MUAs typically display the inbox with (status,sender,subject,received-time).

With subject_prefix I can quite easily tell apart discussions from several
IETF mailing lists, and it works with _every_ MUA with default settings.

-Martin

---

From: "t.petch" <[email-masked]>
Date: Thu, 11 Aug 2011 09:38:46 +0200

----- Original Message -----
From: "Martin Rex" <[email-masked]>
To: "Barry Leiba" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 10, 2011 7:00 AM

<tp>
Until you get a Last Call, which is cross posted to the WG list, and some
replies have
[wgfb] and some do not, and then it gets cross posted to SAAG and we get
[wgfb][saag] or [saag][wgfb] or [saag] or [wgfb] or ....  You could of course
request an update to all MUAs to ignore prefixes when collating.

But nope, prefixes are a dead technology; do not insert them on the IETF list
(speaking as one whose MUA, supplied by the manufacturer who supplies most of
the world's MUAs, cannot do anything with List-Id:-(.

Tom Petch
</tp>

-Martin

---

From: Richard Kulawiec <[email-masked]>
Date: Thu, 11 Aug 2011 10:22:03 -0400

> of it (my company internal Email is completely seperate at ~30/day, though).

Let me start with a preamble: I think that those of us who choose
to "drink from the firehose" by subscribing to many mailing lists
or newsgroups or RSS feeds, especially those with lots of traffic,
have by doing so taken upon ourselves the obligation of finding
and configuring the right tools to make our decisions work for us.
(And in a complementary way, I think those operating those resources,
have taken upon themselves the obligation to run those resources per
spec, e.g. -request per RFC 2142, List-Id per RFC 2919, and so on.)
When everyone does so, things work very smoothly...which is ummm, kinda
the reason that we have these standards.

Now, to the substance of what you've said:

I'm not surprised this presents difficulties: funneling all incoming
mail into one mailbox means that...all incoming mail is in one mailbox.
And while it's still possible to sort, tag, and filter that mail easily
if you have a quality mail client [1] those tasks aren't as easy as
they could be if that mail was in separate mailboxes.

So let me suggest this methodology, which isn't the right one or the
best one or anything like that, just one that works for me.  Decide which
mailing lists are important to you, which are less important, etc.
Use procmail to sort all incoming messages on a per-list basis into
individual files in directories named accordingly, e.g:

	high/outages
	medium/nanog
	medium/ietf
	medium/ip
	medium/infowarrior
	low/funsec
	low/nanog-announce

Now it's all pre-sorted by list, making it easy to peruse any of them,
and all the lists are organized by priority, making it easier to decide
which ones to read when you're pressed for time.  (It's also possible to
clone incoming messages with procmail so that you can also have a
single file that has copies of everything, just in case you want that.)

No need for subject-line tags.  And everything is nicely separated so
that if you choose to search it it's easy to focus on what you want.
This also makes it easy to handle archiving, deletion, and other
mail-related tasks.

---rsk

[1] I use and highly recommend mutt, which is lightweight, pretty secure,
full-featured, extensible, well-supported, works beautifully via ssh,
and runs on all professional-quality operating systems.  It's also quite
efficient and makes many common mail tasks very easy and fast.

---

From: Richard Kulawiec <[email-masked]>
Date: Thu, 11 Aug 2011 10:49:22 -0400

> IETF mailing lists, and it works with _every_ MUA with default settings.

The fact that poor, broken, obsolete, or non-standards-compliant
MUAs exist is not a valid reason for inflicting a fundamentally-broken
kludge on the people who have chosen their MUAs with care.

And actually, no, you can't *always* tell those discussion apart,
nor can you tell them from off-list replies...because (a) discussions
which cross multiple lists may carry the subject-line tags from
each list and (b) off-list replies will also -- unless someone takes the
time to hand-edit the Subject line and remove the tag or mark it
[off-list] -- carry the tag.  This is one of the many reasons why
List-Id is vastly superior: it solves both these problems.

For example, consider these exquisite little inconveniences (chosen
from thousands of examples on hand):

	Subject: Re: [asterisk-security] [asterisk-dev] dahdi system.conf update
	Subject: [WEB SECURITY] [HITB-Announce] HITB2011AMS Conference Materials
	Subject: [opensuse-project] Re: [opensuse-testing] Re: [opensuse-factory] Request to change MS6

I like the last one particularly: as the conversation thread migrated,
the subject-line tags managed to gradually colonize the entire Subject
line, thereby obliviating the actual Subject.  (Yes, incidentally, I suppose
you could set up your MUA to honor the leftmost tag, but that does nothing
to solve problem (b) above or any of the other I haven't bothered to enumerate,
and anyway if your MUA is that smart...then you could just use List-Id.)

And I haven't even gotten into all the circumstances where [.*] appears
on a Subject line and has nothing to do with the mailing list's name.

---rsk

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Aug 2011 11:24:52 -0400

On Thu, Aug 11, 2011 at 10:49:22AM -0400, Richard Kulawiec wrote:

> nor can you tell them from off-list replies.

List headers don't guarantee helping with that, though, either,
because many lists will supporess the echo of the list mail to you if
you are also mentioned in the addressee headers.  Given the prevalence
of people using reply-all, that happens often.  Then some mail in the
discussion arrives in your inbox and other mail arrives in the list
box.  And yes, this could be alleviated by people replying just to the
list, but a lot of mail clients seem not to provide a convenient way
to do that.

I don't want the additional subject line cruft, but the list headers
are not a magic answer.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Aug 2011 17:58:59 +0200 (MEST)

> to "drink from the firehose" by subscribing to many mailing lists

List-Id: is only useful for folks who have either lots of time on
their hands, or want to use automatic archival and have no desire
to actually process the email they're receiving.

> mail into one mailbox means that...all incoming mail is in one mailbox.

Yes, and that is the most efficient way to perform full processing.
I'm a simple human being that can focus his mind and his eyesight
only on one single thing at a time, so everything has to be serialized
anyway, and no amount of slicing and dicing the stuff will reduce
the amount of processing -- but most of it will incur additional actions
to open it when it is not queued in a single inbox.

> they could be if that mail was in separate mailboxes.

seperate mailboxes is OK for archiving, but it adds complexity and
costs additional time if the intention is to really process 95% of the
stuff (5% is junk that I delete without opening).

-Martin

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Aug 2011 12:26:04 -0400

> to actually process the email they're receiving.
...
> to open it when it is not queued in a single inbox.

Martin, please don't assume that everyone deals with their email the
way you do.  I sort my mail using List-ID header fields, each list's
messages go into a separate mailbox (organized much the way Richard
Kulawiec suggests), and I find it *fabulously* useful and efficient.
Still, I would never suggest that you had to do it that way, nor that
your way isn't useful.  Your way isn't useful FOR ME.  Apparently, my
way isn't useful FOR YOU.  À chacun, son goût, after all.

So the question really goes to the mailman people: can we get an
option to make the prefix inclusion a subscriber option?  Each list
would have a default behaviour, but each user could change it (just as
I now change every list's "suppress duplicates" option when I
subscribe to it, which makes sure my folders contain complete
threads).  That would make everyone happy.

As long as the option goes by mailing list, and everyone has to eat
the preference of whoever sets up the list, we'll have endless and
non-productive arguments (like this one) about it.

Barry

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 11 Aug 2011 09:30:08 -0700

> list, but a lot of mail clients seem not to provide a convenient way

:0 Whc: msgid.lock
| formail -D 8192 msgid.cache
:0 a:
.duplicates/

is pretty much magical if you have the ability to procmail.

---

From: Keith Moore <[email-masked]>
Date: Thu, 11 Aug 2011 13:01:11 -0400

> way isn't useful FOR YOU.  À chacun, son goût, after all.

Something that I've observed for many years is that people really don't like to change the tools and practices that they have used regularly and for a long time, even when new tools and/or practices are more functional.

(It turns out that I'm the same way.   Back in the winter of 1980 I ported James Gosling's Emacs to VMS.  I haven't used Gosling Emacs since circa 1985, but I'm still using Gosling's key bindings.  I've ported those key bindings to every editor I've used since then.  I programmed almost exclusively in C between 1980 and 2009 or so, at which point I started learning Python and now write most of my code in it.  I have no regrets about learning Python, but I also have no regrets at sticking with C for so long.   Even though GUI interfaces have long since become commonplace on desktops, the application that I use most is still a terminal emulator as an interface to bash.   And I'd still be using MH to read my mail if it had decent IMAP support.)

So if people want to stick with mail user agents that don't recognize List-ID, if they want to have all of their mail end up in one mailbox, if they want to use "sort by subject" to classify their incoming mail - I don't blame them.   Sure there are better tools these days, but it's understandable if they are hesitant to invest the time required to evaluate and learn new tools and new ways of handling mail, and potentially disrupt their ability to communicate while doing so.

Munging the subject field of mailing list traffic is really ugly, but many people have long-entrenched work habits that rely on it.  I don't think that existing lists should change their behavior, and I certainly don't think it should be the default behavior for new lists, but I would like to see it be a subscriber option for new lists.

Keith

---

From: Patrik Halfar <[email-masked]>
Date: Thu, 11 Aug 2011 20:28:45 +0200 (CEST)

> to actually process the email they're receiving.

Don't understand your note List-Id: require lots of time.

> to open it when it is not queued in a single inbox.

I'm simple human as well and I need processing most of e-mail on mobile 
devices. Then prefixes in subject don't allow see subject on first sight. 
What's more sorting into directories allowes  download just required 
messages and don't download lists which can wait.

> stuff (5% is junk that I delete without opening).

Patrik

- -- 
Ing. Patrik Halfar
Faculty of Information Technology
Bozetechova 2, 612 66 Brno, Czech republic
  Phone: +420 (541) 14-1327 (VUT/office)
  Phone: +420 (606) 609-172
Jabber: [email-masked] (private)
    PGP: B577 58A0 2125 161D 294C 7F77 17B6 B8F0 BE0A 9B1D
    Web: http://www.fit.vutbr.cz/~ihalfar

---

From: Yoav Nir <[email-masked]>
Date: Fri, 12 Aug 2011 08:24:47 +0300

> to actually process the email they're receiving.

Not sure why this is. I sort by the list address in the to: or cc: fields, but that's a limitation of my MTA.

> to open it when it is not queued in a single inbox.

I think the opposite. Suppose I'm subscribed to WebSec, TLS, PKIX and IETF. There are different threads running in all 4 lists. I come to work in the morning, and see that I have several messages on all lists. If I read them one-by-one in one mailbox, I have to switch contexts for the different threads. If they're sorted into four mailboxes, I can follow one thread, and then another. MUAs can try to sort by thread, but occasionally fail (when people change subjects, like "How to use MUAs (was: subject_prefix on IETF Discuss?)", or when we get a "Re:" equivalent in some foreign language), so I prefer to see them sorted by date rather than grouped by threads. I'd rather make less context switches and just read mails from a single list grouped together, but that's just me. You may have a different way of handing too much email.

---

From: Hector Santos <[email-masked]>
Date: Fri, 12 Aug 2011 02:23:44 -0400

> non-productive arguments (like this one) about it.

+1.

But its not all waste :)

For me, reading these "user support issues" is feed for product 
improvements to see where what new sysop vs user needs are considered. 
   The Subject prefix was one of them we looked to:

    - minimize the promotion of mail tampering ideas,
    - its less needed today with newer MUAS, and
    - we have new DKIM considerations.

It first appeared be a good and easy candidate for a new user option 
to override the list setting, but when the code change requirements 
were looked at, at least for our software (independent list server and 
smtp server), it was not a feasible feature to implement without 
multiple design methods to check out and significant code change 
simply because the list server creates a single 5322 payload for a 
smart host SMTP connection multi-RCPT distribution.

I guess for an SMTP server that has built-in list distribution and has 
access to the list membership database, it can do customize payload 
per member.

---

From: [email-masked]
Date: Fri, 12 Aug 2011 19:24:40 -0700 (PDT)

> option to make the prefix inclusion a subscriber option?

I confess to being more than a little perplexed as to why you and others think
this idea in and of itself is a useful solution to anything.

The problem with putting tags into the subject field is fundamental: The
semantics just don't match. Subject field text is routinely reused in a variety
of ways - such reuse is in fact openly condoned and encouraged by our various
email standards. And this reuse breaks tags that are necessarily bound to the
context of the original message.

For example, suppose I elect to have lists add tags to the messages I receive.
That's all fine and dandy until I decide to reply to one of those messages.
Now the tag goes right back to the list and gets redistributed to the people
who do not want it.

This problem can be ameliorated somewhat by having the list actively strip it's
own tag from messages sent to recipients that have elected not to receive the
tag, but you're still left with the problems associated with replies to
messages sent to multiple lists.

> Each list

No it won't. See above. In fact by making the presence of the tag unpredictable
it may actually make things worse.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Fri, 12 Aug 2011 23:01:17 -0400

> this idea in and of itself is a useful solution to anything.

If having it be a per-subscriber option (off by default) would aid migration to a world where subject tags are not commonplace and therefore not widely expected, that might be worth it.  Maybe having them off by default will encourage more use of List-ID.

I agree that the problems you mention are real.  As long as the subject tag were an option, lists supporting it would still need to be able to strip subject tags from replies.  Replies to messages sent to multiple lists would still be messy.

Keith

---

From: Hector Santos <[email-masked]>
Date: Sat, 13 Aug 2011 03:05:56 -0400

Keith Moore wrote:
> If having it be a per-subscriber option (off by default) would aid migration to 
> a world where subject tags are not commonplace and therefore not widely expected, 
> that might be worth it.  Maybe having them off by default will encourage more 
> use of List-ID.

+1

One way to view this is to focus on the central issue and why/when the 
subject tag was useful:

        The need for Discussion Groups separations

But why did this occur?

Before Offline MUA became prevalent, online group ware conferencing 
provided the separation and it was the dominant user types.  Off hand, 
there were at least five different user types or access points:

   USER1: Online (console, web, gui) portals, folders separations 
available
   USER2: Offline w/ Online access to folders using non IETF method 
(i.e. Exchange)
   USER3: Offline w/ Online access to folders using IETF IMAP standard 
method
   USER4: Offline w/ Online access to folders using IETF NNTP standard 
method
   USER5: Offline using IETF POP3 Standard but with no inherent folder 
separations

So pre 2001 USER5 who may not have a MUA with support for RFC2919 
(List-ID) or flexibility to add new headers, needed a help using an 
undesirable mail tampering idea - subject list tags.

But today, RFC 2919 is widely adopted, MUA are more flexible and DKIM 
is also adding new pressures to avoid using this Subject List tag kludge.

So if the central issue is separation, we now have three IETF Methods 
for offline users to achieve this - IMAP, NNTP and LIST-ID sorting, 
and a new DKIM standard that this kludge conflicts with.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 27 Aug 2011 09:06:16 -0600

> "Doctor, it hurts when I do that."

Yah, I find this particularly bad when reading email on my Datapoint 3300