I am writing a program that composes an email reply. The original email may be a reply already. How should I handle the subject?
I have seen the everything-before-the-colon method used. This could affect a situation re[2]:. If the colon method was used. The reply would become Re: and the other party’s computer would lose count.
If not, the reply would become Re: re[2] Then the next reply could come through as re[4] as was intended.
But the colon method can be useful for cases where you say Resending: and the next reply would become Re:.
Do you have input on this? Is there a standard or common way to do this?
(With no context at all it’s difficult to provide a concrete answer – you may want to provide more information in your question)
Most decent mail user agents (MUA) use the
In-Reply-To:header to indicate message threading, without resorting to unsafe operations such as parsing theSubject:header. Most such clients also have a proper threading mode where unusual stuff such asRe[2]:is at best unnecessary. The de facto standard of usingRe:is a good compromise between terseness and content, but with proper threading support it eventually comes down to aesthetics.Just use
Re:in messages you create yourself – anything else is bound to lead to confusion. Make sure you properly generate theIn-Reply-To:header for any reply messages.Please do not remove content from the
Subject:header. You may refrain from adding to it when e.g. a properRe:substring already exists, but if you are actually removing strings you are bound to get it wrong, leading to confusing situations.This is not a strictly technical issue – different people have different preferences. In a specific community, e.g. a mailing list, social automation (sic) will take care of any repeat offender that uses strange or confusing conventions.
Trying to deal with this automatically is bound to cause more problems than it would solve. Such issues are also not the responsibility of the carrier – i.e. the mailing system. Keep your system simple and focus on real technical problems.
EDIT:
A common case of a broken client (or user – I have always been unclear on this) is the
Re:avalanche case:Tempting isn’t it? A simple filter rule in the MTA, or a few lines of code in a replying MUA and the avalanche is replaced by a nice, single
Re:automatically!In my opinion, this is one case where the temptation should be resisted to:
There is no guarantee that an MTA is the only path a specific message uses. For example, when some users reply to mailing list messages, they reply both to the mailing list and directly to the poster. Naturally, the poster will receive both messages, most probably by completely different paths.
Do you know how confusing it can be to receive the same message with two different subject lines? Even a basic sort-by-subject would fail. In my opinion, even spam detection systems that add
[SPAM],**SPAM**,$P@Mor whatever to the subject are pushing it.Can you imagine a library selectively changing the titles of their book copies according to some sort of local policy?
Even if your MUA “fixes” the issue, everyone else will still be using the old subject, except for when replying to you. Moreover, you have just single-sidedly created what appears to be a new thread. Proper mail clients will still display the thread correctly, but the visual effect is confusing. After all, you did remove a highly distinctive feature of this thread from your reply post, didn’t you?
I actually remember a couple of fun threads where the
Re:avalanche in their subject was part of a tongue-in-cheek discussion. Why would you want to miss on that?Sure, people use broken clients. Or they are broken themselves. If anyone gets really out of line it can be handled individually. Just don’t compound the problem and leave our
Subject:headers alone. Please? Pretty please?