> Thank you for your large effort in investigating my problem.
>
> I have no idea about your low level tcp-ip-solution.
> I access the mail directly on the computer where mercury sits (XP Home SP2)!
> I use Imap just to access the mail sometimes on a laptop, normally I work directly on the mail server.
>
> The next thing what I do not understand: If I move the mail to another
> Imap-Folder, I can watch the jpg with no problem!

This is what I find strange.  I can view these message attachments you forwarded to me without problems with WinPMail, OE, Outlook and Eudora via IMAP4 but I cannot do this with Thunderbird.  WinPMail in direct access can view the attachments also without problems.  Apparently there is something about this message that is causing a problem with Thunderbird.

All the clients, even Thunderbird, can view the attachments in the message you sent me via the ZIP file.

>
> Maybe I will compare the Imap-Log-files for this behaviour and tell you some results.

Not sure this will help at all since all of the other clients do not have a problem viewing this message via IMAP4.

>
> Best regards again, Walter

Several, but not all of my users are plagued with broken attachments. These can be .doc, .pdf, or .jpg attachments.I have experienced this issue before, and replacing the NIC card on the user's computer solved the problem. But now the problem shows up on many computers, I have changed the NIC card on one machine, and then also on the server. It is probably only one bit or two that is causing the problem. If I forward (from the SMTP server) the message to another server such as gmail, the attachment can be then downloaded from them, using the same e-mail client, without error.

 I have set up an account for a certain user on my own workstation, and messages from his account on the POP server are broken, but CC copies to my own account are received intact. Thus it seems clear to me that the client workstation is not at issue this time around. Frequently, if two attachments are sent, one will be broken and the other is not.

I have been using Mercury for many years and with many upgrades. The problem came on sort of all of a sudden two days ago. An upgrade to 4.51 did not change the issue.
Perhaps somebody has some suggestions as to why some of the attachments are breaking.

 
Thanks, Elias
 

You need to pinpoint if the attachments are getting broken on the way into Mercury/32 or on their way out to the client. The only way to start looking for broken messages on the server side is to turn on session logging on the SMTP-server MercuryS. Therein you should look for the completion of all inbound traffic.

Peter,

Attachments appear to be received by the server intact, I can set the account to copy them to a outside server (Gmail) and the attachment remains intact. It appears to break when requested from the POP server from an e-mail client.

 
Elias
 

Do any of these attachments contain very long lines? If so, what sort of line lengths are we talking about?

Cheers!

-- David --

David

I do not suspect a "long line" This occurs in many e-mails to several users: .doc; .jpg; and .pdf files among others. 

Yesterday I ran some logs from the POP server, and compared them against the source code in the received message at the mail client. They appeared to be identical. Indeed, the source code in the received message and the sent message appear to be identical, yet the received attachment is broken and will not open.

 I have been running Mercury far too long with out a problem to suspect that the problem is actually in Mercury. Recently my #2 server went down (backup domain server). Server #1 (the primary domain server) and #3 server (Mail Server) were not affected, but there seems to be some dns issues. I corrected them (or so I thought) or at least they can connect to the internet again.

I fail to see why email can go through but attachments cannot, but suspect a residual network issue. But I should be able to repair the issue and perhaps you have some suggestions that may help, or at least others here may have had a similar problem and could share a solution.
 

Thanks, Elias 

[quote user="Broadway Lion"]

David

I do not suspect a "long line" This occurs in many e-mails to several users: .doc; .jpg; and .pdf files among others. 

Yesterday I ran some logs from the POP server, and compared them against the source code in the received message at the mail client. They appeared to be identical. Indeed, the source code in the received message and the sent message appear to be identical, yet the received attachment is broken and will not open.

 I have been running Mercury far too long with out a problem to suspect that the problem is actually in Mercury. Recently my #2 server went down (backup domain server). Server #1 (the primary domain server) and #3 server (Mail Server) were not affected, but there seems to be some dns issues. I corrected them (or so I thought) or at least they can connect to the internet again.

