|
FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc. |
|
Thread Tools |
21 Dec 2016, 12:46 AM | #16 | |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
Thank you Bron for taking the time to engage with us. I think I speak for the vast majority of us here when I say that, even when we unfairly take out our frustrations on you, we nevertheless really appreciate your willingness to show we are not ignored.
I have always found you totally honest in what you say (evidenced by your admission that EMD was deliberately neglected, and the understandable reasons why). I firmly believe honesty is the best policy. You will sometimes be attacked when delivering a message people do not like, but it builds trust in the long run that is worth some discomfort. If I may, I would like to make a few comments on this: Quote:
Other items are more worthy of discussion. Here are a couple of examples of things available in the old classic interface, but difficult to do in the current interface. They are not used every day, but are important on occasion for one or more of my customers:
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 is particularly tragic as, in most respects, the new security system is a big improvement over the old one. Discussion with the base prior to implementation would, I feel, have avoided this blind spot. 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. 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". Last edited by BritTim : 21 Dec 2016 at 12:55 AM. |
|
21 Dec 2016, 01:44 AM | #17 | |
Essential Contributor
Join Date: Apr 2008
Posts: 371
|
Quote:
One thing that I do appreciate about FastMail is that they provide a robust web interface that doesn't detract from "pure IMAP" — while support for things like labels would always be nice, I'd hate to see that implemented in a way that precludes the use of IMAP email clients. I don't think we have to look very far to see an example of an ugly, non-standard IMAP implementation resulting from too strong of a focus on a web-based interface. |
|
21 Dec 2016, 06:16 AM | #18 | ||||
The "e" in e-mail
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696
Representative of:
Fastmail.fm |
Quote:
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:
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:
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 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. |
||||
21 Dec 2016, 06:32 AM | #19 | |
The "e" in e-mail
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696
Representative of:
Fastmail.fm |
Quote:
Permanent delete isn't really permanent anyway, it's just setting a \Expunged system flag, then cyr_expire cleans up the email a week later. We already offer a self-serve restore from backup, which gets you back the email in the folder it was in, rather than wherever it was moved to. What we could do (and it's on the roadmap as a wishlist item, because it's a ton of work) is something nice where you can see "in session X you deleted 5000 messages at 5:25am from <ipaddress>[countrycode]" with a button to restore just that set of messages along with an extra folder/label which allows you to quickly view them all... But anyway, you can get back email if someone steals your session and wipes out a ton of messages. You were never more safe from them reading all your email or moving it all around or sending stuff on your behalf by having restricted mode. It was a crappy concept that I wrote when I wasn't thinking carefully of all the implications. Bron. |
|
21 Dec 2016, 06:39 AM | #20 | |
The "e" in e-mail
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696
Representative of:
Fastmail.fm |
Quote:
We have one issue for regular IMAP clients at the moment which fell out of how we implemented XCONVMULTISEARCH way back 5 years ago. If you have messages with \Deleted flag set but not yet EXPUNGED via IMAP, we will nuke them straight away. We had to do that, because otherwise it made the sort mutable in horrible ways, and made everything really slow. We have a plan to fix that restriction though, and finally remove it. There's also debate over whether we will allow multiple exactly identical messages in the same mailbox. Same bytes. If we don't, it would be implemented as immediately expunging the old copy when you added a new one, because that's safest against IMAP clients which do something like move-to-current-folder through some bug, and proceed to EXPUNGE the old UIDs. Certainly, it's going to be a bit complex allowing both UID view and JMAP ID view of the same messages, because we'll have to merge the flags somehow - if you set a flag via JMAP we probably want to set it on all messages, but if you clear it from ONE of the UIDs via IMAP, do you want to clear it from all? Tricky. I spend an inordinate amount of my day thinking about things like this. Bron. |
|
22 Dec 2016, 08:31 PM | #21 | |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
Quote:
Firstly, I am not claiming either that a restricted mode is a panacea, or that the restricted mode that existed in the past was the ideal approach. It is a fact that security features involve real effort to implement properly, and no one benefits from security theater that confers no real protection. However, it is in both the users' and in Fastmail's interest to have controls available that limit the opportunity for abuse. I think the points you raise on the limitations of restricted sessions miss the point. I see two main areas where alternative restricted logins can be of benefit:
I am sure implementation would raise some detailed challenges. However, I would argue the basic structure is not that complex. The session could have a flag that indicates whether or not administrative rights are available. Web interface menus adapt accordingly, together with checks when entering an administration page that it should be allowed. For one-time passwords, I would suggest
|
|
22 Dec 2016, 10:16 PM | #22 | ||
Essential Contributor
Join Date: Apr 2008
Posts: 371
|
...and it shows
I've moved my mail back and forth between FastMail and other services, including my own Dovecot server, enough times that I've come to appreciate the intricacies of good IMAP (many of my "migration tools" over the years have been my own hacked-together Python and Perl scripts). Then there's the inscrutable way that the iOS Mail app handles IMAP sessions and UID FETCH, especially in larger mailboxes, and what it does to the sort order of messages if they weren't filed into the folders chronologically in the first place (as often happens when moving large chunks of messages or reorganizing things). On my own server, I went so far as to actually run a script to reset the mtimes on the underlying mbox files and then force a regeneration of all UIDs so that everything would be nice and chronological Forget non-standard server IMAP implementations. Some ideas of how to build IMAP clients are even nuttier. Quote:
To make matters even more complicated, I know that some mail clients — Apple Mail for macOS comes to mind — have actually started filtering out duplicate messages in the UI, regardless of what exists on the IMAP server or in the underlying store. Doesn't mean the messages won't be there, but the end user will never see them, which can lead to all sorts of other confusion when doing back-end comparisons of message counts. Quote:
|
||
22 Dec 2016, 10:32 PM | #23 | |||
Essential Contributor
Join Date: Apr 2008
Posts: 371
|
Quote:
Even then, I'm not sure limited administrative functions are much more than security theatre either. I mean, they provide some real security, but against what particular threat model? A hijacked session? Most changes a hijacker could make in administrative preferences aren't usually anything critical, and a log/notification of administrative access changes might serve just as well in this case. It would also require an attacker to have built something to mess with the FastMail UI specifically. Security changes still can't be reset without providing the real password — although how that's now handled should be the subject of a separate discussion, since of course if you've entered it once, even with 2FA, an attacker theoretically has that password and can replay it into the security preferences field (in your current session). I would agree that this needs to be shored up somehow when working on "untrusted" computers. Placing a similar restriction on making other major administrative changes, such as adding/removing domains and aliases, could be locked behind a similar additional level of authentication as well, which would make sense to me — these aren't things that users change on a regular enough basis to have a need to justify "casual" access to them without authenticating again to prove that your session hasn't been hijacked, either by malware or by somebody walking up to your PC that you've left logged in Quote:
Quote:
Obviously if you're talking about administrative restrictions, there needs to be a way to differentiate the session, but that could just as easily be accomplished with an "untrusted computer" style checkbox. Remember that as long as we're talking about using 2FA, we don't get re-playable credentials anyway, so a hijacked session and intercepted password would be of no benefit provided the limited session access was properly handled by FastMail on the back-end (and again, admin functions were properly locked down in such a way that having the one-factor password wouldn't open up access to things that it shouldn't). Anyway, some good thoughts here either way, and it's an interesting discussion. Ultimately I'm just playing devil's advocate here |
|||
23 Dec 2016, 07:44 AM | #24 |
The "e" in e-mail
Join Date: Jul 2002
Location: VK4
Posts: 3,029
|
Brong, thank you for you post, at least now we know what all your thoughts are on the F/m forum.
Personally I don't see the point of having a F/m forum without someone from F/m participating......you might as well close it down and wait for the influx of support tickets.... As you may well know running a business is not all about grabbing the $ it involves keeping your customers by making sure they are happy and hopefully it will stop them looking for crappy alternatives. Merry Christmas to all you guys in there . |
23 Dec 2016, 06:51 PM | #25 | |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
Quote:
First, I am assuming that regular access, where possible, should be using U2F. I argue for OTP in the common case where those using computers on an ad hoc basis are unable to establish a session using U2F. The choices for such users are
I am open to the argument that limiting functionality is less important than time limiting of less secure sessions. However, I think both have merit. |
|
23 Dec 2016, 07:03 PM | #26 | |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
Quote:
Two of the objectives of the forum since the beginning have been
|
|
24 Dec 2016, 06:32 AM | #27 | |||
Intergalactic Postmaster
Join Date: May 2004
Location: Irving, Texas
Posts: 8,930
|
Quote:
Quote:
Quote:
|
|||
24 Dec 2016, 08:23 AM | #28 |
The "e" in e-mail
Join Date: Jul 2002
Location: VK4
Posts: 3,029
|
Some good points Bill, and I do realise fastmail do things a little differently to what they did in 2001-2002 but in the old days we were made to feel part of the concept and I really enjoyed those days but sadly they are not going to come back are they.
Thank you for all your help you have given everyone over the last few years. Terry.... Last edited by Terry : 24 Dec 2016 at 08:42 AM. |
24 Dec 2016, 09:44 AM | #29 |
Intergalactic Postmaster
Join Date: May 2004
Location: Irving, Texas
Posts: 8,930
|
Have a very merry Christmas or other holiday, Terry. Thank you also for your kind comments.
Bill |
24 Dec 2016, 07:06 PM | #30 |
The "e" in e-mail
Join Date: Sep 2004
Location: The Netherlands
Posts: 2,908
|
Times they are a changin'. Merry Christmas and happy emailing in 2017.
|