This still doesn't work in most cases. See example message. 
Attachments are encoded at base64 however $this->_transferEncoding 
always returns 8bit for every part of that message for some reason.

Changes have been made in Git for this ticket:

Request #9783: Use approximate size when displaying message part information

  1 files changed, 1 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/cecd44a6b1945f9408709de55c90ae13360c2a3c

Changes have been made in Git for this ticket:

Request #9783: Provide method to return approximate size of parts if 
it contains base64 encoded data

  2 files changed, 39 insertions(+), 10 deletions(-)
http://git.horde.org/horde-git/-/commit/5713e39fcb45460df9de4f094384443b1d44e9d7

How about adding another method for returning the estimated size, and 
check for the existence of that method before calling it?

No.  getSize() and getBytes() (or whatever they are called) in 
Horde_Mime_Part returns the size of the current state of the contents 
- regardless of whether it is base64 encoded or quoted-printable or 
binary or 7 bit or whatever.  We can't start returning approximate 
sizes from that function because that is simply broken behavior.

And the only place we know the current encoded state of the contents 
is internally inside Horde_Mime_Part.  So nothing can be worked around 
externally.  And can't extend Horde_Mime_Part in IMP to add this 
feature either.

Can you say why? Doesn't this just change the results of method calls, 
not signature, etc.?

This can't be done without breaking BC with the Mime package.

I think that example is a bit extreme, and that user could have caused 
confusion regardless, but I'm in favor of using the 2/3 approximation 
for base64 parts.

Why I think this need to be corrected is that I had real world 
example, where user sent PowerPoint presentation from Gmail to Horde 
account. Another user tried to open presentation from IMP but could 
not (because he did not had PowerPoint installed :)). Users started to 
"debug" situation on their own. They called each other and one said 
something like "I have sent you this PowerPoint presentation which is 
2 megabytes in size" and another said "Own I think it's our company 
antispam features because I see 3 megabytes". The same Horde user then 
called our IT deparment to compain that our mail service doesn't work 
and damages attachments. It was a long time, while we figured out that 
user just didn't had powerpoint installed.

I agree with you that from MIME perspective this is not really a bug. 
But all major mail clients show actual file size, so it is a little 
bit confusing for users. Maybe it can be guessed? Actuall size is ~2/3 
of base64 MIME size.

I'm not sure if one could call this a bug. It's the size of the MIME 
part, so it's correct. And we could only guess the real size anyway, 
because we don't want to decode the complete mime part only to figure 
out the correct size.

Sizes for attachments in message view are shown for base64/uuencoded 
size, not the real size of the file.