Fastmail.com suffering DDOS attack

Just going off the public numbers for one of google's ASNs[0], with the amount of public peers they have (and likely far more private peers, and I'm just assuming google doesn't buy transit and ignoring that), it's unlikely that a DDoS would ever cause an outage for more than a small subset of people. You may be able to saturate a link or two, but that's not difficult to route around generally.

That is of course only for network saturation DDoS, I'm sure there are ways google could be ddosed at the application or server level, but they likely have enough infra in place to be able to eat the attack without anyone outside of google noticing.

[0] https://www.peeringdb.com/net/433

Urbit seems to try to provide a centralized, personalized model for application services. I don't think centralizing is the way to go, mainly because my entire digital life is dependent on de-centralizing all my services. They try to make it out to be like some kind of container you can put anywhere, but that's like saying we should all use one kind of bag for everything we ever need to carry in our daily lives. There's good reasons I have 10 different kinds of bags at home.

Open to flood poisoning.

I'm not referring to POP or IMAP. I can keep my mail offline in any format I choose, anywhere I want. It's just text records. I can keep it in a .pst file, in a Maildir, in an mbox, behind an MUA or any mail retrieval protocol/service. My point was that using a repository like Git, you can simply store your mails (after you receive them, using any mechanism you choose) and then replicate them anywhere, and use any method you choose to interface with the repository later. Think of Git as your mbox or Maildir, and IMAP5 as the protocol+service to interface with it.

The reputation system is a relic of domain-hosted mail. We don't need to rely on it, it's just necessary for the current mail paradigm.

Crypto signatures from/to recipients could help this. You could register your personal signature with a notary, and the network could validate it before sending or receiving. You can then extend the cryptographically-secure identity into any other system you want to determine whether you want to accept the mail.

--

Example 1:

User A wants to send mail to User B. User A and User B both have crypto signatures distributed through notary services on the network. User A connects to a New-SMTP (NSMTP) service called "ZomboCom" and initiates sending a mail. The ZomboCom service checks the signature on the mail, and it's valid on the network. It also checks the recipient signature, and it's also valid on the network. It then accepts the mail. Then, ZomboCom can route the mail, or advertise it for delivery.

User B uses three different NSMTP services - "Flooz", "Webvan", and "eToys". User B has registered their signature with them all, and each validated the signature, and all of them agree to receive mail on behalf of User B.

An additional service can exist on the network which routes users to registered services - a Message Routing service. Flooz, Webvan and eToys can all register themselves with the Message Routing network as valid recipients for User B. When ZomboCom wants to deliver a message to User B, it can simply query which providers are listed as recipients for User B. It can verify they are real providers by cryptographically verifying the records against User B's public crypto key, which is in a different network service, the Public Key service.

So, ZomboCom connects to each of Flooz, Webvan, and eToys, and sends them a notification that there is a message waiting to be delivered for User B. Each one determines they do indeed receive mail for User B, and each then connects to ZomboCom and initiates receiving the mail. They each check User A's signature against a list of revoked signatures, and a separate list of "bad senders". If there is no bad flag, they receive the mail and store it.

Flooz, Webvan and eToys all store the mail in a Git repository for the user. The user can then retrieve their mail by merging each service's repository into their own. They can purge their repositories, edit history to remove old mail, whatever. Since every message is cryptographically signed/hashed, duplicates are easy to identify and ignore. If any one provider stops working, the other will have received the message already.

Example 2:

Spammer wants to send mail to User B. Before the message can make it into the network, they need a crypto signature to sign their mails with.

Even if they run their own NSMTP server, all the recipient servers will be verifying Spammer's crypto signature before accepting. Each server can in turn subscribe to lists of revoked signatures, so if Spammer abuses the privilege of sending and is flagged as a spammer, these different recipient servers are just not going to accept their mail.

Of course, we're still using IP addresses on the low level, so you can always reject connections from certain IP blocks if you want.

--

I should note that almost all of this could be implemented using existing infrastructure. The Git repository and and IMAP5 protocol could be implemented separately by clients and MDAs if they chose, but would not be required for the network component at all; you could do this with existing IMAP4 servers, and provide the p2p network as a way to interface with existing SMTP servers.

