Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.10.1

Bug #18335 Attachments broken
Submitted: 2011-03-03 23:23 UTC
From: dunix Assigned: jon
Status: Closed Package: Net_SMTP (version 1.5.1)
PHP Version: 5.3.5 OS: Gentoo Linux
Roadmaps: (Not assigned)    

 [2011-03-03 23:23 UTC] dunix (Dunix Dunix)
Description: ------------ After updating from 1.4.1 to 1.5.0, attachments in some mails are broken. I'm using Net_SMTP with Horde and Imp. The attachment mime part is always cut off at the same position. Amavis notices the following: > Mar 3 18:04:33 mail amavis[21946]: (21946-09) WARN: MIME::Parser > error: part did not end with expected boundary After going back to 1.4.1, the problem disappeared.


 [2011-03-11 04:46 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2011-03-11 11:25 UTC] jon (Jon Parise)
-Status: Open +Status: Closed -Assigned To: +Assigned To: jon
I applied a simpler version of the suggested patch. It looks like the problem was just that the default timeout value was spelled 'null' instead of '0'.
 [2011-03-13 16:43 UTC] passembk (Markus Passerschröer)
1.5.1 is still broken for me. Seems like setting a '0' timeout doesn't work. Maybe setting no timeout at all if no timeout is requested is better?
 [2011-03-13 16:45 UTC] dunix (Markus)
-Status: Closed +Status: Open -Package Version: 1.5.0 +Package Version: 1.5.1
 [2011-03-21 08:46 UTC] jon (Jon Parise)
Could someone try one of these suggestions and report back? Or perhaps provide some more details on how to reproduce this problem? I'm afraid I'm not seeing the problem here, so it's difficult for me to determine how to fix it correctly.
 [2011-03-21 13:07 UTC] passembk (Markus Passerschröer)
Not sure if this helps, but e-mails / attachments have to be of a certain size. The e-mails are usually cut off at around 65KB. This is almost always reproductible. Around 5% of these e-mails get through without being cut off.
 [2011-03-22 09:52 UTC] jon (Jon Parise)
Great; it sounds like this is reproducible for many people. Could you trying attempting some of the timeout changes suggested in the comments to see if they make a difference?
 [2011-03-23 03:44 UTC] passembk (Markus Passerschröer)
