Closed Bug 1822218 Opened 2 years ago Closed 2 years ago

Thunderbird IMAP sync removes inline JPG and presents as attachments

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Version:
Thunderbird 102
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 61815

People

(Reporter: jamesmknott, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36

Steps to reproduce:

I received a message (containing text & inline jpg intermixed) in my att.net (actually it is yahoo.net) webmail INBOX. I then forwarded this message to that same account at att.net and also my gmail.com account. The SENT message (in SENT webmail folder) on att.net webmail looks identical (after the "forwarding ... words of course). Note that Thunderbird IMAP is setup for both the att.net and gmail.com email.

Actual results:

This message on gmail webmail and att.net webmail INBOXes look correct. FYI.

Both the gmail.com & att.net Thunderbird INBOX messages arrive via Thunderbird IMAP sync -- but the message body topmost contains all the text, then followed by all JPGs attached. -- THUNDERBIRD IMAP sync sometimes does not work correctly.

ALSO, similar problem occurs if INSTEAD of forwarding original file to myself at att.com, if using att.net webmail I save the UN-sent forwarded draft to the att.net webmail DRAFT account -- when Thunderbird IMAP sync occurs, the version in the Thunderbird DRAFT account has text separated from all the attached JPGs.

Expected results:

Both the gmail.com & att.net Thunderbird INBOX messages (containing text & inline jpg intermixed) that arrive via Thunderbird IMAP sync should still have text & inline jpg intermixed and appear identical to 1) gmail.com and att.net webmail INBOXes, and 2) att.net webmail SENT folder.

Component: Untriaged → Networking: IMAP
Product: Thunderbird → MailNews Core

PS: I have NO IDEA why some of the description of this bug is in HUGE font size. It is not something I (knowingly) did, and I don't even know how I COULD have made such big text anyhow. Just FYI.

