Meaning and purpose of the Subject field

Thomas 'PointedEars' Lahn PointedEars at web.de
Mon Dec 21 17:55:52 EST 2015


Jon Ribbens wrote:

> On 2015-12-21, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> I can't specifically recall if I've used any MUA other than Gmail that
>> even attempts threading email messages.
> 
> Also: Thunderbird, The Bat!, Eudora, Gnus, Outlook, Outlook Express,
> Pegasus Mail, Pine, Apple Mail, Windows Live Mail, Yahoo Mail,
> Evolution, SquirrelMail, KMail, Windows Mail, etc.

Yes, of course.
 
> Trying to suggest that MUAs should never look at the Subject line for
> threading is, unfortunately, ridiculous.

No, it is what the Internet message standard says instead:

,-<http://tools.ietf.org/html/rfc5322#section-3.6.4>
| 
| 3.6.4.  Identification Fields
| 
| Though listed as optional in the table in section 3.6, every message
| SHOULD have a "Message-ID:" field.  Furthermore, reply messages
| SHOULD have "In-Reply-To:" and "References:" fields as appropriate
| and as described below.
| 
| The "Message-ID:" field contains a single unique message identifier.
| The "References:" and "In-Reply-To:" fields each contain one or more
| unique message identifiers, optionally separated by CFWS.

(“SHOULD” in an RFC means: “do as I say unless you can give me a very good 
reason not to do it”.  See RFC 2119 for details.)

vs.

,-<http://tools.ietf.org/html/rfc5322#section-3.6.5>
| 
| 3.6.5.  Informational Fields
| 
| The informational fields are all optional.  The "Subject:" and
| "Comments:" fields are unstructured fields as defined in section
| 2.2.1, and therefore may contain text or folding white space. […]

> Yes, in theory it shouldn't be necessary

It is not.

> but in practice enough people are using poor clients that don't provide
> enough context in the proper headers that it can't be avoided.

That Internet communication is made more difficult for *all* because a 
*perceived* majority of *perceived* clients is broken, is putting upside 
down the good Internet principle of “be conservative in what to send, 
liberal in what to receive”.

Those b0rked clients should either be fixed at once or not be used, period.

Instead, in practice, the Python mailing list software is b0rked since I 
know of the mailing list’s/newsgroups’ existence (several years ago): it is 
b0rked in the regard that its distributor does not consider that it is also 
posted to a Usenet newsgroup where articles require a References header 
field to be properly threaded.  Incidentally, that References header field 
is, in the absence of an In-Reply-To header field, used by hybrid e 
mail/NetNews agents such as Thunderbird, in full compliance with the NetNews 
message standard:

,-<http://tools.ietf.org/html/rfc5536#section-3>
| 
| 3.  News Header Fields
| 
|    The following news header fields extend those defined in Section 3.6
|    of [RFC5322]:
| 
| […]
| 3.2.10.  References
| 
|    The References header field is the same as that specified in Section
|    3.6.4 of [RFC5322], with the added restrictions detailed above in
|    Section 2.2 and those listed below: […]

One could kill two birds with one stone here by fixing this, but it is not 
done.  Why?

> And, yes, fixing the mail clients of "everybody else in the world"
> might be a lovely idea but it is a little impractical to implement.

I find your argument strewn with gaping defects in logic.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.



More information about the Python-list mailing list