View Single Post
Old 21 Dec 2016, 07:16 AM   #18
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696

Representative of:
Fastmail.fm
Quote:
Originally Posted by BritTim View Post
  • Copy (not move) messages to another folder. Support for labels would make this unnecessary, but it really is important (to make messages easy to find later) to be able to see messages from multiple places in the hierarchy. Saved searches can sometimes be a band aid, but are not equivalent.
  • Downloading messages resulting from a search as a zip file..
  • Sending multiple messages as attachments in an email. This feature is incredibly useful when sending a select archive of messages for legal review. Other use cases exist.
Hey, I argued in favour of all those. Copy, I can tell you for sure that it will come back as "add label" as soon as JMAP is ready. We've already added the infrastructure inside Cyrus IMAPd to allow you to map from the GUID (SHA1 of the RFC822 message body at the moment, though it might become BLAKE2 in the future) back to all the messages in all the folders with that exact content. If you access your mail via JMAP, that maps to a list of 'mailboxIds' which are the folders containing that message.

Downloading multiple messages as a zipfile, we already have the facility to download entire mailboxes as a zip file (though it's hidden behind a door that says "beware of the tiger"), so that shouldn't be a problem. The tricky part with anything that CPU intensive is making sure it can't be used for abuse, but I'm working on a generic "turn these blobIds into a zip file" and "turn this zip file into some blobIds" for the new Storage/Files interface which is being built up on beta, so we should be able to hook that directly to JMAP to handle both message attachments and full messages.

Sending multiple messages as attachments. Dammit, I want that too. You're not the first person I've heard it from as one of the key things keeping people going back to classic occasionally. I'm going to whack these three things into tickets for next year and argue for them - they're all well thought out and useful things.

We had a really good support ticket about 3 months back when I made the Inbox => INBOX change from somebody who was worried about classic and enumerated things they cared about, and a lot of those were fixed over a couple of week period. I can't offer quite as fast turnaround this week because half our staff are already off on Christmas holiday.

Quote:
Similarly, I believe the decision to implement recent security changes without consulting the base meant that a mostly excellent enhancement has a major flaw that is very troublesome for some users. The availability of limited access to the web interface (public terminals where U2F is unavailable/blocking some users from editing their own configuration) is not necessary for everyone, but is an important security feature for some. Its lack leads to a situation where security must be sacrificed in some cases so as not to get in the way of getting work done.
This on the other hand, was a clusterf*&( of massive proportions. I was responsible for the half-arsed "limited access" mode, and it was awful. The number of ways that people could break around it meant that it was security theatre, and the amount of extra work required to decide which parts of screens could still work in restricted mode.

I was really glad to see restricted mode die. Maybe the communication about WHY it was going away could have been better, but there's no way we were ever keeping it. Very few people used it (we collected stats, it was in the low hundreds that used it regularly) and it imposed major complexity overhead.


Quote:
There are some new features that would be great to see (my favorite is the editheader sieve extension) but I am a realist. I recognize they would not be strategic for Fastmail, and resigned (without rancor) to be disappointed. Most users do not know what they are missing, so this does not hurt Fastmail.
Ahh, editheader

I'm really hoping we manage to get sieve variables integrated soon. We have potential uses for editheader ourselves, and it's definitely a thing we'd like to do. As you notice, it's a matter of allocating resources. Replacing the current mess of different database formats with a single robust key-value store with structure on top and one atomic transaction would improve the edge cases so much:

https://blog.fastmail.com/2016/12/03...ip-and-beyond/

And I've already sat on my hands for the past 3 weeks and worked on other things even though my grand lovely "zeroskip" database engine is going to be fricking amazing when I have the time to sit down solidly for a couple of weeks and write it.

Quote:
I hope you see the above as constructive, and not an attempt to denigrate the work done by you and your colleagues. Notwithstanding the tendency of some to make posts that are unhelpful, I do fundamentally believe in the concept of "the wisdom of crowds".
I absolutely do, this has been really valuable. Thank you for taking the time, especially to enumerate the features on classic that are holding you from using the regular interface for everything.

I hope I've been able to explain why we killed restricted mode as well - there were too many ways around it to a determined attacker, and it was too complex and costly to maintain.
brong is offline   Reply With Quote