Bugzilla@Mozdev – Bug 26340
Unchanged Field Option for %To()%, %CC()% and %From()%
Last modified: 2018-04-27 02:08:00
You need to log in before you can comment on or make changes to this bug.
This category would keep the original headers for the "To:", "CC:" and "From:" fields in the reply template headers. Thus if a messsage was originally sent to "John Doe <johndoe@gmail.com", the reply header would show "John Doe <johndoe@gmail.com". On the other hand, if the original e-mail was just sent to "<johndoe@gmail.com>", the reply header would show only "johndoe@gmail.com". This would also be useful to people like me who have mail from other accounts forwarded to their main account, as the reply would thus be generated as coming from the account towards which is was originally addressed. It would also show when an e-mail was sent "personally" (name + e-mail address) or "generally" (e-mail address only.) Thanks in advance!
Changed Bug Title. I am still debating what to call the option, "original" doesn't quite hit it. For the moment my favorite is %to(initial)% %cc(initial)% %bcc(initial)% %from(initial)% because it describes the initial (starting point) status of the header as it comes from the mail server. The other question I have is whether the Advanced option "Resolve Names from Address Book" should override this, or would this defeat the purpose?
(In reply to comment #1) > Changed Bug Title. I am still debating what to call the option, "original" > doesn't quite hit it. For the moment my favorite is > > %to(initial)% > %cc(initial)% > %bcc(initial)% > %from(initial)% > > because it describes the initial (starting point) status of the header as it > comes from the mail server. The other question I have is whether the Advanced > option "Resolve Names from Address Book" should override this, or would this > defeat the purpose? > The bug title change is fine. Calling the option "initial" is also quite logical. I don't think that "Resolve Names from Address Book" should override the new option; as you suggest, this would defeat the whole purpose. Thanks again for taking this up.
Created an attachment (id=8264) [details] 1.5 prerelease 16 Try this version. It apears Thunderbird will wrap the name portion (everything before the email address) in double quotes, not sure if this is done during sending or by the nsIMimeHeaders interface that I am using to read the headers from the email. In my test case I was using %from(initial)% in order to print out the from header contents, resulting in "Axel Grude (Test from Indigo)" <axel.grude@xxxxxx.com> I don't know whether all double quotes should be removed or left in, as I do not know what part of the mail process adds these.
(In reply to comment #3) > Created an attachment (id=8264) [details] [details] > 1.5 prerelease 16 > > Try this version. It apears Thunderbird will wrap the name portion (everything > before the email address) in double quotes, not sure if this is done during > sending or by the nsIMimeHeaders interface that I am using to read the headers > from the email. > > In my test case I was using > %from(initial)% > in order to print out the from header contents, resulting in > > "Axel Grude (Test from Indigo)" <axel.grude@xxxxxx.com> > > I don't know whether all double quotes should be removed or left in, as I do > not know what part of the mail process adds these. > I've been trying out the new version. When there is no name (just an e-mail address) in any of the four fields, it works perfectly. The issue of double (or, at times, single) quotes is remarkably inconsistent. A bit of quick and dirty testing gives me the impression that they seem to appear in three cases: 1) Replying to e-mails sent by corporations (this may depend on the mail system they use, see point 2 below) 2) Replying to e-mails sent via Outlook. I know that Outlook insists on adding single or double quotes (depending on the version). 3) Replying to e-mails where a non-alphabetic or non-numeric character forms part of the name (e.g., "@" or ","). Would it be possible to add a filter of of the "IF(LEFT(1)=ASC(34) OR ASC(39),LEFT(1)="")"? I don't know how complicated, or indeed, feasible this would be. In summary, except for the quotes issue, it's working well. Thanks for diving into it so quickly. Much appreciated ;-)
(In reply to comment #4) > (In reply to comment #3) > > Created an attachment (id=8264) [details] [details] [details] > > 1.5 prerelease 16 > > > > Try this version. It apears Thunderbird will wrap the name portion (everything > > before the email address) in double quotes, not sure if this is done during > > sending or by the nsIMimeHeaders interface that I am using to read the headers > > from the email. > > > > In my test case I was using > > %from(initial)% > > in order to print out the from header contents, resulting in > > > > "Axel Grude (Test from Indigo)" <axel.grude@xxxxxx.com> > > > > I don't know whether all double quotes should be removed or left in, as I do > > not know what part of the mail process adds these. > > > > I've been trying out the new version. When there is no name (just an e-mail > address) in any of the four fields, it works perfectly. > > The issue of double (or, at times, single) quotes is remarkably inconsistent. A > bit of quick and dirty testing gives me the impression that they seem to appear > in three cases: > > 1) Replying to e-mails sent by corporations (this may depend on the mail system > they use, see point 2 below) > > 2) Replying to e-mails sent via Outlook. I know that Outlook insists on adding > single or double quotes (depending on the version). > > 3) Replying to e-mails where a non-alphabetic or non-numeric character forms > part of the name (e.g., "@" or ","). > > Would it be possible to add a filter of of the "IF(LEFT(1)=ASC(34) OR > ASC(39),LEFT(1)="")"? I don't know how complicated, or indeed, feasible this > would be. > > In summary, except for the quotes issue, it's working well. Thanks for diving > into it so quickly. Much appreciated ;-) > Very occasionally, the brackets ("<" and ">") are quoted in the reply header if there is just an e-mail address (no name) in the original e-mail