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.

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'.

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?

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.

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.

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?

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.

1.5.0 appeared to exhibit this behaviour for us, and 1.5.1 resolved it. WFM.

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).

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

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 http://pear.php.net/bugs/bug.php?id=18262 and http://bugs.php.net/bug.php?id=39598 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.

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

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").

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.

Added patch timeout.patch.

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.

Revision 310236 fixed the problem for me.

@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.

0-byte socket write() results will be considered a failure in the next release.

Bug #18281 now has patches applied against Net_Socket - please review/test.