I fail to see why email can go through but attachments cannot, but suspect a residual network issue. But I should be able to repair the issue and perhaps you have some suggestions that may help, or at least others here may have had a similar problem and could share a solution.
 

Thanks, Elias 

[/quote]

The first thing that comes to my mind when  this happens is packet fragmentation when downloading from the POP3 host.   POP3/SMTP transmissions may fail if the MTU packet size is so large that a packet is fragmented.  In many cases the receiving system router blocks the receiving servers "packets fragmented" response to the sending system using "MTU Discovery".  These oversize packets are not accepted and so are resent.  This results in a timeout, generally at the end of the message transmission but it can be anywhere in the process.  You need to reduce the MTU size. Windows defaults to a 1500 MTU and many routers and DSL connections need 1492.  You might simply want to turn off the MTU Discovery operation.

You might want to get a copy of SG TCP Optimizer that I find quite handy.  http://www.speedguide.net/downloads.php  This little utility will allow you to test your MTU for maximum size without fragmentation against specific servers.  If will also make it easy to adjust the MTU.  

And finally, does these problem computers, by chance, happen to have an NVidia NForce 4 chipset on the motherboard?  If so, many other have had this exact problem, and it turned out to be an optimization setting for the built in NIC which caused the problems with packet fragmentation. Disabling the advanced optimization capability called "checksum offload" made all the problems of sending SMTP mail via WinPMail disappear.

Whether this will fix your problem I do not know but the mail is being received properly by Mercury/32 and appears to be being corrupted when the client downloads.

We have the same old problem, that if we receive larger attachment, the files are broken, especially images (.jpg).

I have now tried to send the same email containing a jpg-file to our linux-server, the mail is intact, also the attachment.-

Now I did a compare of the mail source code, and I can see following difference in the encoded data:

Correct file:

*****************************************************************************************************************************