Sorry for the confusion, dunix and passembk are both my accounts. I could reproduce the problem on two different machines. The patch that I attached fixed it on both of them. Let me know if you need more information or if there is anything else that I could test.
 [2011-03-27 17:53 UTC] doconnor (Daniel O'Connor)
1.5.0 appeared to exhibit this behaviour for us, and 1.5.1 resolved it. WFM.
 [2011-03-28 20:55 UTC] jon (Jon Parise)
-Status: Assigned +Status: Feedback
The attached patch changed the behavior to only set the socket timeout if a connection timeout was specified. That effectively removes all non-default timeout behavior, which is not the goal of the feature. In its default mode, the current 1.5.1 code should default to an infinite socket timeout (timeout = 0). So I'm a little confused what's causing the problematic behavior (an overly-short timeout that's tearing down the connection for large transfers).
 [2011-03-30 16:06 UTC] passembk (Markus Passerschröer)
I don't know if this is helpful, but I installed xdebug to trace the problem. Here is the relevant output: The first trace shows what happened when the e-mail got through without being cut off: 0,6897 18185088 -> Net_SMTP->_send($data = '...') /usr/share/php/Net/SMTP.php:1036 0,6897 18310152 -> Net_SMTP->_debug($message = '...') /usr/share/php/Net/SMTP.php:250 0,6897 18185088 -> Net_Socket->write($data = '...', $blocksize = ???) /usr/share/php/Net/SMTP.php:252 0,6897 18185184 -> is_resource(resource(108) of type (stream)) /usr/share/php/Net/Socket.php:379 >=> TRUE 0,6897 18185184 -> is_null(NULL) /usr/share/php/Net/Socket.php:383 >=> TRUE 0,6897 18185184 -> fwrite(resource(108) of type (stream), '...') /usr/share/php/Net/Socket.php:384 >=> 124991 >=> 124991 The second trace shows what happend when the same e-mail was cut off: 0,6897 18109824 -> Net_SMTP->_send($data = '...') /usr/share/php/Net/SMTP.php:1036 0,6897 18234888 -> Net_SMTP->_debug($message = '...') /usr/share/php/Net/SMTP.php:250 0,6897 18109824 -> Net_Socket->write($data = '...', $blocksize = ???) /usr/share/php/Net/SMTP.php:252 0,6897 18109920 -> is_resource(resource(108) of type (stream)) /usr/share/php/Net/Socket.php:379 >=> TRUE 0,6897 18109920 -> is_null(NULL) /usr/share/php/Net/Socket.php:383 >=> TRUE 0,6897 18109920 -> fwrite(resource(108) of type (stream), '...') /usr/share/php/Net/Socket.php:384 >=> 65536 >=> 65536 Additionally, the fwrite function generated the following notice: fwrite(): send of 8192 bytes failed with errno=11 Resource temporarily unavailable in /usr/share/php/Net/Socket.php on line 384
 [2011-04-13 13:54 UTC] alec (Aleksander Machniak)
Because Roundcube webmail users complain about similiar issue I'll try to help. 1.5.1 is still a problem. I feel it can be related to and I don't know how to reproduce this, but can imagine that socket's fwrite() (in socket's write() method) returns 0. In this case _send() doesn't return error and data() will continue the loop over all chunks of data. Final _send("\r\n.\r\n") can also not return an error. It looks that we could detect "0" response from write(), then sleep for some short time and try again. I don't know how it can be related to socket timeout. Maybe fwrite returns 0 after timeout is reached or sth or it's an other issue.
 [2011-04-13 22:10 UTC] grosjo (Joan Moreau)
Hi, I am very interested in fixing this issue , using RoundCube and other softs based on this class. Please let me know if I can help in some way. Thanks Joan
 [2011-04-15 02:21 UTC] blueyed (Daniel Hahler)
The problem here is quite trivial: a timeout of 0 seconds will (set via Net_SMTP::setTimeout => Net_Socket::setTimeout => socket_set_timeout) will make the socket time out after 0 seconds, which means "nearly instantly" and will only happen with a large amount of data. I've attached a patch to change the default timeout to 30 seconds instead. Even when "0" would have meant "never" here, it would not have been a good default. The problem however is two-fold, because Net_Socket does not properly catch the timeout, and no error is returned in that case. I will submit a patch for Net_Socket, too (see bug #18281) Given that patch for Net_Socket and a timeout of 0, you would get an error instead (for a "larger amount of data").
 [2011-04-15 12:18 UTC] alec (Aleksander Machniak)
-Status: Feedback +Status: Critical
 [2011-04-15 13:54 UTC] alec (Aleksander Machniak)
I was digging deeper. It looks that following is true: 1. fsockopen()'s timeout is only for connection (just check php manual) 2. stream_set_timeout(0) doesn't reset nor disable timeout. If so, we need more changes in Socket package and one simple fix for Net_SMTP. See patch timeout.patch. There's still a question about handling zero response from Socket's write() method. See my previous comment.
 [2011-04-15 13:54 UTC] alec (Aleksander Machniak)
 [2011-04-15 18:44 UTC] jon (Jon Parise)
-Status: Critical +Status: Closed
I've patched the Net_SMTP code to avoid setting the timeout value to 0. I mistakenly thought "zero" implied "infinite" there, probably because that's what the current Net_Socket code appears to believe. I'm not going to apply the Net_Socket patch at this time because I'm not the Net_Socket maintainer. I'll wait for someone to verify that the code in just checked in to SVN (revision 310236) fixes the reported problem before I release a new version of the package. Please give it a try if you have the time.
 [2011-04-16 00:17 UTC] passembk (Markus Passerschröer)
Revision 310236 fixed the problem for me.
 [2011-04-17 13:33 UTC] alec (Aleksander Machniak)
@jon: what about my thoughts on handling "0" result from Socket's write()? I think it should be at least considered as a write error.
 [2011-04-26 09:51 UTC] jon (Jon Parise)
0-byte socket write() results will be considered a failure in the next release.
 [2012-01-25 18:26 UTC] doconnor (Daniel O'Connor)
Bug #18281 now has patches applied against Net_Socket - please review/test.