Opened 18 months ago

Last modified 12 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:


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 (add)

Change History (7)

comment:1 Changed 18 months ago by zzz

  • Status changed from new to infoneeded_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 18 months ago by Reportage

  • Status changed from infoneeded_new to new

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 18 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 18 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 18 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 12 months ago by zzz

  • Resolution set to wontfix
  • Status changed from new to closed

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 12 months ago by Reportage

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.