CHgyjLJuVUKqD1DMCWAweJBzB8S4DFyUaPMdtRxYPMyywSOpA5lKwdxBhLkNURcMorjiXUwsuCPc
AZaNX7Tx8QXRh0IABE1GLGpM1dx65phXJXYjEII9p5+JuVi8t29W7/3KbHY45mUOw7jUzf4mmfim
xg8ERT4P+JqbAyv+6UcXkGxJi6w0VhA/M0lB5EW2K+uJAFywYBtTRhC/mAdyCBzLuoB+ZL5g9iSQ
F5hhosHiWIU0GS4APEl8yIImXBuXcArkEG6lgyi+zJUl8ygYF9SMOJV8yEyiWRLHcG5YkVcglSXx
AuSpUuQWJPMgliBByYRMpe5WQ7UY/UlVzdQ1sT8xKDmFkO5jKHExHcSdmETzKQcQWPMiCHJJgMeT
LBgEywRf3Q1FkwE5MNGqzJVjNmPvImr8Ul53b4Wpjf3OZ1fxqBUcjomVnpslSz1KEMLI9sg6k7Es
9SgYDQoDdyUCeopuDDPJPxAaSKRkPEXDyQJUXKlyoEMGW0kCSVJITKgfMkkkCjJIZIVJJJIRRlGX
KMCjBaWYJlVUksyoRJckoQJBhHqUZRUqXK7gSXLAlQKMqXKlEkkEkIqVcsyoHvnFg0JkyYzOq+D+
mHHUzZEuYlxrHMKEdmCyXNuTDEMm2bnRjKoZGu5blsvDDiNI+pKl1MAqVDAlyVGriSiZclRpirJ7
l3KJqUI1Mgvn5kAoQb+ZZZRVmVnYIdSWT4kJ2i1izluU+mMa7MEsAeOYvdIDcmrgy5MgMAyA1JrW
DuS5R6u5VyaYuVckkauLPUvjb3z8QZK5jTEuS5PMncaKMksqRyeP5ktR9mEVC2M0gf4AElnyY1UC
Kv7jCDD+1b/mARLAqTyMF7m+pRQnsy1NSEmXTA7alVCkk0VUlQpKgDJCqVUCvMuSQ9QJ1JKk5PiB
Uomoew+eJPYOO5rxrN6hdk9CT03P1DL/APFYW12E14s+YFxL5Nywqr0BGDTHd7jRjUxIO/8AuVnb
SOW6EJcDtdCv5mpVA6hXQ77lRnx6faAXomO+NoFSKfftJ5qwZArhm3UV+u5FWGFn3SWQTzwZftUG
ot8l2T7aHnzAIPsPyYTHgFj3MWTV46pC4cc8jgyLhzahSz5GHPQPEI2Fhssgy8Z2gkEKYra4xqoP
IH7jCIYgHd1yfuFUSaJAO4dfczuuVyvu/kAzUbZSBQ+JYNjgAAcWYCC2XE+y1zNXJHBAjKDsrEkl
eLhsED8e4HixL9qYyehCFEttOzg9xK43enQ9HyZpD7lBAtW+pQDIQuMqF+CIVefGQNyiZGAblB3N
9Aj3NABxlvbRodQMq4HYiuP5jxpq7McaNQwfdUBfohRGooXqKLe7uCpbK4Q5Karr6lRpcgD3GLyu
qpakEiZM+Zn/AKSjIG/tJ6MdSbAWWngEmUst1UFzvFuTxzxJu9u1RxfJjFQkXXcAA6DGGHX0JmQm
yXBUXx9zcyqva8zPkxBgdrbTJmLuqoOp3Di+JMVI7BhYlOmRz7coVfsQlxlUomz8x7BnCrCxxM+X
TBgQRYmjIAFG1muUrFWIYhgebjFlc1sLYza9Q0yblp14mzPjBUlOT8TPscIW2cgdCC0llxmtjD+I

***************************************************************************************************************************** 

Incorrect (Mercury received file):

*****************************************************************************************************************************

