Problems sending/attaching files in email using Linux

Hi All,

I have search this entire site but could not find anything on this topic, but I doubt that nobody had that before so it is probably so common knowledge that only a newbie like myself would nopt know.

Well, I am having trouble sending email attachments, more specifically pdf or jpeg files. I am able only so far to send .txt atachments so I know it is not the email program or some incompatibility. I have tried several different files (the largest being 40kb) and still have the same trouble.

I have tried Kmail and Firebird using my ISP's smtp (sprint), using gmail's SMTP, and directly within the gmail site using different browsers (Konqueror, Mozilla, and Firefox) but still no luck.

I have tried with Knoppix Live CD 3.4 & 3.7, Knoppix 3.7 Hdd install, and Ubuntu LiveCD and still have the same problem. And did so on 2 different computers.

The only thing I can think off is that there is a special parameter/config to set somewhere in Linux to adjust for this to work, but wherever I try I cannot find it, and it is most likely because I have been a MS Windows user for too long ;-)

Hope someone here can direct me to the right info to solve this.

Thanks in advance,

Francis

What kind of problems, are you getting any error messages?

If you are using Gmail, did you set up POP correctly in the Gmail settings?

I send attachments on a regular basis using Gmail, and even Hotmail (don't hate me, i'm trying to get away from it).
The difference being, I don't bother with the using Gmail as pop/smtp, I just do it from the web interface. Same goes for hotmail. No real need to pop/smtp if webmail works.
I know of no 'special' thing you must do to send attachments....., but if you're getting some type of errors, tell us about them.

I use kmail, have not had any problems with jpg attachments & have not had to do any special setups.

Thanks Fyrebird10, Green1 and CrashedAgain for your prompt replies...

Fyrebird10 ->

I do get an error message only when using Gmail on the web. Error is: Document Contains No Data. The other way I tried (thru SMTP) it just gets stuck at 87% transmission. According to gmail help site, Document Contains No Data error should only occur if I am transfering exe file or file larger than 10Mb, but the files I am trying to transfer are .jpeg and .pdf and none were larger than 40kb.

Green1 ->

Yes, POP settings are correctly set (ie I can receive mail without problem). SMTP works fine also using regular email or when attaching .doc files or .txt files, it only blocks with jpeg and pdf.
I also know it is not my ISP blocking the files since I can send attachments fine when doing it under Windows...

CrashedAgain ->

Well it is encouraging to know that I should not have trouble sending attachments. Still a mystery to me...

As far as connections go, I am using dialup from home. But the other PC i tried this on (using Knoppix Live and also trying Ubuntu Live) still had the same symptoms and it is using token ring...

Thanks for all your help...

Francis

Wow. If I didn't know any better I say, "What is the common denominator here?"
Is it the PC hardware, the user, what?
If what you are trying to do does not work on several different OS's, I'd say it ain't the OS. However, please don't misunderstand. I am not implying anything, but this just sounds weird.

This sounds like it could be a permissions issue or maybe that the hard drive you are pulling the data from is not mounted.

Hi Green1,

;-)

Yes, there are 2 common denominators here actually (but eh, it could very well be the user, so lets make that 3, however, as I said, I am not aware of any other way of sending files as attachments and when sending .doc files or text files this works just fine).

Well, the 2 OS tried under Linux are all Debian based. Did not tried non-debian distros yet. The other non-Linux based OS (MS Windows XP, and MS Windows 98 work fine so I did not list them in the original post)

The other common factor is that all test were being sent to a gmail address (either mine or my girlfriend's) but I never heard of a receptor side blocking the mail before it even sent.

PC Hardware is not common. Tried it on my home PC (AMD 1.7 Ghz) and my work laptop (IBM T41 has an Intel mobile cpu).

All that said, it is weird, I agree. In my 5 years doing tech support I have never heard of this...

Actually, you could help me eliminate one of those common denominators - can you try sending me a pdf as attachment (in the 40 kb range) to my gmail address? ( [email protected] )
and let me know if you get the same problem...

Thanks for helping...

Francis

Quote:

---

Originally Posted by francisgirard

Thanks Fyrebird10, Green1 and CrashedAgain for your prompt replies...

Fyrebird10 ->

I do get an error message only when using Gmail on the web. Error is: Document Contains No Data. The other way I tried (thru SMTP) it just gets stuck at 87% transmission. According to gmail help site, Document Contains No Data error should only occur if I am transfering exe file or file larger than 10Mb, but the files I am trying to transfer are .jpeg and .pdf and none were larger than 40kb.

Green1 ->

Yes, POP settings are correctly set (ie I can receive mail without problem). SMTP works fine also using regular email or when attaching .doc files or .txt files, it only blocks with jpeg and pdf.
I also know it is not my ISP blocking the files since I can send attachments fine when doing it under Windows...

CrashedAgain ->

Well it is encouraging to know that I should not have trouble sending attachments. Still a mystery to me...

As far as connections go, I am using dialup from home. But the other PC i tried this on (using Knoppix Live and also trying Ubuntu Live) still had the same symptoms and it is using token ring...

Thanks for all your help...

Francis

---

Maybe a dumb idea but try renaming a jpg file as .doc or .txt or something just to see if it will work.

francisgirard,

sent you a .pdf (44k) file thru gmail.

Also, just as a tip, you might not want to type your full email address for public viewing because data miners will gather them and send you junk mail.
do this:

francisgirard <at> gmail <dot> com

or something similar.

Hi All,

CrashedAgain -> yeah I tried that one both ways - renaming a jpg with .txt and renaming a .txt with jpg (in case it was some type of filter blocking). the renamed jpg still did not pass and the renamed txt file still passed. So, my guess was that it is the actual content of the file that does not pass. Txt and doc do not have the same tructure as binaries like zip, exe, pdf, jpg.

Green1 -> thanks for the tips and the test. I see it is not that common factor, I have received your mail attachment so obviously it is not gmail blocking it.


On the same line as above, since the files that are causing trouble are binaries (txt and doc pass without trouble)someone from the office actually suggested that it might be related to MIME settings but I am not sure where I can find those in Linux... Maybe one of you would know...

Thanks again for all your help :-)

Quote:

---

Originally Posted by francisgirard

Hi All,

CrashedAgain -> yeah I tried that one both ways - renaming a jpg with .txt and renaming a .txt with jpg (in case it was some type of filter blocking). the renamed jpg still did not pass and the renamed txt file still passed. So, my guess was that it is the actual content of the file that does not pass. Txt and doc do not have the same tructure as binaries like zip, exe, pdf, jpg.

---

I'm surprised at that result; I always thought mail programs just sent attached files 'blind' without trying to read or identify them (else how would spies be able to send encrypted secret messages?). Maybe that's a thought...have you made any changes to encryption or mime policies? Mine are all just default.

Aha ! Someone else with exactly the same problem I am having with SMTP !

Running Knoppix 3.6, installed on my hard disk, with the 2.4.27 kernel.
KPPP for dial-up.
The PC doesn't have much memory - only 96 Mb RAM, with a 500 Mb swap partition.
I have tried the following e-mail programs, with exactly the same symptoms: Thunderbird, Netscape mail, Sylpheed, Mutt, Mozilla Mail. What's the common thread for all of these ?
I have tried both my local ISP SMTP server (which requires no authentication), and gmail's SMTP server (which requires authentication).

txt files go thru. most jpg files get stuck. most pdf files also get stuck. There seems to be a size dependency - very small jpg and pdf files go thru, but somewhere around 30 kb, they get stuck.

I did a snoop with Ethereal - it gives the impression that the ISP SMTP server suddenly stops acking the message body packets. Not sure I believe that - Seems more likely that the packets stop going out the ppp interface.

None of these problems occur running Win 98SE with Outllook Express on the same PC (it's dual boot).

What other experiments or diagnostics can I try ?

Here's a fix, but it's not pretty....

There are a few things going on here:

1) The SMTP servers seem to be losing a large percentage of packets, causing the Linux TCP to retransmit. The servers are also slow to ACK packets. I have no idea why this occurs - but it is common to both the gmail SMTP server and my local ISP SMTP server with my 19.2 kb/s dial-up connection. I also have no idea why this problem is so much worse with binary attachments than text attachments.

2) The Linux TCP algorithm is adapting to the SMTP server packet-drop and slow ACK problems by increasing the amount of time between retransmissions, up to a maximum of 120 seconds. The TCP throughput drops to virtually zero and the e-mail gets "stuck".

The fix to the problem is to force the Linux maximum TCP retransmission timer to a much smaller value - like a few seconds. This probably violates some RFC, but it gets the job done !

I ported the patch at http://www.jankratochvil.net/project/tcp_rto to the 2.4.27 kernel source, and rebuilt and installed this kernel. Once that is done, you can tweak the maximum TCP retransmission timer to something like 3 seconds:

echo 300 > /proc/sys/net/ipv4/tcp_rto_max

Put this in a rc*.d script so it will get set with each reboot.