Issue Type: Bug Created: 2006-11-22T16:26:43.000+0000 Last Updated: 2007-07-05T14:43:30.000+0000 Status: Resolved Fix version(s): - 0.8.0 (21/Feb/07)
Reporter: Franco A. (strfrank) Assignee: Matthew Weier O'Phinney (matthew) Tags: - Zend_Mail
Related issues: Attachments: - mail_after.txt
I tried to send an attachment with a simple text mail using Zend_Mail::addAttachment() method, using default options. The mail is generated correctly but there's some problem with the attachment, as it is malformed when received.
Using standard base64 encoding it looks that there's a problem with line breaks in the attachment bytes. After some trial and error I had success in sending the attachment by setting Zend_Mime::LINELENGTH to 72 (instead of 74), but I didn't investigate why. Please let me know if something is needed to better understand the problem
Posted by Bill Karwin (bkarwin) on 2006-11-28T17:50:43.000+0000
Assigning to Matthew, scheduling for 0.7.0 release.
Posted by Simon Mundy (peptolab) on 2006-11-28T19:54:03.000+0000
Hi Franco - what transport were you using? Can you snip a portion of the encoded message to show a before / after of the lines that were affected? It may also help to know a little more about the environment you're sending the mail from (Platform, Mail software, etc)
Posted by Franco A. (strfrank) on 2006-11-29T16:59:40.000+0000
Hi, Transport is default mail(), here's a test script I used:setBodyText("Test body"); $mail->setSubject("Test subject"); $mail->setFrom("email@example.com"); $mail->addTo("removed@aaa"); $att = file\_get\_contents("test.pdf"); $at = $mail->addAttachment($att); $at->filename = "test.pdf"; $mail->send(); ?> I'll attach two mail messages, one with no changes to Zend framework 0.2.0, the other with Zend\_Mime::LINELENGTH = 72. I'll also attach the original test.pdf file. Platform is ubuntu linux 6, postfix, php 5.1.6, apache 2.0
Posted by Simon Mundy (peptolab) on 2006-11-29T18:51:45.000+0000
Thanks for the info. I've tried a number of scenarios and can't reproduce the problem you're seeing.
There's a couple of things that may help identify the problem as well - could you try sending the message with different line endings? You can use the code below to change the line ending to either "\r\n" or "\n" to see if that changes anything.
<pre class="highlight"> $transport = new Zend_Mail_Transport_Sendmail(); $transport->EOL = "\n"; $mail = new Zend_Mail(); $mail->setBodyText("Test body"); $mail->setSubject("Test subject"); $mail->setFrom("firstname.lastname@example.org"); $mail->addTo("email@example.com"); $att = file_get_contents("test.pdf"); $at = $mail->addAttachment($att); $at->filename = "test.pdf"; $mail->send($transport);
Secondly, I'm scratching my head wondering why 74 chars has been used when 76 chars is the RFC2045 recommendation. Can you revert back to 74 chars for the above test, then perform another round of tests with 76 chars and see if that changes anything? I'm interested to see if your local mail (Postfix) is being difficult. You may also wish to try the SMTP transport to see if the problem persists.
Posted by Franco A. (strfrank) on 2006-11-30T17:02:59.000+0000
Hi, I had no luck with "\n" but it works if I comment the second line ($transport->EOL = "\n";) and set LINELENGTH to 76. Looking at the mail files I attached I noticed that, for each line, the sequence \r\n is repeated twice (there's a blank line between one encoded line and the other). MAybe this could be of some help.
Posted by Franco A. (strfrank) on 2006-12-19T08:32:31.000+0000
I experimented a bit with this issue, here's what I discovered:
I couldn't make Zend_Mail_Transport_Smtp work, even with a small email:
//I tried this server, maybe another one will work $tr = new Zend_Mail_Transport_Smtp("smtp.tiscali.it"); Zend_Mail::setDefaultTransport($tr); $m = new Zend_Mail(); $m->setFrom("firstname.lastname@example.org"); $m->addTo("email@example.com"); $m->setSubject("Blah blah blah"); $m->setBodyText("AAAAA"); $m->send();
With this code I get an error 554 Message refused
Posted by Simon Mundy (peptolab) on 2007-02-03T10:06:12.000+0000
Closed for now - but If this resurfaces and we can get some more tangible tests then it will be given some further consideration.
Have you found an issue?
See the Overview section for more details.