Why attachments are downloaded?

General discussion about PopTray. You love it? You hate it? Talk about it here.

Moderators: KY Dave, jojobear99, Rdsok

Post Reply

Why attachments are downloaded?

Post by choprava » Thu Apr 17, 2003 12:34 pm

On previewing the message, I found that attachments also gets downloaded. Is there any option by which we can select whether to download the attachments or only body of message?

With Warm Regards,

User avatar
PopTray Family
Posts: 773
Joined: Fri Feb 01, 2002 10:30 am
Location: Milan, Italy

Post by ilNebbioso » Thu Apr 17, 2003 1:49 pm

Actually there isn't any option to do what you're requesting. I agree that some time it could be useful (e.g. virus possibility) to preview the message to see the name of the attached file(s) in order to decide to delete it or not.

User avatar
Posts: 83
Joined: Fri Feb 14, 2003 2:45 pm
Location: Western Australia

Post by mpot » Sun Apr 20, 2003 7:56 am

Not only that, but from a performance point of view, it could be very useful.

For example, if a user receives an email with a large attachment, to be able to view any accompanying text in the email, they have to wait for PopTray to download the entire email, including attachments.....


Post by Guest » Sun Apr 20, 2003 1:04 pm

PopTray developers,

Is there any option by which we can prevent the download of attachment in POPTray.

:lol: :arrow:


User avatar
Site Admin
Posts: 1957
Joined: Mon Oct 15, 2001 12:54 pm
Location: Cape Town, South-Africa

Post by Renier » Tue Apr 22, 2003 9:17 am

The POP3 protocol (RFC 1939) doesn't include such advanced features. When POP3 was developed I doubt whether MIME attachements even existed (only specified in RFC 2822 five years later).

The only thing that most POP3 severs support is the optional TOP command which will download the first x number of lines. PopTray 3.0 pre-beta 0.7 and later has support for this command. Since you would then download an incomplete message, no attachment decoding will be done, and you would only be able to see the raw message body.

First Timer
Posts: 4
Joined: Wed Nov 24, 2004 2:50 pm

Option to NOT preview attachments

Post by ddapop2 » Wed Nov 24, 2004 3:01 pm

Attachments are handled via "multi-part" mail, is this not true?

Isn't it therefore just a case of downloading up to the END of the first "part" (ie the body).

That is to say, up to the end of the second "boundary".

First Timer
Posts: 4
Joined: Wed Nov 24, 2004 2:50 pm

Downloading Attachments

Post by ddapop2 » Thu Dec 30, 2004 3:59 pm

Actually, as I think about this, (now using Beta 8), what bothers me is NOT that the attachments are downloaded, but that they are SAVED TO DISK.

This saving to disk causes my virus checker to kick in and will (hopefully) find any viruses, but what if it misses one? And really I didscover that I don't want to keep the email anyway OR its attachments?

Some email programs (eg TheBat) offer an option to "keep attachments in the email". IE they don't save attachments to disk.

Is this much possible?


User avatar
Still here
Posts: 13
Joined: Tue Dec 07, 2004 1:40 am
Location: Montreal, Canada

PopTray limitations

Post by Mindblower » Thu Dec 30, 2004 7:07 pm

Hello. I'm new here, so please bear with me. I use PopTray NOT as a mail reader, but rather as a mail pre-viewer. This fine program allows me to see what mail is there for me (and others), under several accounts. I also find the heading of From, To, Subject, Date, Size, to be more than enough in allowing me to decide if I actually need to read the mail. Yes, at times I have read mail using PopTray, but only to satisfy my cusiosity. The expressed concerns about d/l attachments and saving to disk are indeed justified. Maybe altering the approach one currently uses, till a fix is found, is an ideal option, Mindblower! 8)

User avatar
PopTray Family
Posts: 1422
Joined: Fri Mar 19, 2004 11:36 pm
Location: Norman, Oklahoma USA

Post by Rdsok » Fri Dec 31, 2004 4:51 am

Poptray doesn't save to disk unless you tell it to after you've selected preview. At most it may have a temp file but the attachment isn't able to be accessed there.

Posts: 40
Joined: Tue Oct 21, 2003 10:36 am

Post by Vanguard » Sat Jan 01, 2005 10:14 pm

Attachments aren't something separate from the e-mail body. They are just a piece of text within the body of the e-mail (whose encoding using text represents the binary equivalent of the original file). POP3 hasn't a clue about differentiation between one part of the body and anothe part. The TOP and DATA commands simply retrieve the text of the body - whatever it may contain.

