[imp] Big attachment problem

[Myke Place]

* Michael M Slusarz (slusarz at bigworm.colorado.edu) [030206 10:06] spake thusly:
> Quoting "Kevin M. Myer" <kevin_myer at iu13.org>:
> 
> | See http://bugs.horde.org/show_bug.cgi?id=1162 - lots of finger pointing,
> | IMHO
> | about where the real problem lies, but it should be enough to understand
> | whats
> | going on.  The problem is NOT that the machine isn't powerful enough to
> | handle
> | large attachments - its that as IMP uses PEAR's SMTP routines, the size
> | of the
> | attachment balloons in memory to a huge number (many times more the
> | original
> | attachment size), which quickly hits any sane PHP memory_limit size.
> 
> No, the solution is that you *limit* attachments to a certain size.
> 
> First, this is not the problem that is being asked about in this thread - 
> here, the user is not being able to send any attachments, not that he can't 
> send big attachments.
> 
> Second, as mentioned in the bug report, the above behavior is simply *NOT* 
> a bug.  It may be inefficient, but it is not broken.  This is like saying 
> AutoCAD is buggy since it will not run on a machine with only 64 MB.  
> Simply put, you _do_ have to use a more powerful machine if you want to 
> send large attachments - it's as simple as that.  If you do not want to 
> use/purchase new hardware, then a solution is to simply limit attachment 
> size via php.ini to something smaller (e.g. 5 MB).
> 
> I renew my objection in the bug report that people really, really, really 
> shouldn't be sending 19 MB attachments through the mail system.  This is 
> not what the mail system is designed for - there are other protocols out 
> there that are designed specifically for the purpose of transferring files.
> 
> If someone wants to rewrite the PEAR SMTP module to be more resource 
> friendly, I'm sure the maintainers of the module (which chuck and jon 
> appear to be 2 of them) would be more than happy to commit it.  There is 
> definitely no need to write a Horde specific SMTP module, as was suggested 
> in the report.  This a 'performance' request, not a 'bug' request, so, 
> since I 1) am not getting paid, 2) don't have time, and 3) it works for me, 
> don't look to me to do anything about this (soon).  Therein lies the joy of 
> open source development... :)
> 
> michael


Hi,

I'm not sure if I'm experiencing this effects of this problem, and I do agree with Michael that 
people shouldn't be sending 19MB attachments through e-mail. However, there are users who -- on our 
network at least -- who think that 5MB is a reasonable size, and so I've been instructed by the 
powers that be to 'make it happen.' After rasing 'post_max_size' to 16MB, I get the following error 
when trying to send an attachment of size 5MB:


Fatal error: Allowed memory size of 20971520 bytes exhausted (tried to allocate 7006319 bytes) in 
/var/www/horde/lib/MIME/Part.php on line 195

Fatal error: Allowed memory size of 20971520 bytes exhausted (tried to allocate 140 bytes) in 
Unknown on line 0

To me, 70MB seems like an awful lot to be allocating for a 5MB attachment. I'm totally willing to
believe (and hopeful actually) that this is only a configuration issue on my end, but if so, could 
somebody point me in the right direction? I'm on running Horde/IMP on a machine with 512MB RAM with 
about 4000 regular webmail users. 

Here are what I think are the relevent parts of my php.ini:

max_execution_time = 30
memory_limit = 20M
post_max_size = 16M

and the output of test.php:

Horde Versions

    * Horde: 2.1
    * IMP: 3.1 (run IMP tests)
    * Turba: 1.1
    * Kronolith: 1.0
    * Mnemo: 1.0
    * Forwards: 2.0.1-cvs

PHP Version

    * View phpinfo() screen
    * PHP Version: 4.1.2
    * PHP Major Version: 4.1
    * PHP Minor Version: 2
    * PHP Version Classification: release
    * You are running a supported version of PHP.

PHP Module Capabilities

    * FTP Support: Yes
    * Gettext Support: Yes
    * IMAP Support: Yes
    * LDAP Support: Yes
    * MCAL Support: Yes
    * Mcrypt Support: No
    * MySQL Support: Yes
    * PostgreSQL Support: No
    * XML Support: Yes

Miscellaneous PHP Settings

    * short_open_tag enabled: Yes
    * magic_quotes_runtime set to Off: Yes
    * file_uploads enabled: Yes

PHP Sessions

    * Session counter: 3
    * To unregister the session: click here

PEAR

    * PEAR - Yes
    * Recent PEAR - Yes
    * Mail::RFC822 - Yes
    * Log - Yes
    * DB - Yes


Is it really necessary for PHP to allocate 70MB worth of memory? Can anything be done to prevent 
this? 

-mp