[imp] wrong attachment size, again

[Michael M Slusarz]

Quoting Martin Kaehmer <martink-ml at gmx.net>:

| Hallo Michael,
|
| --On Sonntag, 3. August 2003 15:31 -0600 Michael M Slusarz
| <slusarz at bigworm.colorado.edu> wrote:
|
| > Quoting Martin Kaehmer <martink-ml at gmx.net>:
| >
| >| Hi all,
| >|
| >| just found another bug in imp (cvs 29.07.2003). If you add an
| attachment,
| >| its size is calculated before it is mime-encoded. That way only a
| smaller
| >| total size of the mail is checked against attach_size_limit than it
| >| should.
| >| If you finally send that mail, all parts get encoded and the total
| size
| >| may grow over attach_size_limit.
| >
| > No this is not a bug - this is expected behavior.  Telling the user
| they
| > have a 5MB limit, and they then upload a 4.9 MB file and it gets
| rejected,
| > would be completely unexpected.
|
| ack, but the same user will have difficulties to understand why he can
| send
| this 4.9MB mail to himself, but can't forward it afterwards anymore. If
| you
| forward a mail containing attachments, its parts are already
| mime-encoded.
| Therefore the displayed size of the mail will be 33% bigger than before.
| That's a little inconsistency in handling attachments.
|
| What about having both sizes on the compose page (at least for new
| attachments), but using the bigger one for the total size?

I've been thinking for the last few weeks about always displaying the size
as the decoded size because, quite honestly, that makes the most sense. 
The only time you would care about the encoded size of a MIME part is if
you were downloading the raw text of the message part - which never
happens.

I am just trying to figure out a clean way of doing this before I make the
changes.  Most likely, I will just add another method to MIME_Part:: that
will return the "decoded" message size.

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder