I agree 100%

The way geary works now (from my understanding) is that it downloads all messages and attachments locally from whatever timeframe the user sets (2 weeks, month, etc).

I tend to have mine load everything, irregardless of time, so I can search through past emails. However, this leads to geary taking up many gigabytes of storage space, most of which is taken up by old email attachments. For which the grand majority are a waste of space.

I find this a security risk, a waste of space, and a waste of bandwidth. Can we not only store the attachments that a user explicitly says to download (as is how nearly all other email clients work)? Further, I suggest that we only hold onto attachments for a fixed window of time before we automatically clean them out, perhaps 1-2 weeks from the time of download. After which point, the user can just download the attachment from the email of choice again.

This is definitely a security risk. I was shocked to discover that Geary is downloading ALL attachments, including those in the Spam folder. Unfortunately, I will not be able to use Geary with this issue present.

Britt & Bill,

I agree that making lazy downloading of attachments would be highly desirable for some users to conserve storage space and minimise download volume. However I don't see where the security risk is.

My understanding is that since that unless an infected file is executed or interpreted in some way then any malware it contains cannot be executed. Since Geary stores attachments in a hidden, implementation-specific directory, they will not be found by desktop services like Tracker and will not be otherwise triggered without user intervention. Thus the only way that an infected file will be opened and hence the malware triggered is through user explicitly doing so, and then it doesn't make any difference if the attachment is already on the filesystem or has to be downloaded first.

I readily acknowledge there may be specific attacks that I am not aware of that makes Geary's current attachment handling a risk, however since security risks are very important concerns, making vague claims about them isn't very useful.

So, what's the specific details of the attack vector that constitutes a security risk here?

Ok, I may have been in error when I claimed it to be a security risk. The paranoid, tin foil hat wearer in me always feels a bit anxious when things find their way on to my computer without my explicit permission. Notably being spam email attachments, etc.

While it may not pose an immediate risk unless it is executed, it still makes me feel uncomfortable that much of my precious ssd space is taken up by wasted attachements, in the order of tens of gigabytes.

Fair enough, thanks for the information. Hopefully Geary will get the support it needs now that it has found a new maintainer anyway, and I will be able to just use it instead of Pantheon-Mail

Whoops, please ignore my comment #5, I mixed up my responses in my chrome tabs. What I meant to say was:

I did lay out a couple observations and suggestions in general for cleaning up mail (and attachments) over time in bug 766581. Please see that one as it may pertain to how to address some of these issues.

(In reply to Britt Yazel from comment #4)
> Ok, I may have been in error when I claimed it to be a security risk. The
> paranoid, tin foil hat wearer in me always feels a bit anxious when things
> find their way on to my computer without my explicit permission. Notably
> being spam email attachments, etc.

No problem, that's understandable. Apologies if I came off heavy handed before.

> While it may not pose an immediate risk unless it is executed, it still
> makes me feel uncomfortable that much of my precious ssd space is taken up
> by wasted attachements, in the order of tens of gigabytes.

Yep, I totally agree. IMAP supports this, so we would need to see what changes are needed in Geary for support it.

Adding myself to this. We receive a vast load of mails including *large* binary files in our professional environment, and most of them I neither need nor want on my local device because they're just supposed to go into some automated processing pipeline.

As an additional idea here, AquaMail on Android offers the feature to automatically *just* download message headers in order to cut down both storage space and bandwidth and still be able to provide search for recepients, subjects or senders or navigate communication threads. Maybe this would be an interesting idea for geary too.

Closing this in favour of https://gitlab.gnome.org/GNOME/geary/issues/453