1310462 - add on how to copy old external emails

Status: RESOLVED INVALID

(Thunderbird :: Help Documentation, defect)

Description

[Nick Levinson]

You seem to have no instruction on how to copy old emails from an email service provider's server (in my case, Yahoo), but apparently it can be done, so I propose you add to your help file (<https://support.mozilla.org/en-US/products/thunderbird/emails-thunderbird/read-send-and-organize-emails>, as accessed Oct. 9, 2016). Here's a possible text, based on my partial experience (not all of this has been tested) and subject to your double-checking of procedure and editing of the writing as you see fit:

Start Thunderbird and opt to work online. (If there's a way to go online after opening Thunderbird, say so.) This will work with POP. In the left pane, select an external email account. In the main panel, under "Email", click on "Read messages". In the case of Yahoo, it will prepare to copy individual emails and then it will copy them one by one from the Inbox of your external email account, in chronological order, oldest first, with full headers, even if you did not set Yahoo to show full headers. If it does not copy from any other Yahoo folder, create an additional local folder to receive email copies or to move the copies you just made into so that where Thunderbird copies into will be empty and available for jore copies, go to your Yahoo account, make a folder on the Yahoo server, move the copied emails from the Inbox to your new folder, move emails from another folder into your Inbox, go to Thunderbird, repeat the process for copying emails until that Yahoo folder has been finished, go to Yahoo, move the newly-copied emails back to their former folder, and repeat the process with another Yahoo folder. When all is finished, move the emails you first copied from the new temporary folder back into the Inbox. Check your local copies to be sure you have everything you want. If you do, you can delete them from the Yahoo account (be sure no new ones have arrived at Yahoo during the process or that you have copied them) or you can move them to a specially-named folder as a backup. To stop copying at any time, quit Thunderbird. If you restart Thunderbird and resume copying, Thunderbird will resume where you left off, but if you have deleted some emails other than the latest one copied it may not copy to replace the deleted ones.

Comment 1

[Jorg K (CEST = GMT+2)]

Matt, can you take a look at this one.

Comment 2

[Matt]

https://bugzilla.mozilla.org/show_bug.cgi?id=1310462
https://bugzilla.mozilla.org/show_bug.cgi?id=1310461
https://bugzilla.mozilla.org/show_bug.cgi?id=1310459
https://bugzilla.mozilla.org/show_bug.cgi?id=1310458
https://bugzilla.mozilla.org/show_bug.cgi?id=1310457
https://bugzilla.mozilla.org/show_bug.cgi?id=1310456
https://bugzilla.mozilla.org/show_bug.cgi?id=1310455

7 almost consecutive bugs.  All seeking support not reporting bugs or asking for enhancements in my opinion.

Thunderbird manual here http://en.flossmanuals.net/Thunderbird/

Nick,  this is a bug forum.  Support is undertaken here. https://support.mozilla.org/en-US/questions/new  I suggest you avail yourself of the support,  because I do not think this is a valid bug either.

We have IMAP with Yahoo.  The only other option is POP.  These are no Something Thunderbird, or even Mozilla.  They are protocols set up by the internet engineering taskforce.

The RFC for IMAP mail can be read here. https://tools.ietf.org/html/rfc3501
The RFC for POP can be read here https://tools.ietf.org/html/rfc1081

If there is some standard Thunderbird does not meet,  then please file a bug for that to be addressed.  If you file a bug for an enhancement,  it must not contradict the information included in the standards.

I will leave this bug open as I fail to understand what this is all about.  But I do feel the bug is invalid at this point.

Comment 3

[Nick Levinson]

If authoritative documentation has moved to another site (the domain suggests it's not Mozilla's), then that should be told to all users, not just me and a few insiders. Not saying so is a Thunderbird documentation bug.

I do use the support fora and have for some time. When the problem is limited to me and some others, support is more apropos. When it affects many users, Bugzilla or something similar is more apropos. Someone once said that a manual is a list of what's wrong with a program; that's an oversimplification, but there's something to be said for intuitiveness and meeting users' expectations. While bug reports have sometimes led to useful support, that's not what I seek at Bugzilla. While developers may be busy, discouraging input is not as good an idea as increasing the developer base. I have read a number of RFCs over the years, and, as far as I know, I haven't proposed to contradict any of them. While conforming to RFCs and meeting security challenges are and should be among relatively high priorities, usability and some other issues are also relevant, as they affect the number of users willing to stick with a product and therefore the product's future.

The Bugzilla reports are nearly consecutive because I draft offline and edit them, and then post later at one time. No one else was doing so at the moment except for one, but that's a coincidence. I didn't ask anyone to wait. The idea of listing the group is discussed at <https://bugzilla.mozilla.org/show_bug.cgi?id=1310459#c3>.

Comment 4

[Wayne Mery (:wsmwk)]

The bugzilla "help" component is currently for "in-product" documentation, of which there is very little. So it is a bit misleading, and perhaps the description could be better than the current "Inaccurate information and typos in Thunderbird's help documentation."

I think it's great and commendable that you are interested enough to be engaged, and concerned about Thunderbird's future. In the case of this bug report, the place to be is indeed  https://support.mozilla.org/en-US/questions/new where there are more people with skills to assist than are available in bugzilla.  And we'd certainly welcome your help in adding to and improving the documentation at https://support.mozilla.org/products/thunderbird

Comment 5

[Nick Levinson]

I did ask Support for this (https://support.mozilla.org/en-US/questions/1137884) about a month-plus before I brought it to Bugzilla and @Matt gave me a reply that, as I recall, got me started in a helpful direction.

But that left the need for a support article (either existing or new) to cover this better. I've seen the "Volunteer for Mozilla Support" button (https://support.mozilla.org/en-US/products/thunderbird), but I probably assumed that that button meant that I could answer other people's questions, for which I usually don't consider myself qualified enough. It turns out that clicking the button leads to "Write help articles" > "Help us write help articles!", which includes editing, but the lead-in "Volunteer for Mozilla Support", while not false, does not suggest that it's the place for reporting errors. In a case like this, I'd rather report the error and leave it to someone more expert in Thunderbird than I am to figure out how to edit an existing article or write a new one so it does not contain any new errors by me. Thus, as far as I could tell at the time, Bugzilla was the place for that. Perhaps, before the next time it occurs to someone like me that something in Mozilla's online support should be treated as a bug or enhanced, if I look in Bugzilla, it will have been revised to direct me to the proper place to propose such a change. That could be the Support volunteer path, but there's also talk that SUMO/SUMOMO is the place except that it's being or to be replaced and a decision re Lithium is pending (https://bugzilla.mozilla.org/show_bug.cgi?id=1310458#c4). Non-Mozilla documentation has been recommended in this thread in comment 2 (Floss Manuals), but that hardly seems to be an editing solution as long as Mozilla offers support articles. Whatever path is ultimately preferred for proposing an edit, the place to tell users is not just in a bug comment (a nice step) but in Bugzilla where we're told how to direct a bug for a product component.

I assume that anyone who doesn't like dealing with proposed edits to Mozilla's support articles may simply ignore Bugzilla reports about them and leave responding to them to other readers of Bugzilla reports, just as I assume that programmers who are only interested in RFC noncompliance bugs need to read RFC noncompliance bug reports; and likewise for subspecialties within any such component. So maybe what's needed is a bug report about how Mozilla has configured Bugzilla for Thunderbird's documentation including support. If I should file that kind of bug report, please let me know. If someone else has a better way of revising Bugzilla to advise us in case we want to see a change in a support article or other Mozilla support, then please go ahead. I don't need the credit.

For anyone who wasn't sure what this bug report is about, that's stated in the first sentence. But if documentation is so unimportant that Mozilla doesn't even maintain it any more, that may be because some programmers know the software so well they don't need documentation. However, most users are not programmers and most users may not even be daily users of a given program. Documentation is more useful for us half-geek half-laic and we should not be criticized for hoping it'll be in shape. If Bugzilla is not revised to redirect proposals away, Bugzilla will probably continue to get them.

Comment 6

[Matt]

You accessed a category of documents that listed 26 actual support documents, in the category "Read, send and organize emails"

The text that follows is to say the least specific to your mail provider and your understanding of email.  Exactly which of those articles would you have someone edit?

Personally anything specific to Yahoo would probably go in the yahoo article. https://support.mozilla.org/en-US/kb/thunderbird-and-yahoo

All I see is a convoluted process to use pop to download all folders on the server.  IMAP will do that as a matter of course without any convoluted procedure you copying and replacing if folders.  Something very similar to what we used to offer folk using yahoo and Hotmail when they only offered POP mail.

Copying IMAP folder contents to Local folders is the recognised method of making immutable local copies.  Not copying many folder server side into the inbox.  It is slow, prone to error and really a poor method unless you are truly stuck with a POP account.  You are not!

As an editor, I would not accept that procedure as something we should publish as a method to make local copies of Yahoo accounts.  Or any mail servers mail where IMAP support is offered.

So I closed this bug as invalid for the following reasons.

1. The suggested procedure is not something we would recommend.
2. The suggested location is an auto generated listing of articles in a category. (not a document that can be edited.)
3. Nothing of tangible value is added to a the knowledge base we are struggling to keep current (and failing).
4. Mozilla's web site is a different product.  That is a separate bug.  

Might I suggest that before you continue that you look at the relationship between Thunderbird (a community run project with no employees) and Mozilla (The parent that ceased development on Thunderbird in 2012 and is suggesting we find a new home)
This is a factual account of where we are. http://news.softpedia.com/news/two-foundations-are-willing-to-take-over-thunderbird-development-503408.shtml

So Mozilla really has little interest in things Thunderbird.  But you are coming in on the end of a long process that you are not ware of and making assumptions.

1.Mozilla has a policy that they will not provide manuals.  So a group of volunteers created one at FOSS.  This was done in the time Mozilla had the Mozilla Messaging company running Thunderbird.

2. Mozilla has a policy of supplying knowledge base articles.  That policy is long and under constant revision.  The recognised entry point to the process is https://support.mozilla.org/en-US/kb/improve-knowledge-base

Whilst ever we share a support site with Mozilla we are basically bound to those policies.  While I for instance may ignore them, I can assure you the folk doing the translations of the articles into other languages will  quickly complain should the workload be to great or the content questionable in their eyes.  I have had translators simply revert edited articles to their prior state because they disagree the edit is beneficial.

Comment 7

[Nick Levinson]

No sweat. My point in linking to the category was to show which articles were nearly relevant on the assumption that one article would be appropriate for editing or that a new article could be added to the category, not that the category itself would be turned into an article. I wasn't sure which article would be best or if adding or editing would be better. The text I proposed was only proposed as a possibility "subject to your double-checking of procedure . . ." and your critique is no problem for me. You'd likely know the product much better than I do. I also wouldn't be surprised if some email service providers vary procedures according to a customer's nation, perhaps because of what paid services they can market there and therefore what's included in the free service in that nation, but I don't know for certain if they vary. The thought for an article arose because I started out having difficulty figuring out what steps to execute, even though I'm moderately geeky and can often hack my way around menus and such, and if I would benefit from an article, then others likely would, too, but you or someone else would know better than I would whether the demand would be enough to warrant writing much.

The Softpedia article and a couple of others were interesting. I'm assuming that Bugzilla reports abut Thunderbird will be transferred or made available to Thunderbird's developers at whatever new venue is found, so that it's still useful to post there until the transition.

Thanks for the analysis and response.