(In reply to jamesmknott from comment #1)

PS: I have NO IDEA why some of the description of this bug is in HUGE font size. It is not something I (knowingly) did, and I don't even know how I COULD have made such big text anyhow. Just FYI.

Probably something in your comment 0 that is being seen as markdown symbols. You can edit the post and look for things in there like multiple dashes, tildes etc that might be seen as markdown. Before saving your edit there's also a "preview" so you can check that it's fixed.
The link at the bottom about markdown may help. FYI, I had this happen too.

Steps to reproduce:

I received a message (containing text & inline jpg intermixed) in my att.net (actually it is yahoo.net) webmail INBOX. I then forwarded this message to that same account at att.net and also my gmail.com account.

Was forwarding done with tb or webmail?

The SENT message (in SENT webmail folder) on att.net webmail looks identical (after the "forwarding ... words of course). Note that Thunderbird IMAP is setup for both the att.net and gmail.com email.

Actual results:

This message on gmail webmail and att.net webmail INBOXes look correct. FYI.
Both the gmail.com & att.net Thunderbird INBOX messages arrive via Thunderbird IMAP sync -- but the message body topmost contains all the text, then followed by all JPGs attached. -- THUNDERBIRD IMAP sync sometimes does not work correctly.

So you mean they came into tb with the .jpg stuff as attachments at the bottom instead of inline with the html?
Did this happen for both the yahoo/att and gmail?

ALSO, similar problem occurs if INSTEAD of forwarding original file to myself at att.com, if using att.net webmail I save the UN-sent forwarded draft to the att.net webmail DRAFT account -- when Thunderbird IMAP sync occurs, the version in the Thunderbird DRAFT account has text separated from all the attached JPGs.

So I think you mean these are html formatted message with embedded graphics (.jpg) and when tb fetches them from yahoo imap the text is OK but the .jpgs are actual attachments?

Can you provide a sample message of equivalent size that has this issue when fetched by tb from yahoo/ATT and gmail?

Thanks for your efforts! I'll look at your above stuff later tonight and post back answers.

I will look into the font size question later.

Was forwarding done with tb or webmail? >> Forwarded from att.net (yahoo) webmail to both my gmail.com & att.net accounts.

So you mean they came into tb with the .jpg stuff as attachments at the bottom instead of inline with the html? >> Correct
Did this happen for both the yahoo/att and gmail? >> Yes, both look identical, with .jpg as attachements as seen by TB, but inline as seen by both webmail services.

So I think you mean these are html formatted message with embedded graphics (.jpg) and when tb fetches them from yahoo imap the text is OK but the .jpgs are actual attachments? >> Yes, I believe the text is OK (note that text is formatted, color, size, etc so I presume it's HTML formatted), but all the .jpg have simply been removed from being inline with the text, and instead appear as attachments
(as in "<paperclip_icon> 13 attachments <download_icon> Save All" at the bottom of TB preview.

Is it possible that the inline .jpg images are external links? If so, there's a setting at yahoo under "Viewing email" => "Show images in messages" that may affect how yahoo imap sends messages to clients like tb. Try setting it to "Always except in spam folder" and see if that helps if your .jpgs are links. This shouldn't affect messages with the .jpg bytes directly embedded in the email. Anyhow, just a possibility.

I've been able to create a message like you describe (text/jpg/text/jpg/text...) in yahoo Drafts but when I copy it to a regular yahoo folder, tb only displays partial images. So not sure what's going on.
But if I copy it to a non-yahoo server like dovecot, it displays OK in tb. So I'm pretty sure yahoo is doing something it shouldn't. Looks like it's only returning a partial fetch for this too. So my guess right now is this and bug 1821755 are dupes.

Ok, I'm seeing the same thing when I forward a message with inline .png from within yahoo webmail. It looks right when view from inside yahoo and gmail webmail but shows attachments and empty placeholders when view at yahoo and gmail accounts in tb.
So, for this issue, don't need sample email or a log, for now.

OK, thanks for letting me know. I'll be glad to help in the future if you just let me know whatever you need. In the meantime. I'll be doing nothing here.

More questions. Are you seeing square empty boxes in the message where you would expect to see the images?
Do you have View -> Display attachments inline checked/enabled?
Do you have View -> Message Body As -> Original HTLM selected?

I don't see these making a difference for me but you might check these and see what you see.

At yahoo webmail I can grab the message source (... View newest raw message) and save it to file yahoo.eml and open that file with TB and it looks fine. But if I let tb fetch the message via imap, the resulting .eml file (from tb save source) shows text and only attachments like you see. For some reason yahoo sends the file via imap in a way the tb can't decode correctly. I tried opening the .eml with an old tb version (68) and see the same problem, so it's not anything recently changed in tb causing this. I need to try to open the .eml returned by yahoo imap in another email app and see if it can handle it.
:
I only have two other installed linux based mail clients, Claws and Trojita (both fairly crude). Claws didn't show any attachments or inline images, just text. But Trojita show the inlines like it should, but also showed the images as attachments; maybe that's a feature, not sure. I'll create a simple and hopefully short example and try it with client Evolution (less crude) which I can download/install. It's looking like this is a real tb bug (TBD).
:
I've now tried it with Evolution and see the same as with Trojita. The file that displays with no inlines on tb show inlines in Evo and on Trojita, but both also show the inline images as attachments at the bottom. The file that displays with inlines in tb also displays as inlines on Trojita and Evo with no attachments shown at the bottom.

So yahoo is providing tb a good .eml to display via imap (works OK on two other clients) but tb is not showing the images as inline graphics but only as attachment at the end.
So bug confirmed. I'll try to attach a simple example email that shows the bug.
(Note: Seems like this should have been reported at some time in the past but I haven't found anything after searching.)

Status: UNCONFIRMED → NEW
Ever confirmed: true

your question: Are you seeing square empty boxes in the message where you would expect to see the images?

Here's what I see when it works correctly:
Two text lines
Five jpgs
two text lines
three jpgs
one text line
one jpg
one text line
one jpg

Here's what I see when it's wrong:
Two text lines
one empty square box {instead of a jpg I suppose - only ONE box, NO MORE empty boxes anywhere in displayed messages)
four text lines
Eleven jpgs as attachments

So I do see ONE empty box, but not an empty box for each jpg.

your question: Do you have View -> Display attachments inline checked/enabled? >> It is checked/enabled on ALL messages, good and bad.

your question: Do you have View -> Message Body As -> Original HTLM selected? >> yes, on ALL messages, good and bad.

PS: Note that I'm running Thunderbird on Windows 10, not Linux (FYI, probably doesn't matter).

James,
After talking with an expert on mail formats I have some more questions to ask.

  1. When you see an email with the inline images that are moved to attachments, is the sender of that email also using yahoo? I guess if the sender's address contains "yahoo" or "att" they are using yahoo as their SMTP (outgoing/sending) server.
  2. Can you show the source on one of your problem messages? To do this, open the corrupted message and click the "More" button in the preview/viewing pane and then click View source OR select menu item "View" and then click "Message source" OR just press ctrl-u. In the window that opens, search for "multipart". Do you see multipart/mixed or do you see others like multipart/alternative or multipart/related. If you see a multipart/mixed it causes TB to show the images as attachments and is getting improperly formatted by yahoo.
  3. Check the source on a message that comes in OK with images properly inline. It should not contain multipart/mixed but instead it should have multipart/related.
    Thanks!

The "sender" question is a little complicated:

  1. I have seen the "truncated" jpg/email problem Bug 1821755 on several emails that my friend sent from his gmail account. I have also seen it from my sister's gmail account. I don't have many friends that use att.net (nor yahoo), but I have NOT seen it from the one att.net friend I do have.
  2. I have seen this "attached jpgs not inline" Bug 182218 when I, on my att (yahoo) webmail, forwarded the original newsletter (from my gmail friend) back to my (same) att.net account - I was doing this to create test emails for the other (1821755) bug. Honestly, I cannot remember if I've ever seen it from any other source than when I'm sending test emails from my att.net webmail. Like most people, I get lots of emails daily (none from yahoo people) and they don't seem to have this Bug 182218 problem. I have the (unsure) impression that I haven't seen this Bug 182218 until about when we started debugging this together. (Of course, if this problem truly only occurs when I'm sending yahoo webmail to myself, I can simply stop doing that). Note that when I forward to myself using att webmail and TB shows it as "attached jpgs not inline" that when I look at the same FORWARDED email on att.net webmail INBOX (or SENT) it ALWAYS looks fine (but of course I don't know that when att forwards mail to itself if it uses IMAP or what). So for Bug 182218 I have no CURRENT PROOF that it occurs other than when yahoo forwards a gmail message, so it simply could be a yahoo (forwarding) problem??. (Of course, this isn't the case for the other Bug 1821755 which has nothing to do with FORWARDING).

A GOOD email (having the pictures inline) has lines with the word "multipart" as
one line with "Content-Type: multipart/alternative;"
One line with "Content-Type: multipart/related;"
There are NO lines with the word "fixed" in the message.

A BAD email (having all jpgs only as attachments)
One line with "Content-Type: multipart/mixed;"
One line with "Content-Type: multipart/alternative; "

I checked perhaps four good ones and four bad ones (my friend sends the email "newsletter" every day), and they all follow the above pattern.

See Also: → 61815

(In reply to jamesmknott from comment #11)

First off, you might want to edit the links in comment 11 to Bug 182218 since it's points to an old bug. Looks like you left out a 2 so should be Bug 1822218 (I fixed them in my quote of your comment below).

The "sender" question is a little complicated:

  1. I have seen the "truncated" jpg/email problem Bug 1821755 on several emails that my friend sent from his gmail account. I have also seen it from my sister's gmail account. I don't have many friends that use att.net (nor yahoo), but I have NOT seen it from the one att.net friend I do have.

Ok, I need to look at bug 1821755 again. The interim workaround is to just disable fetching by chunks. For now, that should fix the truncation problem.

  1. I have seen this "attached jpgs not inline" Bug 1822218 when I, on my att (yahoo) webmail, forwarded the original newsletter (from my gmail friend) back to my (same) att.net account - I was doing this to create test emails for the other (1821755) bug. Honestly, I cannot remember if I've ever seen it from any other source than when I'm sending test emails from my att.net webmail. Like most people, I get lots of emails daily (none from yahoo people) and they don't seem to have this Bug 1822218 problem. I have the (unsure) impression that I haven't seen this Bug 1822218 until about when we started debugging this together. (Of course, if this problem truly only occurs when I'm sending yahoo webmail to myself, I can simply stop doing that). Note that when I forward to myself using att webmail and TB shows it as "attached jpgs not inline" that when I look at the same FORWARDED email on att.net webmail INBOX (or SENT) it ALWAYS looks fine (but of course I don't know that when att forwards mail to itself if it uses IMAP or what).

It wouldn't be IMAP to forward a message since IMAP is only used by clients (like TB) to retrieve emails, not to send or forward them.

So for Bug 1822218 I have no CURRENT PROOF that it occurs other than when yahoo forwards a gmail message, so it simply could be a yahoo (forwarding) problem??. (Of course, this isn't the case for the other Bug 1821755 which has nothing to do with FORWARDING).

So I think you are saying you are not seeing any problem with inline images only showing as attachments unless you forward stuff within yahoo/att webmail. You are NOT seeing this issue on emails received from other people. If so, that's good to know and this isn't as big a problem for you as I was thinking it is.

A GOOD email (having the pictures inline) has lines with the word "multipart" as
one line with "Content-Type: multipart/alternative;"
One line with "Content-Type: multipart/related;"
There are NO lines with the word "fixed" in the message.

A BAD email (having all jpgs only as attachments)
One line with "Content-Type: multipart/mixed;"
One line with "Content-Type: multipart/alternative; "

Yes, that's exactly what I was hoping you would report!

I checked perhaps four good ones and four bad ones (my friend sends the email "newsletter" every day), and they all follow the above pattern.

Correct me if I'm wrong but I think (and hope) you are saying that the "BAD" emails are just ones you forwarded within yahoo/att webmail as a test of the other Bug 1821755 and not the newsletters from your friend.

Anyhow, pending a few more confirmations from you, I think we can mark this bug as a duplicate of the (very old) bug 61815.

I apologize for bug number typo above. I have googled for "how to change bugzilla comment" and found nothing that helps me change the typo (or huge text markdown error) - not sure if I have appropriate authority? Will fix if I'm provided link to instructions.

You are correct. AFAIK, the "BAD" emails are just ones I forwarded within yahoo/att webmail as a test of the other Bug 1821755 and not the newsletters from my friend. I think?? I may?? have seen this problem from others in the past, but whatever it is not a big issue to me for sure. And I'm assuming that since bug 61815 hasn't been fixed (by yahoo, nor worked-around by TB), in 23 years, it's not going to be (which is OK with me).

Since we (now) believe that this bug is NOT a duplicate of Bug 1821755 I'll retest Bug 1821755 and put comments there.

I thank you for your fantastic help!

FYI, my conclusions: For the original newsletter from gmail friend sent to my att.net account I notice that....

  1. if received correctly via TB IMAP, and then I forward from TB to gmail webmail, then it arrives at gmail webmail FINE (with jpgs inline, not as attachments).
  2. if I forward (directly) from att.net yahoo webmail to gmail webmail, then it arrives at gmail webmail BAD (not with jpgs inline, but as attachments).
  3. if I forward from att.net yahoo webmail back to att yahoo webmail, then it arrives at att yahoo webmail FINE (jpgs inline), but if I then view this forwarded email via TB IMAP, it appears BAD (not with jpgs inline, but as attachments.

I conclude that forwarded the newsletter from yahoo webmail causes jpgs to be sent as attachments for both gmail and and TB IMAP, but not if sent to yahoo.

I apologize for bug number typo above.

No problem. I thought any commenter could edit their own post using the "pencil" icon to the far right of your name on each post. Not sure if it takes special privileges for that "edit icon" to appear.

Anyhow, sounds like all is OK and this isn't causing you any big problem. So I'll go ahead and close this as a duplicate of that other old bug.
Note: It will also be marked as "resolved" even thought it's not really.

Status: NEW → RESOLVED
Closed: 2 years ago
Duplicate of bug: 61815
Resolution: --- → DUPLICATE

I agree with you closing this problem as a duplicate.

Thank you for all your hard work here!

You need to log in before you can comment on or make changes to this bug.