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.

Comments

[2011-03-10 23: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
MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net
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!

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.

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.

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

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.

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.

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.