No feedback.

Now that I've thought about this a little more, I don't see how we can 
really do this. Obviously we have to track *some* state in _POST - we 
could track the previous state in the session, but then the user would 
go to upload a file that's too large and they'd have a weirdly 
reverted message window - and if they hadn't submitted it at all yet, 
it'd just be blank like it is now.



Where would you like us to store state?

We have limited the IMP attachment size with 
$conf['compose']['attach_size_limit'], and we've set a slightly larger 
size limit in php's post_max_size.  When a user attempts to attach a 
file that's between the two sizes, IMP produces the expected message 
saying that it can not attach the file because it's too big.  If the 
user tries to attach a file larger than post_max_size, though, php 
produces an error, but IMP does not detect that the attachment size is 
too large and warn the user.  Instead, the compose screen is wiped and 
returned to its virgin state.



I suspect that this happens because horde is using the superglobal 
arrays $_POST and $_FILES to maintain email state.  See 
http://www.php.net/manual/en/ini.core.php#ini.post-max-size



The only workaround from a configuration perspective is to make 
post_max_size ludicrously large so that a user could never attempt to 
attach a file that big.  Unfortunately, this means that other PHP 
applications can also take advantage of that size limit.



Perferably imp/horde would warn the user and keep state any time the 
attachment size exceeded attach_size_limit, not just when it's between 
attach_size_limit and post_max_size.