Preview of attachment filenames and sizes before downloading entire msg

RESOLVED INVALID

Status

--
enhancement
RESOLVED INVALID
11 years ago
8 years ago

People

(Reporter: dosergio, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; pt-BR; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: 2.0b1

It would be nice if when the attachment is heavier than the allowed, instead of the text message "click here do download the entire message" it would be nice if T.B. ALSO showed a mime-type icon with the filename and size to help us deciding if we want or not to download that e-mail.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.


Expected Results:  
Showing the type, filename and size of a heavy attachment before downloading it.
At least the mime-type wouldn't be possible, in most cases - depends on where the limit happens to be drawn of course. (We'd have to download the message to tell you what it is...)
(Reporter)

Comment 2

11 years ago
Thanks anyway I thought it would be possible, I had the impression that in the mail header there was some information about all the attachements in the message ... If there's not, the way the mail headers are today, they are very stupid headers.
Nope, that kind of info is not in the main header...
OS: Windows 2000 → All
Hardware: x86 → All
Sergio, comment 0 is lacking a lot of necessary detail for summary, STR, actual and expected results. Could you add a little?

Magnus, is it possible (before downloading the entire msg), to calculate size
a) of whole msg
b) of individual attachments?
Summary: Preview of attachment filename and size → Preview of attachment filenames and sizes before downloading entire msg
(Reporter)

Comment 5

9 years ago
Ok. 
1- Sumary
When the email attachements are over the configured limit for that account, Thunderbird shows a simple message that the e-mail was not retrieved because it overpasses the limited configured to that account.

2- Actual result
Thunderbird do not detail what is up to be downloaded if you click on the link "Click here do download the entire message".

3- Expected result (if possible)
Thunderbird could show icons with filename and size of each attachment in a way that we could decide on retrieving the full message or not. For instance: if a friend of yours sent to you an electronic comic presentation (ex. power point) or a video with 20MB of size, you could at least see the kind of attachment decide before downloading it. 

My question is about the MAIL headers and the usefullness of its information:
Does the mail header DO NOT have a summary of the attachments file name and their sizes (KB ou MB) ? If they do not have this information, maybe the header should be upgraded to a more useful model, and geta new version of mail header, as the browsers evolutes, some "untouchable" standards could get into a new paradigma.

An ideal mail header (IMHO) should have info about:
* source of the message (server, ip, user, time of creation, etc)
* target of message (server, user, etc)
* program used to send the message
* attachments details (mime, filenames and SIZE)
* message body details (size, charset, encoding, format, etc).

So, with an improved mail header, any client email program would be able to show a preview of all the details of the message before deciding downloading it (when the size of attachments is too big)
Mail headers do not carry such information. There's basically no way to know what's in the message before you have downloaded it. So while your solution sounds attractive, in practice, it's not feasible. Computing attachment sizes requires to go through the whole message anyway, so you would need to download it first.

Concerning your request to change the standard, most headers you mention already exist. However, I don't think adding attachment infos in the headers is a good idea. The sender could lie about it and trick you into downloading a 20MB comic by pretending it's much smaller.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.