Attachments sent to me not arriving
David Thomas
A client has been trying to send me an attachment from his hotmail.com
address, but no attachment has shown up at this end. He says others have
received this attachment without any trouble. I seem to receive attachments
from other senders without any trouble.
Any suggestions for what he and/or I might try to resolve this?
David Thomas
white...@fastmail.us
consider to be "dangerous" attachments and do so silently. Do you have
another email account to which they can send? If so, try that to see if
your email system is stripping it.
Mike Easter
> A client has been trying to send me an attachment from his hotmail.com
> address, but no attachment has shown up at this end. He says others have
> received this attachment without any trouble. I seem to receive
> attachments from other senders without any trouble.
>
> Any suggestions for what he and/or I might try to resolve this?
You didn't identify the receiving mail server or the attachment's size,
but if you are referring to your connectivity provider, it has a pretty
small allowance for your mailbox. One place says 10 megs, another says 50.
If the attachment is too large and the mail is bounced, your sender
might be unaware of the bounce. You also didn't say whether or not you
had received the email which is supposed to have the attachment but with
the attachment stripped/missing or not.
Large file transfers should be accomplished by other means than email,
and/but if my only email account limit were 10 megs, I would be getting
an additional larger free mailbox such as gmail. Gmail's mailbox is
7600+ megs and attachment max is 25 megs.
--
Mike Easter
Thomas Boehm
So you're saying that you got the email with no attachment? Can you see
something like
--000e0cd28d22d220a704abba0988
Content-Type: application/pdf; name="xyz.pdf"
Content-Disposition: attachment; filename="xyz.pdf"
if you view the source of the email (Ctrl+U)?
David Thomas
> I have found that some mail servers are configured to strip what they
> consider to be "dangerous" attachments and do so silently. Do you have
> another email account to which they can send? If so, try that to see if
> your email system is stripping it.
I did try that (using my gmail account) and it worked. The attachments were
present when I logged into my gmail account on the web. However, when the
message arrived on my gmail account in TB, the attachments were not
present. The attachments were pdfs which appeared to be scans of documents.
Anyway, thanks for your advice.
David Thomas
David Thomas
> You didn't identify the receiving mail server or the attachment's size, but
> if you are referring to your connectivity provider, it has a pretty small
> allowance for your mailbox. One place says 10 megs, another says 50.
>
> If the attachment is too large and the mail is bounced, your sender might
> be unaware of the bounce. You also didn't say whether or not you had
> received the email which is supposed to have the attachment but with the
> attachment stripped/missing or not.
>
> Large file transfers should be accomplished by other means than email,
> and/but if my only email account limit were 10 megs, I would be getting an
> additional larger free mailbox such as gmail. Gmail's mailbox is 7600+ megs
> and attachment max is 25 megs.
Thanks. See my reply to whitedavidp. There were two attachments, each less
than 900kB, so I don't think size was the problem. The text of the e-mail
was OK, just the attachments were missing.
David Thomas
David Thomas
> So you're saying that you got the email with no attachment? Can you see
> something like
>
> --000e0cd28d22d220a704abba0988
> Content-Type: application/pdf; name="xyz.pdf"
> Content-Disposition: attachment; filename="xyz.pdf"
>
> if you view the source of the email (Ctrl+U)?
Thanks. The nearest approximation is -
--_d1ef7b20-4c5a-4b05-86e7-a489ea85bec2_
Content-Type: multipart/alternative;
boundary="_27282f9a-7908-4069-b1f4-81241772e58f_"
--_27282f9a-7908-4069-b1f4-81241772e58f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
No apparent reference to any attachment or filename.
Please also see my replies to the other two responders. My immediate
problem has been resolved, but it would be nice to know why this happened.
It has not happened to me before AFAIK.
David Thomas
Mike Easter
> Thanks. The nearest approximation is -
>
> --_d1ef7b20-4c5a-4b05-86e7-a489ea85bec2_
> Content-Type: multipart/alternative;
> boundary="_27282f9a-7908-4069-b1f4-81241772e58f_"
>
> --_27282f9a-7908-4069-b1f4-81241772e58f_
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> No apparent reference to any attachment or filename.
>
> Please also see my replies to the other two responders. My immediate
> problem has been resolved, but it would be nice to know why this
> happened. It has not happened to me before AFAIK.
You can examine the message source of the intact item in your gmail webmail.
In gmail webmail, open the mail item which has the .pdf attachment. In
the upper right corner of the mail is an arrow to the right of the Reply
button which will display a menu, one item of which is 'Show original'
The layout of such a mail message is:
headers
multipart MIME statement
x multiparts
The last multipart delimiter is supposed to have 2 more leading
hyphens/dashes before the delimiter string defined in the header.
The idea being to dissect the intact item in gmail's webmail compared to
the item in Tbird; focusing on the delimiters to see if there is a clue
why Tbird or your mailserver broke the message.
--
Mike Easter
Greywolf
If the last delimiter starts dash-dash-space, then everything following
will be a "signature", and will be stripped when mail is forwarded or
replied to. Eg, your signature is delimited "correctly", displays as
greyed text, and is stripped when I reply to your post. IMO, it's kinda
dopey to hang onto this leftover from the days when memory and bandwidth
was expensive; it should be abandoned. I don't use dash-dash-space anymore.
IIRC, it was forwarded mail that lost the PDFs. OP could try editing the
Gmail version of the mail before forwarding it to himself.
HTH
Wolf K.
Mike Easter
> Mike Easter wrote:
>> The last multipart delimiter is supposed to have 2 more leading
>> hyphens/dashes before the delimiter string defined in the header.
> If the last delimiter starts dash-dash-space, then everything following
> will be a "signature",
The last delimiter shouldn't be following the/its two dashes with a
space; that is, there shouldn't be a space leading the delimiter.
> and will be stripped when mail is forwarded or replied to. Eg, your
> signature is delimited "correctly", displays as greyed text, and is
> stripped when I reply to your post. IMO, it's kinda dopey to hang
> onto this leftover from the days when memory and bandwidth was
> expensive; it should be abandoned. I don't use dash-dash-space
> anymore.
I don't believe we are talking about a sig delimiter problem and I don't
agree with your position on (not) using sig delimiters.
But it could be that we are talking about 'some kind of' delimiter
problem/handling by something - which is the reason for dissecting the
delimitation/MIME structure.
> IIRC, it was forwarded mail that lost the PDFs. OP could try editing
> the Gmail version of the mail before forwarding it to himself.
He didn't say whether the mail was supposed to be getting to him from
gamil by being forwarded, popped, or imapped.
--
Mike Easter
David Thomas
for me. My gmail account on TB is a POP account. I set it up (following
instructions from a source that I cannot now recall) so that messages into
my gmail webmail account would automatically show up in TB. So I guess you
would say that it is popped from gmail to TB?
I tried to follow Mike's suggestion to look at the source of the original
message in my gmail webmail, but it wasn't there any more. I must have been
lucky to catch it there before it was sent on to my gmail account in TB. I
hope this makes sense.
Mike Easter
> I tried to follow Mike's suggestion to look at the source of the
> original message in my gmail webmail, but it wasn't there any more. I
> must have been lucky to catch it there before it was sent on to my gmail
> account in TB. I hope this makes sense.
The Tb gmail pop account can be configured in Tbird or in Gmail webmail
settings to leave the popped mail on the gmail server, which some people
do because gmail's large storage is useful for various purposes.
Also, even if you are configured to delete the message from the gmail
server after it is popped, gmail may retain that deleted mail for 30
days. If so, you would find it in trash.
http://mail.google.com/support/bin/answer.py?hl=en&answer=13288&topic=12811
Gmail offers enough storage to keep copies of messages you might need
to search for later. By leaving mail on our servers, you can download it
to other computers in the future.* If you really don't want your
messages stored in Gmail, you can automatically delete them when they
are accessed with POP. After thirty days, deleted messages are
permanently removed from Gmail.
--
Mike Easter
David Thomas
suggested. Could not find any "trash" on gmail, but eventually found "Bin"
which was hidden. In it was "the" message! The header was (asterisks
obscure some parts for privacy reasons):
Delivered-To: ******@gmail.com
Received: by 10.204.55.210 with SMTP id v18cs30207bkg;
Sun, 4 Sep 2011 18:35:23 -0700 (PDT)
Received: by 10.220.39.195 with SMTP id h3mr937130vce.202.1315186519304;
Sun, 04 Sep 2011 18:35:19 -0700 (PDT)
Return-Path: <*********@hotmail.com>
Received: from blu0-omc2-s22.blu0.hotmail.com
(blu0-omc2-s22.blu0.hotmail.com [65.55.111.97])
by mx.google.com with ESMTP id
z16si1283528vcv.192.2011.09.04.18.35.16;
Sun, 04 Sep 2011 18:35:19 -0700 (PDT)
Received-SPF: pass (google.com: domain of ********@hotmail.com designates
65.55.111.97 as permitted sender) client-ip=65.55.111.97;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of
******@hotmail.com designates 65.55.111.97 as permitted sender)
smtp.mail=********@hotmail.com
Received: from BLU165-W17 ([65.55.111.72]) by
blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
Sun, 4 Sep 2011 18:35:11 -0700
Message-ID: <BLU165-W17E0D66EA...@phx.gbl>
Return-Path: ********@hotmail.com
Content-Type: multipart/related;
boundary="_8fe9cbad-8a30-4178-9e9b-d8d71b1700d1_"
X-Originating-IP: [121.91.47.217]
From: ******* <********@hotmail.com>
To: <******@gmail.com>
Subject: *********
Date: Mon, 5 Sep 2011 11:05:10 +0930
Importance: High
In-Reply-To: <BLU165-W36791876F...@phx.gbl>
References:
<4D0E9C7E.9050106@*******.com.au>,<BLU165-W64037B2C3...@phx.gbl>,<4E5C9373.9010504@********.com.au>,<BLU165-W44C5B5E87...@phx.gbl>,<4E5DED8A.4010207@********.com.au>,<BLU165-W36791876F...@phx.gbl>
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Sep 2011 01:35:11.0533 (UTC)
FILETIME=[0D93C5D0:01CC6B6C]
--_8fe9cbad-8a30-4178-9e9b-d8d71b1700d1_
Content-Type: multipart/alternative;
boundary="_c9de87ef-44f5-42df-bd3c-da1bfeb25c90_"
--_c9de87ef-44f5-42df-bd3c-da1bfeb25c90_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Further down was this:
--_c9de87ef-44f5-42df-bd3c-da1bfeb25c90_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
followed by many lines of html coding, at the end of which was this:
--_c9de87ef-44f5-42df-bd3c-da1bfeb25c90_--
--_8fe9cbad-8a30-4178-9e9b-d8d71b1700d1_
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="blu c.pdf"
After that came probably thousands of lines of gibberish (representing an
image?). Then came this:
--_8fe9cbad-8a30-4178-9e9b-d8d71b1700d1_
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="blu c 1.pdf"
then thousands more lines of similar gibberish and at the very end was this:
--_8fe9cbad-8a30-4178-9e9b-d8d71b1700d1_--
The two attachments were called "blu c.pdf" and "blu c 1.pdf". I guess
that's obvious to you.
Please tell me if I am taking liberties sending all this to the group.
Jon
Attachments are showing when viewing emails with Outlook via IMAP, but
not when using Thunderbird 6.0.1
Jonathan Kamens
server stripping the attachments when the message is
downloaded into TB.
Rather, the problem is that the mail program used by the
sender of the message formatted it incorrectly, by putting the
attachments in a multipart/related MIME part rather than a
multipart/mixed MIME part.
Without getting too technical, suffice it to say that the
message is not formatted properly, but this particular
misformatting is somewhat common, other mail clients are more
forgiving about it, and previous versions of TB were also more
forgiving about it.
The behavior of TB "broke" (mind you, it's not really "broken"
per se, since as I mentioned the messages are not formatted
properly and how TB is displaying them is therefore not
entirely unreasonable) when I fixed another bug which was
preventing TB from removing attachments from such messages.
The other bug fix caused TB to start being more strict about
interpreting message structures and introduced this new
problem.
Starting in TB 8.0, there will be a new menu item, "View |
Message Body As | All Body Parts", which I added to work
around this issue, which will expose these hidden attachments.
Unfortunately, the folks who maintain the TB UI have decided
that this problem is not sufficiently widespread to make this
new menu item visible by default, so they've hidden it, and
you have to install the "Show All Body Parts" extension to
make it visible.
There is also an open TB bug about making this behvaior more
intuitive:
Greywolf
>
> Please tell me if I am taking liberties sending all this to the group.
No, because
a) going to all this trouble put all that information into your memory,
so that
b) when someone explains what's obscure to you, you are more likely to
understand.
In this case, the "gibberish" you mention encodes the PDF files. E-mail
is transmitted in plain text, so all non-text messages have to be
translated into plain text characters. Thus images, PDFs, etc will show
up as block as gibberish.
The puzzle is, why did Gmail strip the PDFs and trash the original
message? My guess is that their spam/AV filters are a little too
aggressive, and flagged the attachments as possible spam or malware. I
don't use Gmail, so I don't know whether you can reset the spam filters
that apply to your account, but I'd find out if I were you, and do so.
The effect will be more spam coming through until the reset filter is
again trained to your liking.
HTH
Wolf K.
Greywolf
> The problem you are seeing has nothing to do with the mail
> server stripping the attachments when the message is
> downloaded into TB.
Thanks for this information, Jonathan, helps a lot.
Wolf K.
Mike Easter
> this particular misformatting is somewhat common, other mail clients
> are more forgiving about it, and previous versions of TB were also
> more forgiving about it.
> Unfortunately, the folks who maintain the TB UI have decided
> that this problem is not sufficiently widespread to make this
> new menu item visible by default, so they've hidden it, and
> you have to install the "Show All Body Parts" extension to
> make it visible.
Thank you for the explanation and fixes.
The/One problem with something being semi-broken and requiring an
extension to fix is that extensions tend to break with each frequent
(potentially unidentified unnumbered) version change.
--
Mike Easter
Mike Easter
> Mike Easter wrote:
>> Also, even if you are configured to delete the message from the gmail
>> server after it is popped, gmail may retain that deleted mail for 30
>> days.
> Could not find any "trash" on gmail, but eventually found
> "Bin" which was hidden. In it was "the" message!
Goodjob. I see you are Oz, which explains the bin/trash. :-)
> Content-Type: multipart/related;
> boundary="_8fe9cbad-8a30-4178-9e9b-d8d71b1700d1_"
> --_8fe9cbad-8a30-4178-9e9b-d8d71b1700d1_
> Content-Type: multipart/alternative;
> boundary="_c9de87ef-44f5-42df-bd3c-da1bfeb25c90_"
>
> --_c9de87ef-44f5-42df-bd3c-da1bfeb25c90_
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> --_c9de87ef-44f5-42df-bd3c-da1bfeb25c90_
> Content-Type: text/html; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> --_c9de87ef-44f5-42df-bd3c-da1bfeb25c90_--
>
> --_8fe9cbad-8a30-4178-9e9b-d8d71b1700d1_
> Content-Type: application/pdf
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="blu c.pdf"
> --_8fe9cbad-8a30-4178-9e9b-d8d71b1700d1_
> Content-Type: application/pdf
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="blu c 1.pdf"
> --_8fe9cbad-8a30-4178-9e9b-d8d71b1700d1_--
> Please tell me if I am taking liberties sending all this to the group.
I think it is fine because it helps us understand. Some people get this
as mail in their mailbox, but that is their own choice to download and
delete at will.
Here I'm using 'shorthand' of 8fe and c9d to abbreviate the two
different delimiters for the multipart related and multipart alternative.
There is a nested MIME structure, where the overall is the 8fe related
and the substructure is the c9d html alternative, with the .pdf/s
attached to the 'fundamental' 8fe related.
Personally I don't think that structure is all that bad to get broken,
but then I'm not the one who has to 'build code things' to interpret the
variabilities in MIME structure.
--
Mike Easter
Ron K.
There is one bit that caught my attention, so wonder way others think.
Note the file names of the attachments, that they have spaces, not the %20
one would expect with valid web oriented encoding. To me the originating
sender may have set up the results by a system using local file names and
the mail client not converting the spaces to %20.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
Ron K.
Im my reply in another sub-thread I wondered about the attachments file
names which have unencoded spaces. Is such a case a red herring or is it
related to why the attachments seem to be missing. I'm thinking that if TB
tries to handle the attachment that the temp file it creates will not have
a valid file extension, thus the OS is not able to match the temp file to
a registered application.
Jonathan Kamens
>The/One problem with something being semi-broken and requiring an
>extension to fix is that extensions tend to break with each frequent
>(potentially unidentified unnumbered) version change.
I don't necessarily disagree, but (a) Mozilla is getting a
lot better about auto-updating the version compatibility of
extensions when new releases come out, and (b) as for my
extensions in particular, I am very aggressive about keeping
them up-to-date. I run Thunderbird nightly builds, so my
extensions are marked compatible months before corresponding
Thunderbird releases become available.
Jonathan Kamens
>Im my reply in another sub-thread I wondered about the attachments file
>names which have unencoded spaces. Is such a case a red herring or is it
>related to why the attachments seem to be missing.
I believe it's a red herring.
JoeS
> The/One problem with something being semi-broken and requiring an
> extension to fix is that extensions tend to break with each frequent
> (potentially unidentified unnumbered) version change.
You can also manually add the hidden pref in lew of using the extension.
mailnews.display.show_all_body_parts_menu (Boolean)set to true.
(Now I've gone and done it...It's no longer hidden)
--
JoeS Using TB 9.0.."I am endeavoring to construct a pneumonic memory
circuit using stone knives and bear skins."(Spock)
<http://kb.mozillazine.org/Thunderbird_6.0,_etc.>
Daily Build Thread RSS feed http://th3oretiker.de/stuff/thunderbirdfeed.xml