Opened 21 months ago

Last modified 15 months ago

#2085 reopened enhancement

Add option to prevent downloading of mail in Susimail

Reported by: Reportage Owned by:
Priority: minor Milestone: undecided
Component: apps/susimail Version: 0.9.32
Keywords: suimail, no-cache, online mode Cc:
Parent Tickets: Sensitive: no

Description

There are situations where downloading mail from postman's server may not
be desirable. It would be useful, therefore, to add an option in Susimail
to prevent downloading of mail, allowing Susimail to function as an online
mail reader only.

Subtickets

Change History (7)

comment:1 Changed 21 months ago by zzz

Status: newinfoneeded_new

Please elaborate on what those situations may be.

Additionally, susimail is a basic mail client, an we don't provide a fancy facility to change options, just a basic view of them in a text box. I doubt anybody changes options, and it's unlikely that your proposal would get much use.

comment:2 Changed 21 months ago by Reportage

Status: infoneeded_newnew

Susimail used to be an online reader without an offline cache, which is in some scenarios a more
secure option. In the event a user is accessing their mail on a machine other than their own e.g.
in a net cafe, downloading mails is not only undesirable but also potentially dangerous.

As regards the options, upgrading the textbox view to a full UI experience (checkboxes etc) wouldn't hurt. Some of the options may be overlooked in the current format, not least the option to leave mail on the server. As a general point, enhancing the UX progressively is never a bad thing, and may prove
helpful in attracting and maintaining users.

comment:3 Changed 21 months ago by zzz

yeah, good points. but…

susimail is only packaged with the router, so it's unlikely anybody is running it standalone at a net cafe. If somebody is running the router at a net cafe, hopefully it's with a "portable" install, where everything is on a USB stick including the user data.

With standard, not-portable install, I don't know if we have any implied obligation to keep email data more secure than all the other keys and data in the data dir. Yes, susimail previously had no cache, and now it does, but neither case was apparent in the UI, and still isn't.

We're in agreement the options UI would need work if we expected people to actually review them and make changes.

Unfortunately, almost any proposal to add a new optional thing to i2p is automatically very low priority, because only a very small portion of the user base would enable it. 99% of optional stuff goes unused.

comment:4 Changed 21 months ago by Reportage

Some general questions to consider:

  • would presenting options in a more accessible format increase their usage? is ease-of use a priority, and conversely, is complexity a barrier to usage?
  • does adding security features to the console and webapps enhance I2P's profile as a security-oriented platform (for example in relation to TAILS)?
  • are there contexts where enhancing the security of the app could help users in hostile environments where I2P usage may be prohibited
  • is it worth considering implementing encryption for the data dir in conjunction with the console password, with the option to unlock the dir at runtime e.g. ~/i2p/i2prouter start -u user -p pass ?

comment:5 Changed 21 months ago by zzz

Yeah. What this, your other susimail tickets #2081 #2087, and some older tickets here on trac highlight, is that susimail has never been great, it's always been a simple client, and it doesn't have what people expect. Over the years it's gotten several major improvements, but it's not Thunderbird and won't ever be. None of this is on our roadmap and we aren't getting to much of what is on our roadmap.

There's no easy answers here. Perhaps we'll discuss it at CCC next month.

comment:6 Changed 15 months ago by zzz

Resolution: wontfix
Status: newclosed

All the recent changes to susimail (folders, etc.) increase the reliance on a local persistent disk cache. The network still isn't fast enough to eliminate caching altogether, and that would be in the opposite direction of recent improvements e.g. #2087.

If real non-caching webmail is a desired feature, it needs to be provided by postman on his servers. That's the only way it would be half-decent. You can contact him to request it if you like.

Closing this wontfix. The other issues listed in comment 4 are mostly covered in #2081 and #2087.

comment:7 Changed 15 months ago by Reportage

Resolution: wontfix
Status: closedreopened

As a compromise/alternative, what about an option that provides session only local storage, and deletes the local cache when the user logs out? This would work in conjunction with the 'retain mail on server' option and provide more or less the same functionality the OP suggested.

Note: See TracTickets for help on using tickets.