Exists already as bitmessage

> They can't really be blamed for a DOS attack.

That doesn't really hold when their competitors have teams of engineers working on DDoS mitigations and successfully handle most of these attacks. Falling to a DoS is a technical failure just like other causes of outages.

If you're paying for Google Apps, you get e-mail and phone support.

I pay $5 / month for google apps for my personal domain. I've had to contact support twice, the first time I got a phone call < 10 minutes after my email, and the second was < 20 minutes via email.

In my experience, Google support is _excellent_ for their paid products.

Used Microsoft/Google/Fastmail in parallel for my company for 6 months. Fastmail won.

I'm gonna disagree with you. I've run my own mail server for my primary email for years and very rarely have any issues.

While there are pain points when it comes to hosting your own mail, it isn't nearly as difficult as you make it.

It gets more difficult if you are providing a service that has to have uptime guarantees or are providing mail to many users but if you take the time to learn and educate yourself on current standards, hosting your own mail for fun and for profit is a doable thing that more developers and admins should do.

We are at a time when we actually have relatively easy to use software to managing mail servers, so us it.

For what it is worth, I have not had problems with Google, Microsoft, Yahoo, or domains that use their services whether it comes to sending or receiving. Sometimes a server is stuck in an SPAM prevention queue or I might have to whitelist a particularly silly server, but that doesn't happen very often.

If the attacker has ever seen the headers of a message you sent through fastmails SMTP service they have your public IP (Received from header) and can Dos you directly anyway.

They do something similar with their webmail service, but the data is encrypted so it can't be read by a third party.

https://www.fastmail.com/about/reportabuse.html (last paragraph)

EDIT: Fastmail is fairly priced (for me) and i like the features they offer but i wish they wouldn't do this (or rather, i wish they would do the same for the SMTP service as they do for the webmail service)

I've never been subject to DOS in fifteen-ish years of running SMTP.

Personal users aren't of interest to DOS ransomers since a call to the ISP will drop their traffic at the border. Without SLAs costing me money, as would be the case with a big provider, I coulf outlast the DOS. Just inconvenient and annoying.

Sure, but I know nothing about Rackspace and refuse to trust them as a result. Plus I doubt they have anything that can compete with Fastmail's web interface, powered by the JMAP protocol they authored.

So here's what I know about Fastmail that I want to know about any provider I host with:

- I know Fastmail will refuse any requests from the US govt to access data because they're Australian and legally the request has to come from an Australian court

- I know Fastmail's servers use encrypted storage

- I know the specs of Fastmail's servers (they post them on their Help/FAQ)

- I know Fastmail's actually trying to make email better, obvious by their invention of the JMAP protocol

- I trust Fastmail to be able to recover from any serious issues because they actually have on staff developers of Cyrus, the open source IMAP software they use. This means their admins have actual recourse when Bad Things^TM happen, vs the usual when an admin runs out of options, eg, "let's just post on mailing lists and hope we can find an answer"

- I know the fine details of how their spam filtering works, because it's publicly documented. (and it's quite well integrated with some tricks I couldn't employ at my last ISP job as I didn't have developers to assist)

- I know their infrastructure is primarily hosted in NYI with the backup in Iceland.

- I know they are serious about security, as they've been proponents of full SSL/TLS vs STARTTLS which could be MITM and downgraded (yes, many MTAs will let you require STARTTLS, but there are always possibilities of client bugs that could be exploited when you let an attacker intercept plaintext and inject data before the upgrade to a validated TLS session)

- I know how their backups work, because it's documented and I also have the ability to undelete emails which almost no provider gives the end user.

- I know their support is responsive and competent, as they've actually fixed Webmail bugs and put them into production for me within 48 hours

- Fastmail does PUSH email on iOS, while GMail, Rackspace, and most other providers don't offer this because it requires custom integration with Apple's Push Notifications service.

tl;dr yeah, the average provider might promise the moon but can they actually deliver when the shit hits the fan? will they actually strive to please their users and make the internet a better place? probably not.