Closed Bug 216308 Opened 17 years ago Closed 4 months ago
message box repeatedly asking for 'subscribe to <foldername>?' when forwarding a message stored in an IMAP folder
6.77 KB, image/gif
13.96 KB, text/plain
27.14 KB, image/jpeg
2.40 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030811 Mozilla Firebird/0.6.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030811 Mozilla Firebird/0.6.1+ Email Agent: Mozilla Thunderbird 0.2a (20030813) nightly build -- also occurs in previous versions, including the Thunderbird 0.1 release. Also tested was Mozilla Thunderbird 0.2a (20030807) nightly build. When forwarding a message from an IMAP server in a nested folder, I receive a dialog box asking: "Would you like to subscribe to ~dusty/Clients^^Some Client Name?" with "OK" and "Cancel" buttons and a title of "Confirm". If you click "Cancel", it continues to ask again. The IMAP folder that this message is stored in is in the structure of "IMAP Server -> user: dusty -> Clients -> Some Client Name" which is actually stored at "/home/dusty/Clients/Some\ Client\ Name" on the Linux filesystem. It seems the error has something to do with the image attachments. When the image attachments are stripped from the email, the error does not occur. It looks like the number of times it asks the question ("cancel" -> reopen dialog) is based on the number of attached and/or referenced images in the email message. This error does not occur when the forwarding option is set to "as attachment". Reproducible: Always Steps to Reproduce: 1. Use an IMAP incoming mail server account. 2. Set forwarding option to "inline" in the "Options > Composition > Forwarding and Replying to Messages" area. 3. Select (single-click) or open (double-click) the email message in the email list. 4. Click the "Forward" button in the toolbar of the Thunderbird main window (or in the message window itself if you opened the message in step 3). Actual Results: Immediately after the new message (forward) window opens, a dialog box appears with the title "Confirm" asking "Would you like to subscribe to ~dusty/Clients^^Some Client Name?" This IMAP server is running on "Linux office 2.2.19 #22 Wed Jun 20 18:12:16 PDT 2001 i686 unknown". IMAPd banner text: "* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS AUTH=LOGIN] office.ztn IMAP4rev1 2001.315 at Fri, 15 Aug 2003 12:06:18 -0700 (PDT)" I have a cropped screenshot of the dialog box that appears. Also, I have the example email message source. I will post those as attachments to this bug request.
Attachment #129876 - Attachment filename: 200307151218-thunderbirderror-subscribeonforward.gif → 200308151218-thunderbirderror-subscribeonforward.gif
In this attachment, all images have been replaced with blank GIFs. This was removed directly from the folder file stored on the IMAP server.
Possibly related to this is that Thunderbird keeps asking me if I want to subscribe to newsgroups I'm already subscribed to. This has become rather annoying because it also marks all the messages as "unread" (even if I've already read them). I'm not sure what I did to make this happen because it only occurs on one computer. To reproduce, all I have to do is select a newsgroup from the list of subscribed groups.
This bug re occur again after installing the latest update TB 45.7.0 Release Date Jan. 26, 2017 Returning to TB 45.6.0 until this bug will be fixed. Hope somebody will see and fixed this problem. Regards, Jay
I confirm this issue. The dialog asking "would you like to subscribe.." opens even when certain - not all - IMAP emails are selected in the message list (at least with the preview window open). We've had to revert to 45.6.0 until this is fixed. Cancel/escape has to be chosen multiple times before the dialog closes.
I confirm the issue. I have a "Would you like to subscribe.." when i open an email. It looks like thunderbird change the img src from "http://path/to.img" by "imap://email@...". This seems to happen when html signature is used. I can see it by using "ctrl+U" on an email where the issue occurs.
I confirm the issue. We have several users at our organization using IMAP who are receiving this issue to a few email threads. We're looking to revert to 45.6 if the problem spreads. the problem seems to be isolated to people who have received a particular email with the exhibited problem, but it does not apply to other emails the same user has sent. "Would you like to subscribe to user/username/INBOX/Folder " Cancel/escape has to be chosen multiple times before the dialog closes. Hopefully this gets patched in the next release.
(In reply to Edward Paine from comment #5) I have been using 45.7.1 for the last 3 days with no sign of this issue, so it looks like it has been fixed.
This bug is back again as of version 52.0.1. Image sources are converted from http://path-to-image to imap://path-to-IMAP folder which breaks as soon as the folder is deleted or renamed and leads to the "Would you like to subscribe.." pop-up at one per embedded image.
It looks like this has been fixed in 52.1.0
Seems not to fix my problem in 52.2.1 (no change to 52.0.1). Can anyone confirm ?
Thunderbird 56.0 How do you stop those infernal popup windows ? I get literally spammed by those "Do you want to subscribe to WATHEVER_URL_THERE"apopup messages as soon as there is a src="imap://WHATEVER@WHATEVER:143/fetch%3EUID%3E/Fidumail%3E476687?part=1.2&filename=FIDSC-1.gif" in the message. It even gets worse if you try to actually respond : each couple of characters typed in the compose window, the popup comes back. Is there a preference to set or a .js to delete so that it doesn't it again for any url i could have in my emails ???? I'm going crazy, this is plain ridiculous.
This issue is back with version 60.2.1 as per my comment #9 (was using 52.9.1 with no problem).
I confirm the issue is back : many of my users have it (and never had it before).
I am also having this issue, using Thunderbird 60.2.1 on Windows 10 (1803) and am seeing it also when moving messages from one folder to another.
We're also having this issue on our corp environment since updating to 60.2.1. Able to replicate the fault but not workaround it. Rolling back to previous version seems to fix the issue, even for emails that have already had their code changed. As mentioned already seems to be an issue with the code being stripped out for signatures here and being replaced with... src="imap://......." As mentioned above. This is becoming a major disruption here as we've recently rolled out 60.2.1 to the business. Has anyone found a workaround at all? Environment Windows 10 Pro Anthony
First post here, hope it helps - took half a day to find a (possible) solution/workaround, so guess it was worth going through the creating account procedure. Had the same issue after upgrading. Some machines worked, silently ignoring the imap://.. links, others produced the prompt. So, after tons of side-by-side trying, discovered the following: The prompt occurs when mail.server.<serverXX>.socketType is set to anything other than '3', for SSL. It can be changed from the config editor, or, much easier: Account Settings > Server Settings > Connection Security: SSL/TLS No more prompts, at least on tb win version 60.3.0 64bit, and assuming your server supports SSL connectivity.
Thanks for the feedback! I have some emails with the imap:// code in place that have been forwarded from other users' in the business and I'm getting those errors pop up. I have SSL/TLS by default, as does everyone in the company. Does not having the SSL selected stop the actual generation of the imap:// code from the sender or is this just a recipient issue on your side? Cheers Anthony
It is sender mailer (or webclient+server) generated, causing recipient issue - checked the stored emails on the server, the imap://.. was there. I also thought SSL was enabled on all machines, seems it wasn't the case after all. Soon as SSL/TLS got enabled, all popups stop (no need for restart). As for the creation of the IMAP://.. links (instead of images), it could be either sender's mailer, or web interface + mail server, i'd presume. Checking the 'sent items' folder of a sender would be the best place to start, assuming a copy has been kept.
Yeah, the error in the code is generated on the client. We've had the issue for weeks now. Opening the items in "sent" generates the error on the sender's machine as well as the recipient's. Suppressing it on the recipient's side would be half the battle won! Testing with the SSL has been inconclusive this side. Disabling SSL on my client seems to work...not on someone else's. Will continue but thanks for the lead! Let me know how you get on... Anthony
Also verified it's client generated. Furthermore, it seems it's client settings -not version- specific. Two machines, same dpt, same tb version. One sends images in signature as attachments, the other generates links. So, the only difference with tb versions, seems to be how those links are handled by the recipient (popups), and not if they are generated or not. Now, as for which setting generates the links, guess will be able to check later today. Will post back any findings.
I confirm this issue still exists with version 60.3.0 (Win), which annoyingly is the first version to prompt users for an automatic upgrade. We use Connection Security: None because our server/clients are all internal, so I can't test whether buying a certificate would fix it. Staying on 52.9.1 until there's more positive news.
No need to buy a certificate. A self-signed one can be used. You can check your server, might have built-in option to generate one. Then, all you have to do when enabling SSL at the clients is to accept the certificate when prompted - for certs from trusted authorities, you get no prompt. There might (should) be a setting in thunderbird for accepting self-signed cets with no verification prompt. I have seen mobile mail clients that offer this option - never had to check if tb does as well, though.
And, the culprit for the creation of the imap://.. links is: mail.inline_attachments Open config editor, set it to true (default), and you are done. Way to check: Open a mail with signature, click reply, scroll to see if the image is visible. If not, inline_attachments is disabled, and the imap:// link will be generated. Change the value to it's default, try the above procedure again, the image in the signature should be visible - and no pop-ups on the recipient side, despite the version. By doing the above, you are sending emails properly. By performing the previous config (SSL, described in previous post), you prevent the recipient's client from generating the popups when a mail with imap:// links is received. Hopefully now that the cause on both ends has been identified, a fix in a future version will be applied.
Thanks for the information, that's really helpful. My personal TB is set to true, but that makes sense as I haven't been generating the code when forwarding emails. Going to run some tests with users today, will let you know how I get on.
And, the issue wasn't fully resolved with the previous method. Seems that the prompt is produced if the type of the IMAP:// link is the same as the connection the recipient is using. E.g, links ending with :993 will produce the popup if the recipient is using SSL. Soooo, if you really want to get rid of the popup -don't know if there are any sideffects-, some easy cracking is required. First, to be on the safe side, make a copy of the file you'll select, and of your profile. Then, with a disk editor (actually, notepad++ worked for me) open either the file omni.ja or xul.dll, in the thunderbird installation folder, search for the string "imapSubscribePrompt", and change one of it's letters. E.g. make it "imapSubscribePrompX". Don't append a letter, just change one - the size must not be modified. This should get rid of the prompts. Now, as for the config that sends the IMAP:// links, I found a machine that did generate them despite having 'inline' enabled (see previous posts). Just removing and adding the account again fixed it. Kept the profile though to check to see what was causing it.
Just confirming this bug still exists with version 60.3.1 (Win). Downgrading again.
Version 60.3.3 still has this bug.
Thanks for letting us know. I'm going to try the above "imapSubscribeprompt". Has their been any adverse side effects to the workaround at all?
No side effects so far - I modify the omni.ja, so i'd say go with that, instead of the xul.dll. Just make sure to change just one character (in place change, preserve filesize), otherwise, thunderbird wont load. As I get it, what the modification does is: thunderbird checks for the function imapSubscribePrompt in omni.js (which would generated the prompt), doesn't find it, and just does nothing instead. If there is interest express here, i'll try to find some time to create a patcher to simplify the procedure.
Question. How do I edit the omni.ja file? My one is blocks of numbers (in the program files dir). Couldn't see one in the profile dir.
It's in program dir. Just search for the string 'ImapSubscribePrompt'. It's located well bellow the initial binary content. line 365906 on the version i just checked.
Hmm, yeah I tried exactly that, the file is there but the content is just number blocks, top to bottom (45mb's worth!) and that string doesn't exist anywhere else...strange. I checked the profile dir too just in case. I'm running 32bit v6.3.0
Haven't tried the 32bit version, just the 64bit one. Which editor did you open the file with? And how many total lines does it report? I suppose that some text editors will truncate a binary file.
Sublime text. Line 365906 "222c 2022 6e6f 726d 616c 222c 2022 7369" Total 2997965 lines.....all the same as above, strange.
Seems like you are viewing the file as hex. Check if there is an option to view as text file. If on windows, try open it with notepad - just to check the content, i wouldn't save it afterwards + it might take a while to load. As mentioned before, I used notepad++. If you can download it. Very good editor, and free.
Comment on attachment 9099762 [details] [diff] [review] subscribe-fix.diff (proposed patch) Wow, very old bug from 2003. I think your approach is good and we already have confirmation that it's working. I'm happy to r+ this unless you want feedback from Magnus (who's on PTO this week). I can land the patch if you want and remove the print for you. Let me know.
Attachment #9099762 - Flags: feedback?(jorgk) → review+
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.