From ArchWiki

Article overhaul proposition

I'd like to reorganize this page, as I see there isn't too much helpful information here: the Thunderbird#Securing section needs to be looked into; the extensions section looks to be subjective and could use some prioritizing; two of the tip sections values will need to be determined: Thunderbird#Setting_the_default_browser is deprecated (I'm pretty sure), and Thunderbird#Plain_Text_mode_and_font_uniformity is preferential (in font selection and size) and globally defining. These mentions left aside leave a pretty thin article.

Redoing this article I think would be a reasonable task. I was thinking six basic sections would do with this order and reason:

Any thoughts, suggestions? --Gen2ly

+1 from me. -- Alad (talk) 21:07, 15 December 2014 (UTC)
I like the plan too, two questions:
-- Kynikos (talk) 13:47, 16 December 2014 (UTC)
Would Thunderbird#Securing go under Thunderbird#Configuration?
I'm still looking at this. This is all new to me. Depending on necessity, I think it might have a place in its own section. But general layout standardization would probably say that it goes in Thunderbird#Configuration.
I've tested Thunderbird#Setting the default browser, what exactly is deprecated?...
I have yet to look into this yet. When I read the note, I got a feeling that the settings were deprecated... this is an error on my part.
I see, the note refers to some* keys which are indeed not present anymore in Thunderbird, but the rest of the section doesn't rely on them.
I've moved your updated plan to the section below, otherwise it's impossible to follow the discussion, see also Help:Discussion: for example Alad gave his +1 to the original plan but you can't assume he approves the new one too. You may also be interested in the ~~~~ shortcut to quickly sign your posts using the standard format.
-- Kynikos (talk) 16:27, 16 December 2014 (UTC)
Ughh, huge page restructure without discussion. I would prefer consensual relationships with recommendations as I believe that they more positively effect communal-health than quick overhauls. I will respond to this comment as positive and professionally as possible, to any degree if I fail to do so, then I apologize in advance and want it to be known that I consider the human factor, job one.
Impossible two follow is a completely unaccurate connotation. My first thought when I read this was that the rewrite wasn't even read!... I wrote in the summary: "Rewrote proposal with more positive tone, expanded on a bit for better understanding". With this summary along with the edit itself, the factual re-representation in the edit was available. Wiki guidelines for editing discussions (whether verbal or non-verbal) generally allow correction of typos, grammar, and occasionally rewording for understanding, I'll touch more on this in a bit.
I would also like to add that such a description has a high risk of creating a negative reaction. Because the description "impossible" describes the end of the spectrum, it has the possibility of invoking feelings of bereftness before anything can be garnered from it :). From my experience, being considerate, positively effectual, and perspectively accurate in my recommendations helps garner communal bondings.
From here, I took a logical assumption of the possible perspective of the comment (to help fill in unknown gaps that it left). Namely, I came to think that the comment derived from a type of thinking like, "... because of tonal alteration of the discussion, alone it is enough to effect the nature of the discussion." And this, in an attempt to be productive, is what I walked away thinking.
For future knowledge, because it allows for greater understanding, I do plan to create new sections for any discussions even if I feel the general nature of them doesn't change (grammar and typos aside). The linearity of thought argument has tremendous value and I respect that. (I've come to think that the essentiality of action was taken because of this.) Thank you for your time.
(Of a sidenote: In my original proposition, I noticed it ended with a "--Gen2ly". I came to think that my signature was accidentally erased, as I'm pretty sure I left one, and this got put in its place.)
Gently (talk) 18:10, 17 December 2014 (UTC)
There seems to be some misunderstanding here, Kynikos simply moved your proposal to a different section for easy editing, and to keep the integrity of the responses intact - common in talk pages. So let's keep this discussion to Thunderbird, shall we? -- Alad (talk) 18:22, 17 December 2014 (UTC)

Updated plan

I believe this article has enough value (by this I generally mean readership) to warrant a more thorough article. By "a more thorough" article, I mean that some of the section contents will need to be reviewed, and additionally, general usability and configuration sections added.

Sections that need review, I believe, are:

It has been previously tagged as needing "language, wiki syntax, or style improvements" with the note: "This section contains too many colloquial/subjective comments/expressions, a more neutral tone should be used"; a following note reads "Cleaned up some, still needs work."
An expert or some good research will need to go into this section as it generally lacks veracity/impartiality.
Preference for an extensions are usually personal; however... maybe these can be ordered by AUR votes.
The Thunderbird#Setting the default browser section could be helped with a bit of clean up (the note for one, which mentioned below by Kynikos, may be in error), and Thunderbird#Plain Text mode and font uniformity is preferential (in font selection and size) — referring to Font configuration would be the more appropriate action, I believe.

Sections I like to have/add in the article (and their reasoning), are:

Any thoughts, suggestions? --Gen2ly

"Information disclosure" section tag resolution

I would like to analyze the section Thunderbird#Information_disclosure in an attempt to resolve its tagging. The section is tagged, "This article or section needs language, wiki syntax or style improvements. Reason: Cleaned up some, still needs work.". The previous tag (if I remember correctly) noted concerns about partiality and truthfulness.

Thunderbird does a reverse DNS lookup of internal.private.hostname.and.private.domain by default. To help Thunderbird find what it is looking for, and prevent potential information leaks, set your hostname as explained in Network configuration#Set the hostname.

The unusual definition "internal.private.hostname.and.private.domain" I'm relatively sure refers to the canonical_hostname ( man hosts). This form appears to be a bit of an elaboration. In an unmodified file of /etc/hosts the value is localhost.localdomain. I believe our naming of this value should reflect what is in the documentation.

A "...reverse DNS lookup...'" is "the resolution of an IP address to its designated domain name" (source Wikipedia:Reverse_DNS_lookup). I sent to myself two emails and read the email headers and there is no mention of localhost or localdomain (my canonical_hostname is unmodified). Other MTUs I've discovered send this information but not Thunderbird (for example, Received: from (localhost.localdomain [] or Received: from (EHLO (111.222.333.444). This leaves the likelyhood that a reverse DNS is performed when the canonical_hostname is not defined as localhost.localdomain.

Working with the premise that a rDNS can occur (since it has not been disproved) then security regarding information disclosure is a reasonable concern. For example, if I had a canonical_hostname of john-doe_555-blvd-NYNY it would not be swell. While it is likely true that this value doe not get often edited for most Arch Linux users, those on a specialized Intranet or using Arch as a server may alter this value. Additionally, while this unwanted security concern is largely, and possibly even entirely related to Thunderbird, I still think the best way to handle this would to be put a warning tag in the Network configuration#Set the hostname section. This should be done I believe because there might be programs now or in the future that might also perform a likewise operation. The tag could be added that was described like, "It is recommended not to enter user-sensitive data in the canonical_hostname or in an alias. At times, other programs may distribute this information.".

Do disable operation system information in mail headers:

Thunderbird sends a User Agent string which contains CPU architecture, Operating system, and Thunderbird information. This string is has been remarked as noncritical and from my observations is generally only used for datum (e.g. if a MTA is running poorly these details could direct the administrator to an MTU that was recently updated, or to compare MTU number usage).

(The User Agent sting can be viewed by sending an email to oneself and then looking at the email headers, or as describe in this post).

This directive would be bettered, I believe, if was presented as an option. Possibly a description like this will do: Thunderbird sends a User Agent string that yields CPU architecture, Operating system, and Thunderbird attributes. These details are non-critical to email delivery and the sending of them can be disabled if desired. Notwithstanding, this string has uses that are desirable for debugging, developing software infrastructure, and other things — their allowance can aid in software development.

Gently (talk) 17:04, 14 February 2015 (UTC)

Outlook to Thunderbird migration - proposition

I have had a hard time today trying to move local email folders from MS Outlook to Thunderbird on another pc, so I thought I could write a small wiki about it to save others the time and frustration. Would this be a good place to write such an article? I would put in the "Migration" section. The article would cover the following subjects:

  • How to export email folders out of Outlook into a *.pst file
  • How to convert the *.pst file to mbox files using the libpst utilities
  • How to import the mbox files into Thunderbird when
    • using IMAP (manual copy/paste into local mail folder)
    • using POP3 or something else (with the ImportExportTools addon)

I am new to writing wiki articles, but am willing to invest some time in reading the wiki guidelines before posting the article. SamDM (talk) 19:47, 15 July 2015 (UTC)

Hi, I don't see any problems if you add that info, however the "Migration" section was unrelated, and I've updated its heading, so you can instead create a separate "Migrate data from MS Outlook" (or similar) section. — Kynikos (talk) 15:11, 17 July 2015 (UTC)

Accessing Config Editor

I tried to follow the instructions on how to access the Config Editor in the section entitled "Config Editor". However, the option "Edit" was grayed out in the menu. I managed to access the Config Editor by going to the three horizontal bars (Thunderbird Menu), clicking Preferences, then Advanced, then in the General tab selecting the Config Editor. I'm pretty new here so if anyone wanted to update the article to reflect this potential change to the menu system, that would be great.

Somebody62 (talk) 17:42, 1 February 2019 (UTC)