PopTray would need to have parsing code added that would detect which part of the text body message was for UUencoded text that represented a file or use the text representing the MIME delimiter lines and portion of the body. If the point was to only eliminate the text portion of the body representing the attached file then not much code would be required because the code wouldn't have to understand how to handle the decoding of UUencode or deciphering MIME parts. It would only need to note the starting and ending delimiter lines that marked those portions of the text body that represented the attached file.

But how would PopTray know where were the delimited portions within the text body for the UUencoded or MIME parts of the message? Obviously PopTray as with any other e-mail client would have to download the entire message to determine which sections within the body represented special encodings. But then you've already downloaded the entire message in order to do that checking, so eliminating the attachment content at that point would do nothing to speed up the download of the message. You have to get all of the message before you could start figuring out the special portions of it.

A feature of removing attachments from e-mail to speed up downloads would be self-defeating. You want to reduce the size of the download to speed up your mail polling but you are asking that the entire message get downloading to determine what parts to then strip out of it.

Since PopTray should only be issuing a "TOP n 0" command by default (get the first zero lines of the body which results in just returning the headers), the attachments wouldn't be retrieved anyway (since nothing of the body got retrieved). If you enable the "Preview top N lines" option in PopTray then presumably it issues a "TOP n N" command (n = index number of message in mailbox, N = number of *body* lines to retrieve since headers are always included).

Alternatively, you could use PopTray's "Retrieve body while checking" option along with its "Only download if less than N bytes". I forget which POP3 command it is but one of them returns the number of octets for each message in the list of indexes for the messages, so your e-mail client can find out how big are those messages. So you could set it to some low value, like 1KB, but I don't see the value in that. The "TOP n 0" command (by setting "Preview top N lines" to zero) would work better. Presumably disabling the "Preview top N lines" option means PopTray will issue "TOP n 0" instead of something like "TOP n 10" (but 10 lines of text won't much affect your download time, anyway, unless you have hundreds of pending e-mails).

Deciphering which portion of the body of an e-mail constitutents attachments is a funtion performed within whatever e-mail client used to retrieve that e-mail. This is not a function of the transfer protocol (POP3). Even if PopTray were updated to understand UUencode, BinHex, and MIME, that won't do anything to speed up the downloads of e-mail since you would have to get all of an e-mail before you could start deciphering its content.

It's like having a crowd of people outside your door but you want to reduce the size of the crowd that you let in by only letting in everyone that isn't wearing a leather belt (you want to strip out some of the "content"). You can get notified that there is a crowd at your door (the e-mail message) and you can find out how big is the crowd but you can't see through the door to see who is wearing what. You can ask from where they hail and their names (their headers) but that's all. So to find out who is wearing a belt (the portion of text that describes an "attachment"), you have to open the door and move them all inside (POP3 transfer of whole message via RETR command) and start inspecting them (using your coding to decipher the content). Then you find those wearing a leather belt (the specially coded text section representing the attached file) and strip them out of the crowd. But now it's too late. You had to let in the entire crowd before you could start to inspect them, so you never did accomplish your goal of reducing the size of the crowd coming through your door.

I see similar defects in thinking for some folks that define rules that need to inspect the body of an e-mail and then have a later rule to delete it from the server. Well, your first rule forced a download of the e-mail so it could inspect what was in its body so the later rule to delete it from the server won't affect download time because you already downloaded it using the first rule.

You are asking to strip out a portion of the body of an e-mail before you even get it. Won't happen using client-side solutions. The only way to do what you are asking is a server-side solution where you run a filter on the mail server when it sends you an e-mail that strips out the attachments before it sends it to you. But that means you would never get the attachments even when you did want them. The only way to do partially what you want on the client side is to NOT configure PopTray to "Retrieve body while checking" and instead use its "Preview top N lines" option which shows you N lines of the body of every e-mail.

There does seem to be a defect in the "Preview top N lines" option within PopTray but it might good that it works this way. This option does NOT perform the "TOP n N" command when it does a mail poll. It only does that command when you choose to preview a particular message. This means the headers get retrieved twice, once for the "TOP n 0" command sent to get a list of e-mails and for the "TOP n N" command sent later when you choose to preview that e-mail. It is unlikely that you preview every message and there are typically less than 20 lines for headers, so the duplication for header retrieval is no biggie.

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests