EmailDiscussions.com  

Go Back   EmailDiscussions.com > Email Service Provider-specific Forums > FastMail Forum
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
Stay in touch wirelessly

FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc.

Reply
 
Thread Tools
Old 21 Dec 2016, 01:46 AM   #16
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,552
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:
It gets harder and harder when you have more staff working on the same code and more users using each feature to justify doing one cool little hack for a few users
There are some features that were provided in the past that were clearly a mistake. The custom Javascript hack was a case in point. While sorry to see it go, I cannot recall anybody seriously questioning the necessity.

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:
  • 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.
I make no claim that my experience should mandate keeping these features around when the classic interface is canned (as I think is inevitable). I do believe the decision to remove them should be made only when the impact on the customer base is understood.

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 01:55 AM.
BritTim is offline   Reply With Quote
Old 21 Dec 2016, 02:44 AM   #17
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 345
Quote:
Originally Posted by BritTim View Post
There are some new features that would be great to see (my favorite is the editheader sieve extension) but I am a realist.
For the record, I second a desire to see editheader as well, but I agree that it's a matter of being realistic. In all fairness, I had editheader running on my own (dovecot) server, but still chose to move my MX records back to FastMail for the myriad other benefits it provides. So even there it's a question of tradeoffs, and I can therefore certainly respect that the FastMail team has to juggle a lot of balls

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.
jhollington is offline   Reply With Quote
Old 21 Dec 2016, 07:16 AM   #18
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,666

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
Old 21 Dec 2016, 07:32 AM   #19
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,666

Representative of:
Fastmail.fm
Quote:
Originally Posted by BritTim View Post
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.
I'd just like to look back at this little bit some more.
  • restricted mode didn't make any difference to being able to view emails. Somebody extracting everything could still exfiltrate all your email
  • restricted mode didn't stop you sending email, a stolen session could still be used for spam or fraud
  • restricted mode still allowed you to move messages between folders, just not permanent delete

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.
brong is offline   Reply With Quote
Old 21 Dec 2016, 07:39 AM   #20
brong
The "e" in e-mail
 
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,666

Representative of:
Fastmail.fm
Quote:
Originally Posted by jhollington View Post
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.
That's been something we've been very careful about.

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.
brong is offline   Reply With Quote
Old 22 Dec 2016, 09:31 PM   #21
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,552
Quote:
Originally Posted by brong View Post
I'd just like to look back at this little bit some more.
  • restricted mode didn't make any difference to being able to view emails. Somebody extracting everything could still exfiltrate all your email
  • restricted mode didn't stop you sending email, a stolen session could still be used for spam or fraud
  • restricted mode still allowed you to move messages between folders, just not permanent delete

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.
I deliberately waited quite a while before answering, rereading your points several times. I wanted to be clear in my mind that what I believe to be a reasonable position truly is.

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:
  • People who, on occasion, need to use computers whose status is uncertain can benefit from a combination of one-time passwords and a session that does not allow administrative functions. It is true that, in theory, an active one-time session can be exploited in the background to steal data or impersonate you on emails sent out by malware. It is very difficult to do this in a way that is not visible. In particular, the oft made argument that password reset requests can be made and completed within a one-time session without the user noticing strikes me as fanciful in most cases. On the other hand, stolen credentials (especially those allowing administrative rights) that can be used at leisure are extremely dangerous. Nefarious activities are very likely to go unnoticed.
  • In a business context, we often wish to restrict the ability of individual users to modify rules, specify the devices on which they can access mail, and certain other actions. While we could simply lock the user out from the web interface altogether and mandate use of external mail clients, this seems an unfortunate requirement. We would like to be able to specify that the user can use the web interface to carry out activities analogous to those available in a regular IMAP client, but require administrator assistance for other actions.
I do not regard the above to be exotic options of benefit to only a tiny number of users. Separation of user and administrative concerns is quite common. Time limited access rights are of proven value.

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
  • A setting indicates that one-time passwords can be sent via SMS to the specified phone number. Sessions using one-time passwords would always be limited (no administrative function) sessions.
  • The login screen has an option to the right of the password field "Request one-time password".
  • A short time out (300 seconds, perhaps) is established for sessions initiated using one-time passwords.
Other opinions?
BritTim is offline   Reply With Quote
Old 22 Dec 2016, 11:16 PM   #22
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 345
Quote:
Originally Posted by brong View Post
That's been something we've been very careful about.
...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:
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.
While I'm obviously not up on all of the technical details, I feel like de-duplication of that nature would probably solve a lot of problems. I know that your own IMAP migration tools can handle this well enough, but there are a lot of folks who just think it's a good idea to grab a handful of messages from another IMAP mail provider, or even a local folder, and drag and drop them into a FastMail IMAP folder as a means of "migration" and of course that's going to result in duplicates if something's not done to deal with it. Ironically, Gmail seemed to deal with this in some way at least from a user-facing perspective, I can't comment on what actually ended up in the database

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:
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 can see that. Heck, I've run into that scenario with poorly designed IMAP clients when moving large chunks of messages around where there are duplicates that have different flag status, and JMAP doesn't even enter into that.
jhollington is offline   Reply With Quote
Old 22 Dec 2016, 11:32 PM   #23
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 345
Quote:
Originally Posted by BritTim View Post
People who, on occasion, need to use computers whose status is uncertain can benefit from a combination of one-time passwords and a session that does not allow administrative functions. It is true that, in theory, an active one-time session can be exploited in the background to steal data or impersonate you on emails sent out by malware. It is very difficult to do this in a way that is not visible. In particular, the oft made argument that password reset requests can be made and completed within a one-time session without the user noticing strikes me as fanciful in most cases. On the other hand, stolen credentials (especially those allowing administrative rights) that can be used at leisure are extremely dangerous. Nefarious activities are very likely to go unnoticed.
While I agree that a limit to administrative functions makes some sense in this case, I'm not sure that a separate OTP system provides any more benefit than the new 2FA model already does.

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:
In a business context, we often wish to restrict the ability of individual users to modify rules, specify the devices on which they can access mail, and certain other actions. While we could simply lock the user out from the web interface altogether and mandate use of external mail clients, this seems an unfortunate requirement. We would like to be able to specify that the user can use the web interface to carry out activities analogous to those available in a regular IMAP client, but require administrator assistance for other actions.
Or in a family context. I support this particular one wholeheartedly, and I think that it's easily the most compelling argument to allow for a limit to administrative functions.

Quote:
For one-time passwords, I would suggest
  • A setting indicates that one-time passwords can be sent via SMS to the specified phone number. Sessions using one-time passwords would always be limited (no administrative function) sessions.
  • The login screen has an option to the right of the password field "Request one-time password".
  • A short time out (300 seconds, perhaps) is established for sessions initiated using one-time passwords.
Other opinions?
Other than isolating admin functions and providing a session timeout, I'm still a bit unclear on how you see the OTPs differing from the new 2FA system that's already in place. Granted, in the above scenario the user doesn't need to supply their "real" password, but as long as restricting administrative functions is addressed in a better way, the "real" password is largely irrelevant without the second factor (which of course is the point of 2FA).

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
jhollington is offline   Reply With Quote
Old 23 Dec 2016, 08:44 AM   #24
Terry
The "e" in e-mail
 
Join Date: Jul 2002
Location: VK4
Posts: 2,519
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 .
Terry is offline   Reply With Quote
Old 23 Dec 2016, 07:51 PM   #25
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,552
Quote:
Originally Posted by jhollington View Post
While I agree that a limit to administrative functions makes some sense in this case, I'm not sure that a separate OTP system provides any more benefit than the new 2FA model already does.

...

Other than isolating admin functions and providing a session timeout, I'm still a bit unclear on how you see the OTPs differing from the new 2FA system that's already in place. Granted, in the above scenario the user doesn't need to supply their "real" password, but as long as restricting administrative functions is addressed in a better way, the "real" password is largely irrelevant without the second factor (which of course is the point of 2FA).
Thank you for your (as usual) useful contribution to the discussion.

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
  • Use a weaker form of 2FA as their standard form of authentication.
  • Be prevented from using computers on an ad hoc basis when U2F is unavailable.
  • Having an alternative form of authentication when U2F cannot be used. My argument is that any such access should be time limited and providing as few rights as possible for what I assume to be occasional access when a secure computer is unavailable.
