Bug 2035 - don't download attachments when opening mail for reading
Summary: don't download attachments when opening mail for reading
Status: NEW
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: UI/Message View (show other bugs)
Version: 3.7.4
Hardware: All All
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2009-11-01 22:12 UTC by huppaker
Modified: 2020-02-12 14:54 UTC (History)
4 users (show)

See Also:


Attachments

Description huppaker 2009-11-01 22:12:09 UTC
well i guess the title says it all. i'm not sure whether this applies to POP3 coz i've never used it, but it applies to IMAP for sure.

when i open a mail (coz i want to read it), claws mail always downloads attachments too. this is really annoying when one tries to quickly read a mail with a big file attached, and makes unneccessary network traffic. attachments should be downloaded only when one explicitly tells claws mail to download it (such as when he/she clicks on one of them on the right sidebar).
Comment 1 J 2009-11-09 19:42:21 UTC
FYI, on POP3, there's a per-account setting in the reception tab that allows one to specify a maximum size of message to retrieve. If a message is larger, it is only partially retrieved, and one can manually retrieve it completely.
Comment 2 huppaker 2009-11-21 14:53:08 UTC
that applies to sync, not to message view, and it's POP3 anyway, so it's really not related to my problem.
Comment 3 J 2009-12-11 17:42:04 UTC
Now that I'm using IMAP, I think this would be a nice feature, if feasible.

But it could be an annoyance as well.

It would be even better if 
- either the attachments were downloaded in background
- or there would be a minimum size for that feature to be activated (under that size, current behaviour is fine)
- or both