CHgyjLJuVUKqD1DMCWAweJBzB8S4DFyUaPMdtRxYPMyywSOpA5lKwdxBhLkNURcMorjiXUwsuCPc
AZaNX7Tx8QXRh0IABE1GLGpM1dx65phXJXYjEII9p5+JuVi8t29W7/3KbHY45mUOw7jUzf4mmfim
xg8ERT4P+JqbAyv+6UcXkGxJi6w0VhA/M0lB5EW2K+uJAFywYBtTRhC/mAdyCBzLuoB+ZL5g9iSQ
F5hhosHiWIU0GS4APEl8yIImXBuXcArkEG6lgyi+zJUl8ygYF9SMOJV8yEyiWRLHcG5YkVcglSXx
AuSpUuQWJPMgliBByYRMpe5WQ7UY/UlVzdQ1sT8xKDmFkO5jKHExHcSdmETzKQcQWPMiCHJJgMeT
LBgEywRf3Q1FkwE5MNGqzJVjNmPvImr8Ul53b4Wpjf3OZ1fxqBUcjomVnpslSz1KEMLI9sg6k7Es
9SgYDQoDdyUCeopuDDPJPxAaSKRkPEXDyQJUXKlyoEMGW0kCSVJITKgfMkkkCjJIZIVJJJIRRlGX
KMCjBaWYJlVUksyoRJckoQJBhHqUZRUqXK7gSXLAlQKMqXKlEkkEkIqVcsyoHvnFg0JkyYzOq+D+
mHHUzZEuYlkkEkIqVcsyoHvnFg0JkyYzOq+D+
mHHUzZEuYlxrHMKEdmCyXNuTDEMm2bnRjKoZGu5blsvDDiNI+pKl1MAqVDAlyVGriSiZclRpirJ7
l3KJqUI1Mgvn5kAoQb+ZZZRVmVnYIdSWT4kJ2i1izluU+mMa7MEsAeOYvdIDcmrgy5MgMAyA1JrW
DuS5R6u5VyaYuVckkauLPUvjb3z8QZK5jTEuS5PMncaKMksqRyeP5ktR9mEVC2M0gf4AElnyY1UC
Kv7jCDD+1b/mARLAqTyMF7m+pRQnsy1NSEmXTA7alVCkk0VUlQpKgDJCqVUCvMuSQ9QJ1JKk5PiB
Uomoew+eJPYOO5rxrN6hdk9CT03P1DL/APFYW12E14s+YFxL5Nywqr0BGDTHd7jRjUxIO/8AuVnb
SOW6EJcDtdCv5mpVA6hXQ77lRnx6faAXomO+NoFSKfftJ5qwZArhm3UV+u5FWGFn3SWQTzwZftUG
ot8l2T7aHnzAIPsPyYTHgFj3MWTV46pC4cc8jgyLhzahSz5GHPQPEI2Fhssgy8Z2gkEKYra4xqoP
IH7jCIYgHd1yfuFUSaJAO4dfczuuVyvu/kAzUbZSBQ+JYNjgAAcWYCC2XE+y1zNXJHBAjKDsrEkl
eLhsED8e4HixL9qYyehCFEttOzg9xK43enQ9HyZpD7lBAtW+pQDIQuMqF+CIVefGQNyiZGAblB3N
9Aj3NABxlvbRodQMq4HYiuP5jxpq7McaNQwfdUBfohRGooXqKLe7uCpbK4Q5Karr6lRpcgD3GLyu
qpakEiZM+Zn/AKSjIG/tJ6MdSbAWWngEmUst1UFzvFuTxzxJu9u1RxfJjFQkXXcAA6DGGHX0JmQm
yXBUXx9zcyqva8zPkxBgdrbTJmLuqoOp3Di+JMVI7BhYlOmRz7coVfsQlxlUomz8x7BnCrCxxM+X
TBgQRYmjIAFG1muUrFWIYhgebjFlc1sLYza9Q0yblp14mzPjBUlOT8TPscIW2cgdCC0llxmtjD+I

 *****************************************************************************************************************************

You can see, that a small part of the code is duplicated.

Another mail example, where you can also see the duplication of  the code:

yJJ6W+1X9S4N8whMquTzKvmXAh5lVJcsSCpchg+YFyESSdSiuoJlkwSYRDKPEEv8cyqY98TU5qXq
LLAdyqZ+uBDXEKvuVbEGhtAm8kY21GxNYdGAYf8AcdjcOwDCjXPxEdeeZNxBsHmXyTwVtD2jC6Jq
Bn0e1AyG7mlMqt+eeZNxBsHmXyTwVtD2jC6Jq
Bn0e1AyG7mlMqt+5ArfPzNABrqrmmfjiAFTzLPgzo5dGuQ2p2t8TBkxticqR1IquDAIqMWipvuVV
2fEATVcSKaIkZfiDRBgG1V/MXUK7HMg7gCRUJQCJZFjiCRUCm7kUfMg5MsC4EHcsA9+JREsEdQqN

If someone can do more investigation, I can send you a test email with this data.

A very seldom thing happens, if I delete the mail (I work woth Seamonkey and tried this also with Thunderbird).

If I delete the mail and go to WasteBasket, the mail is correctly displayed. Maybe the email clients  purge this (nearly duplicate) line???

Regards

Walter

Munich, Germany 

 P.S. Edit: If I receive the file only with Mercury and look the Y..CNM File in the Mail-Folder, the line is not duplicated!!!!

So it seems to be a problem of the imap-Server-part??? 

 P.P.S: I have updated to 4.51, but the problem was already there with 4.01

[quote user="wwillm"]

 P.S. Edit: If I receive the file only with Mercury and look the Y..CNM File in the Mail-Folder, the line is not duplicated!!!!

So it seems to be a problem of the imap-Server-part??? 

 [/quote]

Turn on session logging for the MercuryI module and compare the transmitted data. This will tell you if it is mercury sending it wrong or if it is your client that is doing strange things to your mail.

Is it mishandling the Content type MIME headers ?

Is the IMAP over SSL? It could be a bad hash [:P]

It seems to be in the imap server.

Here part of the CNM-File: 

LBgEywRf3Q1FkwE5MNGqzJVjNmPvImr8Ul53b4Wpjf3OZ1fxqBUcjomVnpslSz1KEMLI9sg6k7Es
9SgYDQoDdyUCeopuDDPJPxAaSKRkPEXDyQJUXKlyoEMGW0kCSVJITKgfMkkkCjJIZIVJJJIRRlGX
KMCjBaWYJlVUksyoRJckoQJBhHqUZRUqXK7gSXLAlQKMqXKlEkkEkIqVcsyoHvnFg0JkyYzOq+D+
mHHUzZEuYlxrHMKEdmCyXNuTDEMm2bnRjKoZGu5blsvDDiNI+pKl1MAqVDAlyVGriSiZclRpirJ7
l3KJqUI1Mgvn5kAoQb+ZZZRVmVnYIdSWT4kJ2i1izluU+mMa7MEsAeOYvdIDcmrgy5MgMAyA1JrW
DuS5R6u5VyaYuVckkauLPUvjb3z8QZK5jTEuS5PMncaKMksqRyeP5ktR9mEVC2M0gf4AElnyY1UC
Kv7jCDD+1b/mARLAqTyMF7m+pRQnsy1NSEmXTA7alVCkk0VUlQpKgDJCqVUCvMuSQ9QJ1JKk5PiB
Uomoew+eJPYOO5rxrN6hdk9CT03P1DL/APFYW12E14s+YFxL5Nywqr0BGDTHd7jRjUxIO/8AuVnb
 

Here part of the log file (I hope I found the mistake's place):

11:32:07.656: << F5hhosHiWIU0GS4APEl8yIImXBuXcArkEG6lgyi+zJUl8ygYF9SMOJV8yEyiWRLHcG5YkVcglSXx<cr><lf>
11:32:07.656: << AuSpUuQWJPMgliBByYRMpe5WQ7UY/UlVzdQ1sT8xKDmFkO5jKHExHcSdmETzKQcQWPMiCHJJgMeT<cr><lf>
11:32:07.656: << LBgEywRf3Q1FkwE5MNGqzJVjNmPvImr8Ul53b4Wpjf3OZ1fxqBUcjomVnpslSz1KEMLI9sg6k7Es<cr><lf>
11:32:07.656: << 9SgYDQoDdyUCeopuDDPJPxAaSKRkPEXDyQJUXKlyoEMGW0kCSVJITKgfMkkkCjJIZIVJJJIRRlGX<cr><lf>
11:32:07.656: << KMCjBaWYJlVUksyoRJckoQJBhHqUZRUqXK7gSXLAlQKMqXKlEkkEkIqVcsyoHvnFg0JkyYzOq+D+<cr><lf>
11:32:07.656: << mHHUzZEuYlxrHMKEdmCyXNuTDEMm2bnRjKoZGu5blsvDDiNI+pKl1MAqV
11:32:07.656: << )<cr><lf>
11:32:07.656: << * 158 FETCH (UID 24520 FLAGS (\SEEN))<cr><lf>
11:32:07.656: << 26 OK UID FETCH complete.<cr><lf>
11:32:07.656: >> 27 UID fetch 24520 (UID RFC822.SIZE BODY[]<10240.10240>)<cr><lf>
11:32:07.703: << * 158 FETCH (UID 24520 RFC822.SIZE 1030971 BODY[]<10240> {10240}<cr><lf>
11:32:07.703: << CyXNuTDEMm2bnRjKoZGu5blsvDDiNI+pKl1MAqVDAlyVGriSiZclRpirJ7<cr><lf>
11:32:07.703: << l3KJqUI1Mgvn5kAoQb+ZZZRVmVnYIdSWT4kJ2i1izluU+mMa7MEsAeOYvdIDcmrgy5MgMAyA1JrW<cr><lf>
11:32:07.703: << DuS5R6u5VyaYuVckkauLPUvjb3z8QZK5jTEuS5PMncaKMksqRyeP5ktR9mEVC2M0gf4AElnyY1UC<cr><lf>
11:32:07.703: << Kv7jCDD+1b/mARLAqTyMF7m+pRQnsy1NSEmXTA7alVCkk0VUlQpKgDJCqVUCvMuSQ9QJ1JKk5PiB<cr><lf>
11:32:07.703: << Uomoew+eJPYOO5rxrN6hdk9CT03P1DL/APFYW12E14s+YFxL5Nywqr0BGDTHd7jRjUxIO/8AuVnb<cr><lf>
11:32:07.703: << SOW6EJcDtdCv5mpVA6hXQ77lRnx6faAXomO+NoFSKfftJ5qwZArhm3UV+u5FWGFn3SWQTzwZftUG<cr><lf>

and here the result in the mail's source code:

cG9w7lnAxTdjYZF812JUAG45kKBhx3AuQNAEoRKmhSK5owGRT+2QLEksqQeZUNCDV/EKlfrgwJcg
jIV7EtXK/Ylq5HB5HxL2K49po/BjTDMeT3Wh2n4j1zXxkG0/ImFkKmiCIS5SvB5EWSktjo3wOiD5
ENGZf2mx8TFjyULxtR8gx6Zlat3sPz4M53h0ne/WwFcooUGi2QjsQ1GNl59p+YLblN3YnN0lUuQq
KNEfcnpq/wCwgH4lHawscQarmXTPxKK8ESwYYyGqPMm0P+00ZUUGruQwTYNEUZLqBZJEqrMl3JVS
CHgyjLJuVUKqD1DMCWAweJBzB8S4DFyUaPMdtRxYPMyywSOpA5lKwdxBhLkNURcMorjiXUwsuCPc
AZaNX7Tx8QXRh0IABE1GLGpM1dx65phXJXYjEII9p5+JuVi8t29W7/3KbHY45mUOw7jUzf4mmfim
xg8ERT4P+JqbAyv+6UcXkGxJi6w0VhA/M0lB5EW2K+uJAFywYBtTRhC/mAdyCBzLuoB+ZL5g9iSQ
F5hhosHiWIU0GS4APEl8yIImXBuXcArkEG6lgyi+zJUl8ygYF9SMOJV8yEyiWRLHcG5YkVcglSXx
AuSpUuQWJPMgliBByYRMpe5WQ7UY/UlVzdQ1sT8xKDmFkO5jKHExHcSdmETzKQcQWPMiCHJJgMeT
LBgEywRf3Q1FkwE5MNGqzJVjNmPvImr8Ul53b4Wpjf3OZ1fxqBUcjomVnpslSz1KEMLI9sg6k7Es
9SgYDQoDdyUCeopuDDPJPxAaSKRkPEXDyQJUXKlyoEMGW0kCSVJITKgfMkkkCjJIZIVJJJIRRlGX
KMCjBaWYJlVUksyoRJckoQJBhHqUZRUqXK7gSXLAlQKMqXKlEkkEkIqVcsyoHvnFg0JkyYzOq+D+
mHHUzZEuYlxrHMKEdmCyXNuTDEMm2bnRjKoZGu5blsvDDiNI+pKl1MAqVCyXNuTDEMm2bnRjKoZGu5blsvDDiNI+pKl1MAqVDAlyVGriSiZclRpirJ7
l3KJqUI1Mgvn5kAoQb+ZZZRVmVnYIdSWT4kJ2i1izluU+mMa7MEsAeOYvdIDcmrgy5MgMAyA1JrW
DuS5R6u5VyaYuVckkauLPUvjb3z8QZK5jTEuS5PMncaKMksqRyeP5ktR9mEVC2M0gf4AElnyY1UC
Kv7jCDD+1b/mARLAqTyMF7m+pRQnsy1NSEmXTA7alVCkk0VUlQpKgDJCqVUCvMuSQ9QJ1JKk5PiB
Uomoew+eJPYOO5rxrN6hdk9CT03P1DL/APFYW12E14s+YFxL5Nywqr0BGDTHd7jRjUxIO/8AuVnb
SOW6EJcDtdCv5mpVA6hXQ77lRnx6faAXomO+NoFSKfftJ5qwZArhm3UV+u5FWGFn3SWQTzwZftUG
ot8l2T7aHnzAIPsPyYTHgFj3MWTV46pC4cc8jgyLhzahSz5GHPQPEI2Fhssgy8Z2gkEKYra4xqoP
IH7jCIYgHd1yfuFUSaJAO4dfczuuVyvu/kAzUbZSBQ+JYNjgAAcWYCC2XE+y1zNXJHBAjKDsrEkl
eLhsED8e4HixL9qYyehCFEttOzg9xK43enQ9HyZpD7lBAtW+pQDIQuMqF+CIVefGQNyiZGAblB3N
9Aj3NABxlvbRodQMq4HYiuP5jxpq7McaNQwfdUBfohRGooXqKLe7uCpbK4Q5Karr6lRpcgD3GLyu
qpakEiZM+Zn/AKSjIG/tJ6MdSbAWWngEmUst1UFzvFuTxzxJu9u1RxfJjFQkXXcAA6DGGHX0JmQm

Very  seldom,

I have no SSL for Imap!

I tried seamonkey, and I tried firefox! 

Regards

Walter

> We have the same old problem, that if we receive larger attachment, the
> files are broken, especially images (.jpg). I have now tried to send the
> same email containing a jpg-file to our linux-server, the mail is
> intact, also the attachment.- Now I did a compare of the mail source
> code, and I can see following difference in the encoded data:

Could you forward one of these messages to me at techsupp@tstephenson.com for analysis.  I need the *.CNM file as received by Mercury/32 and it's best sent as a zip file to ensure it's not changed at all.  If nothing else I can test the IMAP4 download with a lot of IMAP4 mail clients.

@Thomas:

I sent you the regarding mail with the jpg-attachment and the cnm-file as zip

Regards from Germany, Munich

Walter 

[quote user="wwillm"]

@Thomas:

I sent you the regarding mail with the jpg-attachment and the cnm-file as zip

Regards from Germany, Munich

Walter 

[/quote]

 Not sure what to tell you.  I dumped this message into a Mercury/32 users mail directory and then viewed it directly with Pegasus Mail.  No problem, both graphics looked good.  I then accessed this message via IMAP4 with Outlook 2002, OE, Thunderbird, Eudora and WinPMail and in all cases I saw exactly what I saw when viewing this file directly.  I cannot duplicate this problem.  I can only suspect that there is some sort of low level TCP/IP problem on your LAN/WAN/System that is somehow breaking the download.  I even came in via wireless and from my Linux system and it was the same.

Sorry I could not be more helpful.

Thank you for your large effort in investigating my problem.

I have no idea about your low level tcp-ip-solution.
I access the mail directly on the computer where mercury sits (XP Home SP2)!
I use Imap just to access the mail sometimes on a laptop, normally I work directly on the mail server.

The next thing what I do not understand: If I move the mail to another Imap-Folder, I can watch the jpg with no problem!

Maybe I will compare the Imap-Log-files for this behaviour and tell you some results.

Best regards again, Walter