|
|||
|
We have recently had a few issues reported of corrupt attachments from emails generated by Zend Mail.
What we know so far The email being sent to our SMTP server from Zend Mail has a valid attachment. I compared it's source immediately before it's sent to that of a working attachment and they are identical. Some people receive the attachment non-corrupt while others receive it corrupt. This behavior is consistent per recipient. All recipients receive a non-corrupt attachment when the email is generated by Thunderbird and sent through our SMTP server. Is there any way to view the source that Thunderbird creates to send to the SMTP server? Knowing the differences of what Thunderbird generates vs. what Zend Mail generates could very well help me solve this. This same behavior occurs with different types of attachments. (Tested pdf and jpeg) Testing I sent a single email generated by Zend Mail through SMTP to a number of recipients as a test. All recipients did not receive identical emails. MIMEs' Content-Transfer-Encoding were different from recipient to recipient. I really don't understand how this works. Not related to the attachment itself, but some recipients received the text/plain and text/html MIMEs as quoteable-printable, some received as base64, and some received as 8bit (it's original encoding). The attachment was sent encoded as base64 and received as base64 by all recipients. However, the user who's attachment was corrupt received the attachment with some slight variations: The characters per line were 76 rather than 74 as Zend Mail generates (not including \r\n). The encoding was very subtly different when compared with a valid attachment. A High percentage of the characters matched up but there were a few on each line that didn't. Needless to say, this makes for a corrupt attachment. But where are these characters being changed and why is this attachment being re-encoded in the first place? Why does this happen when sending through Zend Mail but not through Thunderbird? Other thoughts I had a thought that maybe this was an error specific to exchange servers but I tested with an email I have on an exchange server under the same conditions and the attachment worked fine. Somewhere along the line, I think different character sets are being used. This would explain a few unrecognized characters when decoding/encoding the attachment, resulting in a few characters per line being off after encoding back to base64. The email is being sent as UTF-8. It seems that UTF-8 covers all unicode characters with overhead added only when necessary. Does anyone see anything wrong with using this over something like iso-8859-i? Fyi, the attachment issue occurred when we were using iso-8859-i as it does now that we're using UTF-8. I have only been able to test this with a single user's email and, therefore, haven't had the opportunity to discover commonalities between the users that have reported this. I read somewhere that updating Zend Mail's LINELENGTH var for base64 characters per line to 72 from it's default 74. I attempted this without success. I also tried a few other numbers 60, 70, 76. No different. This is slightly off-topic but here as a side-note in case it makes a difference. - Why are we still using base64 and quotable-printable? It seems that these are fixes to SMTP's 7-bit limitation, but the extended SMTP spec that allows for 8-bit transmission was written in 1995. Have email servers still not caught up? It seems that using 8bit encoding rather than base64 would allow us to avoid the errors incurred when encoding/decoding. I tried this and couldn't get it to work anywhere. Maybe I just don't fully understand how this works. |
|
|||
|
Hi,
I have recieved corrupt pdf attachments, too. And I tried a utility called Advanced PDF Repair to repair my PDF file. It works rather well for my corrupt PDF files. Its web address is Advanced PDF Repair - Powerful PDF recovery tool. Recover PDF files. Repair PDF files. Hope this will help. Alan |
![]() |
| Thread Tools | |
| Display Modes | |
|
|