(My last comment was addressing "i'm not sure whether this applies to POP3
". Sorry if I'm out.)
Comment 4 Andrey Gursky 2012-09-16 21:23:10 UTC
The absence of such an essential option makes using of claws-mail impossible on low-bandwidth networks.

The claws-mail is a lightweight email client(?), but it does automatically download attachments, regardless, how big they are. It's not lightweight. And this shoots down using the advantages of IMAP for the purpose of quickly browsing emails.
Comment 5 wwp 2012-09-16 21:53:48 UTC
IMO you're wrong, Andrey, but your opinion might be legitimate, "lightweight" doesn't mean made for mobile use. Claws Mail has been designed and created in a time mobile stuff was not existing *at all*. I think it's still not addressing it, but I'm not saying it must ignore it. Also, downloading attachments has nothing to do with being lighweight or not, you're not focusing on the right word and not getting it in the right (historical) context. It's lighweight in term of power used, framework design, code weight, and runtime resources used.
Comment 6 Andrey Gursky 2012-09-18 16:26:32 UTC
>"lightweight" doesn't mean made for mobile use
Have I mentioned "mobile use"? I'm writing this on my desktop PC connected to the internet through ISDN telephone line.

>Claws Mail has been designed and created in a time mobile stuff was not existing *at all*.
What time do you mean, when there were no internet-aware mobile phones *at all*, but all have got broadband internet access? Where is the plain old telephone line gone?

>It's lighweight in term of power used, framework design, code weight, and runtime resources used.
And I'm speaking about runtime resources: network capacity or internet traffic.
Comment 7 wwp 2012-09-18 16:36:53 UTC
You're right Andrey, you didn't mention mobile use at all. I had this in mind, because in terms of UI limitations and network bandwidth limitations, it's the only case where I can see CM as not being mandatorily adapted (I'm not saying that it cannot be used, but it's not really designed for that kind of use, even if improvements have been done, tagetting small-screen devices).

I was running Claws Mail in its former shape 10 years ago, when network was without comparison and in way worse conditions, and IIRC neither me or other people was finding this application *not* lightweight, whatever the meaning of the word. Now that machines have super powers and that network bandwidth has exploded, I hardly see how such critizism can be pertinent.

What I'am saying is that your current and precise argument is (to me), useless.

Now, about the possibility to optionally skip downloading attachements. I have no clue how this can be done but I can admit that it might may sense for some, and I see that as a pertinent request for feature/enhancement.
Comment 8 Michael Heide 2013-06-21 12:39:38 UTC
I'm one of those mobile users. Right now I'm glad to have SquirrelMail as a fallback.

Today I got several big Attachments which I do not need while I'm in the train / not at home. And mobile IP Traffic is quite expensive here / for me.

And the only way to stop claws-mail downloading all that stuff is "xkill" and "by no means start claws-mail before at home".

Yes, claws-mail right now (before I'm at home) is useless for me. While it /could/ be useful if it doesn't automatically downloads the all mails including attachments while syncing the folder.

So... 

...just my 2¢.
Comment 9 Ricardo Mones 2015-08-26 07:45:04 UTC
(In reply to comment #7)
>
> Now, about the possibility to optionally skip downloading attachements. I
> have no clue how this can be done but I can admit that it might may sense
> for some, and I see that as a pertinent request for feature/enhancement.

In theory this is possible and seems to have libetpan support¹, as it has IMAP functions to fetch body structure and fetch separate body parts².

There's some limitations: encrypted mails and have to be downloaded completely.

Just in case somebody is planning to implement this... ;-)

¹ https://github.com/dinhviethoa/libetpan/search?p=3&q=BODYSTRUCTURE&utf8=%E2%9C%93
² https://tools.ietf.org/html/rfc3501#section-6.4.5
Comment 10 Pedro 2016-10-09 19:21:59 UTC
Adding  a bump to this old issue I found after getting stuck trying to follow a large email thread (where none of the participants bothered to strip the first message's 2+ MB attachment) on a slow 3G link.

I guess this feature will only be useful for a small fraction of users, so maybe it could be hidden under a hidden pref. 

I might take a stab at implementing this if there's a developer wiling to help me figure out the proper way to integrate this with the current code.
Comment 11 Andrey Gursky 2016-11-24 03:47:53 UTC
(In reply to comment #10)
Hi Pedro,

> on a slow 3G link.
You're lucky. I have 7-8 KB/s and I couldn't read E-Mails with big attachments at all, thus I had no choice except to fix it by myself (or, well, migrate to Trojita).

Since Claws Mail didn't port back some old very important for me fixes from Sylpheed and its more simple code base with fewer dependencies, I had to stick with Sylpheed and I've implemented a hack (with 2 known issues), which I could share on [1]. A properly solution seems to be not so easy because of complexity of BODYSTRUCTURE. But if there are people who are interested in it, perhaps, I could give it a try, provided Hiroyuki Yamamoto replies, whether he is already working on this or not [1].

Moreover, fetching flags each time I'd like to check for new mails lasts 25+ seconds (180 KB) or even 60+ seconds for larger folders and it keeps growing. This is very frustrating, since these flags don't get changed in between (provided I'm accessing the mail server from the only instance of my mail client). And how often you'd need to break this rule? I'm about to finish this patch [2].

On the other hand, Sylpheed is not actively developed anymore...

Regards,
Andrey

[1] Download attachments on demand
    http://sylpheed.sraoss.jp/redmine/issues/2
[2] Useless flags refetch of all messages in folder
    http://sylpheed.sraoss.jp/redmine/issues/268
Comment 12 Paul 2016-11-24 05:56:54 UTC
(In reply to comment #11)

> Since Claws Mail didn't port back some old very important for me fixes from
> Sylpheed and its more simple code base with fewer dependencies, I had to
> stick with Sylpheed and I've implemented a hack (with 2 known issues), which
> I could share on [1]. A properly solution seems to be not so easy because of
> complexity of BODYSTRUCTURE. But if there are people who are interested in
> it, perhaps, I could give it a try, provided Hiroyuki Yamamoto replies,
> whether he is already working on this or not [1].

Claws Mail has no direct link with sylpheed since we forked about 10 years ago. AFAIK no-one in the Claws team ever follows what sylpheed is doing since then, so of course we didn't port your "old" fixes - we weren't even aware of them.

OTOH, if you attach a patch for claws-mail here, then perhaps it will have some legs.
Comment 13 Andrey Gursky 2016-11-24 07:01:39 UTC
Hi Paul,

(In reply to comment #12)
> (In reply to comment #11)
> 
> Claws Mail has no direct link with sylpheed since we forked about 10 years
> ago. AFAIK no-one in the Claws team ever follows what sylpheed is doing
> since then, so of course we didn't port your "old" fixes - we weren't even
> aware of them.

as long as not the whole Claws Mail code is rewritten and still consists of Sylpheed code, the connection remains in my opinion. These portions of code have been maintained in Sylpheed but remain as-is (sometimes meaning unfixed) in Claws Mail.

I already reported, that one bug in Claws Mail (rendering it unusable for me) doesn't present in Sylpheed: http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2173. Due to missing response, I haven't reported another one (with the same severity for me).

> OTOH, if you attach a patch for claws-mail here, then perhaps it will have
> some legs.

Thanks for suggestion. There are many things to fix, that Claws Mail developers are not interested in, that's why I'm doing it myself (and for now in Sylpheed). But maintaining the Claws Mail code portions shared with Sylpheed, I believe, should be their responsibility, since they decided to fork.

I'd be glad to contribute to Claws Mail too, once/if here would be more maintaining responsibility feeling, responsiveness (and support due to larger code base and libetpan integration).
Comment 14 Paul 2016-11-24 07:18:59 UTC
(In reply to comment #13)
> as long as not the whole Claws Mail code is rewritten and still consists of
> Sylpheed code, the connection remains in my opinion. 

I'm talking about facts, not opinions.

> These portions of code
> have been maintained in Sylpheed but remain as-is (sometimes meaning
> unfixed) in Claws Mail.

What remains 'unfixed', aside from bug #2173, (which is a feature request).
 
> Thanks for suggestion. There are many things to fix, that Claws Mail
> developers are not interested in,

I am one of those developers and I can't think of any things to fix that Claws Mail developers are not interested in. Since you know us better than we know ourselves, perhaps you can provide further information on that.

> I'd be glad to contribute to Claws Mail too, once/if here would be more
> maintaining responsibility feeling, responsiveness (and support due to
> larger code base and libetpan integration).

We can't control how you feel. This project is around 15 years old, so it is hard to imagine where you get these notions. (Which makes me wonder if you're just trolling.)
Comment 15 Andrey Gursky 2016-11-24 08:44:19 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > as long as not the whole Claws Mail code is rewritten and still consists of
> > Sylpheed code, the connection remains in my opinion. 
> 
> I'm talking about facts, not opinions.

The code is a fact. Connection I treat as opinion.

> > These portions of code
> > have been maintained in Sylpheed but remain as-is (sometimes meaning
> > unfixed) in Claws Mail.
> 
> What remains 'unfixed', aside from bug #2173, (which is a feature request).

Unfortunately this is an extremely important feature. Now I recalled the second issue: html entities are shown not decoded, just like here [1] and perhaps related to [2].

> > Thanks for suggestion. There are many things to fix, that Claws Mail
> > developers are not interested in,
> 
> I am one of those developers and I can't think of any things to fix that
> Claws Mail developers are not interested in. Since you know us better than
> we know ourselves, perhaps you can provide further information on that.

By "not interested" I mean "to implement themselves" not "that would be nice to have".

> > I'd be glad to contribute to Claws Mail too, once/if here would be more
> > maintaining responsibility feeling, responsiveness (and support due to
> > larger code base and libetpan integration).
> 
> We can't control how you feel. This project is around 15 years old, so it is
> hard to imagine where you get these notions. (Which makes me wonder if
> you're just trolling.)

15 years could be heavy burden for software.

I've got them from my own experience: no response for both critical issues I encountered with Claws Mail, which forced me to switch to Sylpheed, where I had to fix something also but not so much as I'd had in Claws Mail.

And I'm not alone. Bug opened (maybe patch proposed):
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=1884
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2001
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2149
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2550
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2969
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3192
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3518
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3601
...
but no substantial response, no status change to more-info, milestone or help-needed.

debug log requested
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3278
and no reply after it has been collected, supplied and additional comments were provided.

Such an asynchronous communication, that prevents the bug to be fixed:
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2257
And I suspect, this could be related to the one I've encountered recently: BODY.PEEK[1.HEADER] returns NIL only with MS Exchange IMAP but works perfectly with any other IMAP servers I'm using. Any clue?

And here it is a very nice exception from the above samples:
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=1953
Though, the issue will not be fixed, but at least there is a technical explanation, allowing someone to go on with it (but the status remained NEW).

I agree, it is a general problem not unique to Claws Mail. And hope despite of our different view on the same thing we could continue to communicate polite enough. What do you think about to propose code stubs for this and other bugs, since you're the most familiar with the code and could know the best place something should be implemented in?

[1] https://unix.stackexchange.com/questions/149223/how-to-convert-html-entities-to-readable-text
[2] http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3192
Comment 16 Robert 2020-02-12 14:54:44 UTC
Bump. Issue still remains, 10+ years later, in claws-mail 3.17.4 (Fedora RPM).

Note You need to log in before you can comment on or make changes to this bug.