Once U2F (or a common method which is equally secure) becomes ubiquitous, I accept that there is no need for time and function limited, alternative less secure authentication methods. My own sense is that this is not going to be true any time soon. As a practical matter, it cannot even be assumed that you will be allowed access to the USB port on computers that are not your own (for some good security reasons).

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.
BritTim is offline   Reply With Quote
Old 23 Dec 2016, 08:03 PM   #26
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 2,552
Quote:
Originally Posted by Terry View Post
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 .
Terry, I am going to disagree with you about the forum being pointless without Fastmail participation, though I certainly agree that Fastmail participation is of great value.

Two of the objectives of the forum since the beginning have been
  • Self help between users, especially for the kinds of issues that support is not going to be willing to involve themselves in.
  • Providing unbiased feedback to potential new users with the assurance that opinions expressed are not (and cannot be) filtered by Fastmail themselves. As such, positive comments (and most important, absence of some types of negative comments) can be trusted. I really wish this kind of feedback was readily available for certain other products!
Merry Christmas!
BritTim is offline   Reply With Quote
Old 24 Dec 2016, 07:32 AM   #27
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,245
Quote:
Originally Posted by Jacinto View Post
...My biggest frustration is the fact that Fastmail chose to "abandon" EMD...
Quote:
Originally Posted by Terry View Post
...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...
I'm surprised by the implication that Fastmail is aloof from their customers.
  • By my count, in 2016 there were 180 posts to this forum by Fastmail staff (brong, robn, and neilj), or about a post every two days on average. In addition, I and several others have communicated here the results of our personal interactions via email with Fastmail staff. I don't think any other email provider had as may posts at EMD by their staff. To my knowledge, there have never been any posts by the staff of larger firms (Microsoft, Google, Yahoo, AOL).
  • In 2016 there have been 46 Fastmail blog posts. I don't know of any other email provider (or high technology company, for that matter) who provides such personal comments and technical details about what is going on in their organizations.
Quote:
Originally Posted by Jacinto View Post
...Don't wish to recapitulate what others and I already posted on this thread. However, the Fastmail that I subscribed to ten or twelve years ago is not the same FM that is in business today...
Happily, that is quite true. You can't expect a business with over 150,000 customers and a small revenue stream from each customer to act like a tiny two-person startup. I work in high technology sales where we I can justify my in-person support at the customer location for products selling for over US $100K, but it's a much different support model for a start-up with free accounts or low cost accounts.
  • Fastmail started as a real company in 2002 (two years before the introduction of Gmail). It was just two people, and much of the support was here on EMD. So initially there were a large number of posts by the small Fastmail staff here. For years a large number of Fastmail users had Member or Guest accounts with no ongoing charges (and no official personal support), so those users came to this forum for basic support.
  • But now Fastmail is a much larger commercial service with no free accounts (other than short-term trials or grandfathered old Member and Guest accounts) So essentially all users get personal support from Fastmail staff using their ticket system, and there is no reason for them to visit this forum for typical support questions. I'm sure that the effect on the support tickets would be very minor if EMD shut down.
  • According to the Fastmail website front page, they have over 150,000 customers in over 150 countries, with over 40,000 business customers. So it's obvious that only a tiny fraction of Fastmail customers participate in these forums, so there is little incentive for their staff to spend much time here.
  • I agree with the comments by BritTim about the purpose of the EMD Forums. And remember that even though you don't see a post every day by a Fastmail staff member here, if something of importance is posted here it will be communicated by various forum members to Fastmail staff and someone may post a response if appropriate. If you carefully read the posts by Fastmail staff and those who communicate with them away from EMD (and the blog posts), there is a lot going on in the background which isn't visible here in this public forum.
Bill
n5bb is offline   Reply With Quote
Old 24 Dec 2016, 09:23 AM   #28
Terry
The "e" in e-mail
 
Join Date: Jul 2002
Location: VK4
Posts: 2,519
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 09:42 AM.
Terry is offline   Reply With Quote
Old 24 Dec 2016, 10:44 AM   #29
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,245
Have a very merry Christmas or other holiday, Terry. Thank you also for your kind comments.

Bill
n5bb is offline   Reply With Quote
Old 24 Dec 2016, 08:06 PM   #30
Berenburger
The "e" in e-mail
 
Join Date: Sep 2004
Location: The Netherlands
Posts: 2,257
Quote:
Originally Posted by Terry View Post
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.
Times they are a changin'. Merry Christmas and happy emailing in 2017.
Berenburger is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +9. The time now is 05:21 AM.

 

Copyright EmailDiscussions.com 1998-2013. All Rights Reserved. Privacy Policy