Oh goody - programmable number plates. What could possibly go wrong. I can just imagine how happy the jackers are going to be - no need to switch plates, just upload a custom firmware and you're gold.
That would be me, hopefully:) Not forever, but for a while. Long enough for the kids to pick up a new language while they're still young and for me to learn all I can from the people there and teach them everything I know!
I guess you haven't seen what's going on behind the scenes. We haven't been quite so public, but personally I've been doing a LOT of work improving the Cyrus imap server that we run on. It's stability and the reliability of the replication system has improved enormously over the past few years, and most of that has been due to FastMail investing time (mostly mine:) ) in not only working on Cyrus itself, but in the monitoring and introspection tools we use to make sure that the replicas are truly up-to-date.
We've almost fully rolled out UTF-8 support internally throughout our interface, which you'll notice if you have to deal with emails with more than one character set at any point. In the past we did everything in a user's default characterset, which was OK for most people but a pain for some.
And heaps of minor fixes that most people don't ever see:)
We put a lot our eggs in one basket for a bit - we had a 2Tb (yeah, I know - not so big by today's standards) RAID6 set die when 3 disks failed. This is before we had replication. It took about 2 weeks to get everyone back online as we streamed from backups as fast as we could!
Our infrastructure is a lot more fault-tolerant now. We actually lost a RAIDset about 3 weeks ago when two drives failed within about an hour of each other (a RAID1 of 150Gb drives - it was about 80% rebuilt)
Users didn't notice anything at all, but there were a couple of days when a subset of our users didn't have a realtime-replicated copy of their mail store as replication re-synced all their data to the new drives.
And after any power failure it was all dead. Sorry, you're wrong. I'm taking the time to respond specifically because you show up with green dots which I assume means you've shown clue at some time in the past.
It's a like a building where the people inside can still work and the people outside can go home, but nobody can get in or out. Yes, everything kept running, but it was a house of cards and without Childs it couldn't be repaired or altered. That's not a functioning network. The fact that things kept working was pure dumb luck that there wasn't a power outage on a core router.
This. I miss the KDE that was nice and easy to use, but Gnome got good enough right about the time KDE got shit. Maybe if I wasn't on Ubuntu mostly I'd consider switching back now, but Kubuntu is still the poor cousin, and Ubuntu has enough problems with consistency without having to worry about more of them.
I should point our sales critter at you! FastMail does very similar things, and has an archival system for businesses needing to retain all emails for discovery purposes.
We also have very good privacy policies - plus being Australian based but with all the servers in the US, we're very well set up to protect privacy.
Australian privacy and telecommunications law means we _can't_ comply with US subpoenas, it has to go via a convoluted mutal assistance treaty that ends up going via the Australian Attorney General. US law enforcement are a lot more willing to accept "I can't do that or I'll be breaking the law" than "I refuse on moral grounds" because any information is unusable unless it's come via the appropriate due process. It certainly puts a stop to speculative fishing!
Kids these days go home and play Xbox. They don't play sports after school because there's no adult supervision and a creepy prevert might come and watch them...
Facebook also had a thing "give us your gmail or hotmail password and we'll log in and retrieve your contact email addresses and offer you to add them as friends if they have a Facebook account already" - presumably they stored those passwords as well.
Active bodies learn better. Now - there's a fair argument for dance or sport instead of "Phys Ed" but a school's job shouldn't just be force feeding information into a kid's brain - it's about development of the entire person and the includes both physical and mental development.
It's a standard technical name for an API, which is why I can say it with a straight face rather than obfuscate around it. The package is called truedomain-milter, for obvious reasons.
If you spoof the headers they'll be dropped on receipt. Note that the message still has to pass DKIM or SPF as well.
Now - if you upload a spoofed message via IMAP you can fool our web interface, but the only person who's going to see that is you or someone else who's shared your folders.
And yeah - we do trust Truedomain because we know the people who run it. Presumably they work on trust building with other people. It's similar to Verisign - why should we trust them? I won't answer that. I trust Truedomain more.
describes the way Truedomain operates. We run a milter which applies X-Truedomain-* headers (view source on those messages - you'll see that even the Logo image is added a per-message basis as a Base64 encoded header)
We're also planning to colour messages from known senders (in your address book) and offer a link to the address book entry that caused them to be trusted, as well as labelling messages that have gone entirely through a trusted path. I added a bunch of extra headers to the list that Cyrus caches on the fast metadata drives to support all this just last week! We've been beta testing Truedomain for a while on one of our incoming MX servers, and it's now applied to all incoming email.
You mean the cost of re-tooling every system on the planet to use a more secure protocol than SMTP (or the ad-ons that have been created to do half a job of fixing the issue)
Answer: plenty more than that. It's not insecure shit that causes a mail server to have trouble determining valid vs invalid SMTP connections, it's the lack of authentication in the protocol. SPF, CSV, DKIM, etc all help - but only if they're correctly set up, and they require 100% subscription before you can ditch anything with them. Not going to happen.
But hey - HTML and CGI have nothing to do with email protocols, so I'm going to assume you're a clueless kiddie who's never run a serious mail server in your life. The best I can say about your point is "you're not right - you're not even wrong".
"Do you want to trust your data to a closed source file system implementation which you can't debug, can't improve and — most scarily — can't even fsck when it goes wrong, because you don't have direct access to the underlying medium?"
This is what you get with a flash drive at the moment unfortunately - a closed source filesystem that presents a single "file" as a block device over sata. And this firmware update is a filesystem driver change. Ouch.
To get in that list a host has to have connected to us and then held on to the connection for 5 minutes without sending ANYTHING down the wire multiple times. It doesn't tend to contain real MXes ever, and it's easy to whitelist an IP address that's known to behave a little strangely.
Unfortunately, mail is a fail sort of business - you have to strike a balance between all your users getting scads of spam and blocking the worst-behaved machines (temporarily) for their behaviour. It means if someone's provider has been a bad net citizen then their legitimate email might not get through for a bit.
Honestly, you sound like someone who's best off running their own mail service, because very few sites will provide the service you want (trust any random SMTP connection and accept whatever they spew) especially if they are big enough to become the targets of DOS attacks. Being trusting just doesn't scale out in the real world.
(and yes, I have missed wanted email in a deluge of spam before - my personal domain has been hit with so much different spam that I just didn't recognise the message in amongst the junk and deleted it. Thankfully I kept a full archive folder with copies of all incoming email and I could find it once I knew it had been sent. There's no perfect answer that gives you a clean feed of only the legitimate stuff)
Cool. Some day I would like to learn how IMAP service is distributed over several boxes. In the late 90s I thought about that problem and decided that I didn't have the sysadm skills to do it (so just threw more memory and faster disks at our IMAP server).
There's a whole blog post about it somewhere I think - but the brief summary is: lots of independent Cyrus configurations and disk partitions (we have up to 40 separate Cyrus instances on a single server - keeps the partitions small and damage contained if there's filesystem corruption for any reason). Then there's an nginx proxy in front of it all that talks to an authentication server which returns the IP address of the backend server to connect to.
We run one IP address (10.*) for each Cyrus master instance, and when we switch over to the replica the IP address goes with it. Keeps the authentication daemon simple!
So yeah - we do it by keeping everything totally separate. It means we can't share folders between "stores" as we call them - so if you create a business/family account, there's a background job that will notice you import users and move them all to the store where that account's master user was created. We also collect disk usage information every few minutes, and there's a background task that automatically balances the usage by moving users amongst the stores.
There's stuff that we block before we even know who it's addressed to. At one point (I haven't checked recently) we had over 1 MILLLION IP addresses that were being blocked from even connecting to our MX servers (for a 24 hour rolling block none less) because of their behavior.
But you can certainly turn the spam scanning right down to the point where anything that's not pretty ugly will be allowed into your mailbox. I have my spam scanning turned a fair way up, and the only false positives I've had are newsletters from companies that I do have a relationship with. Adding them to my address book fixes that up just fine.
Training my personal bayes database has certainly helped reduce the spam through to my Inbox as well (my personal domain address has been around for a while and gets ~400 spam/day)
Fastmail runs the kind of system that I would have like to design.
Why thanks:) I designed a lot of the current system (Cyrus replication slots and stores plus the "10 minutes to reinstall any server" and "make -C conf install" to get config up to date on any server)
Slashdot Mirror
Oh goody - programmable number plates. What could possibly go wrong. I can just imagine how happy the jackers are going to be - no need to switch plates, just upload a custom firmware and you're gold.
That would be me, hopefully :) Not forever, but for a while. Long enough for the kids to pick up a new language while they're still young and for me to learn all I can from the people there and teach them everything I know!
I guess you haven't seen what's going on behind the scenes. We haven't been quite so public, but personally I've been doing a LOT of work improving the Cyrus imap server that we run on. It's stability and the reliability of the replication system has improved enormously over the past few years, and most of that has been due to FastMail investing time (mostly mine :) ) in not only working on Cyrus itself, but in the monitoring and introspection tools we use to make sure that the replicas are truly up-to-date.
We've almost fully rolled out UTF-8 support internally throughout our interface, which you'll notice if you have to deal with emails with more than one character set at any point. In the past we did everything in a user's default characterset, which was OK for most people but a pain for some.
And heaps of minor fixes that most people don't ever see :)
We put a lot our eggs in one basket for a bit - we had a 2Tb (yeah, I know - not so big by today's standards) RAID6 set die when 3 disks failed. This is before we had replication. It took about 2 weeks to get everyone back online as we streamed from backups as fast as we could!
Our infrastructure is a lot more fault-tolerant now. We actually lost a RAIDset about 3 weeks ago when two drives failed within about an hour of each other (a RAID1 of 150Gb drives - it was about 80% rebuilt)
Users didn't notice anything at all, but there were a couple of days when a subset of our users didn't have a realtime-replicated copy of their mail store as replication re-synced all their data to the new drives.
And after any power failure it was all dead. Sorry, you're wrong. I'm taking the time to respond specifically because you show up with green dots which I assume means you've shown clue at some time in the past.
It's a like a building where the people inside can still work and the people outside can go home, but nobody can get in or out. Yes, everything kept running, but it was a house of cards and without Childs it couldn't be repaired or altered. That's not a functioning network. The fact that things kept working was pure dumb luck that there wasn't a power outage on a core router.
Now all we need is to hook this in to the camera networks that already exist in a lot of cities.
Seriously, it solves the "who watches the watchers" problem and adds heaps of interest. Real time public video feeds.
This. I miss the KDE that was nice and easy to use, but Gnome got good enough right about the time KDE got shit. Maybe if I wasn't on Ubuntu mostly I'd consider switching back now, but Kubuntu is still the poor cousin, and Ubuntu has enough problems with consistency without having to worry about more of them.
I should point our sales critter at you! FastMail does very similar things, and has an archival system for businesses needing to retain all emails for discovery purposes.
We also have very good privacy policies - plus being Australian based but with all the servers in the US, we're very well set up to protect privacy.
Australian privacy and telecommunications law means we _can't_ comply with US subpoenas, it has to go via a convoluted mutal assistance treaty that ends up going via the Australian Attorney General. US law enforcement are a lot more willing to accept "I can't do that or I'll be breaking the law" than "I refuse on moral grounds" because any information is unusable unless it's come via the appropriate due process. It certainly puts a stop to speculative fishing!
That's what's know in the industry as a "joke".
Kids these days go home and play Xbox. They don't play sports after school because there's no adult supervision and a creepy prevert might come and watch them...
Facebook also had a thing "give us your gmail or hotmail password and we'll log in and retrieve your contact email addresses and offer you to add them as friends if they have a Facebook account already" - presumably they stored those passwords as well.
er, "that includes" of course. Guess it didn't work for me.
Active bodies learn better. Now - there's a fair argument for dance or sport instead of "Phys Ed" but a school's job shouldn't just be force feeding information into a kid's brain - it's about development of the entire person and the includes both physical and mental development.
You again - what do you have against gym? Lazy much?
http://en.wikipedia.org/wiki/Milter
It's a standard technical name for an API, which is why I can say it with a straight face rather than obfuscate around it. The package is called truedomain-milter, for obvious reasons.
If you spoof the headers they'll be dropped on receipt. Note that the message still has to pass DKIM or SPF as well.
Now - if you upload a spoofed message via IMAP you can fool our web interface, but the only person who's going to see that is you or someone else who's shared your folders.
And yeah - we do trust Truedomain because we know the people who run it. Presumably they work on trust building with other people. It's similar to Verisign - why should we trust them? I won't answer that. I trust Truedomain more.
http://blog.fastmail.fm/2010/01/06/truedomain-anti-phishing-and-email-authentication/
describes the way Truedomain operates. We run a milter which applies X-Truedomain-* headers (view source on those messages - you'll see that even the Logo image is added a per-message basis as a Base64 encoded header)
We're also planning to colour messages from known senders (in your address book) and offer a link to the address book entry that caused them to be trusted, as well as labelling messages that have gone entirely through a trusted path. I added a bunch of extra headers to the list that Cyrus caches on the fast metadata drives to support all this just last week! We've been beta testing Truedomain for a while on one of our incoming MX servers, and it's now applied to all incoming email.
You mean the cost of re-tooling every system on the planet to use a more secure protocol than SMTP (or the ad-ons that have been created to do half a job of fixing the issue)
Answer: plenty more than that. It's not insecure shit that causes a mail server to have trouble determining valid vs invalid SMTP connections, it's the lack of authentication in the protocol. SPF, CSV, DKIM, etc all help - but only if they're correctly set up, and they require 100% subscription before you can ditch anything with them. Not going to happen.
But hey - HTML and CGI have nothing to do with email protocols, so I'm going to assume you're a clueless kiddie who's never run a serious mail server in your life. The best I can say about your point is "you're not right - you're not even wrong".
This post really needs a link to:
http://lwn.net/Articles/355149/
"Do you want to trust your data to a closed source file system implementation which you can't debug, can't improve and — most scarily — can't even fsck when it goes wrong, because you don't have direct access to the underlying medium?"
This is what you get with a flash drive at the moment unfortunately - a closed source filesystem that presents a single "file" as a block device over sata. And this firmware update is a filesystem driver change. Ouch.
To get in that list a host has to have connected to us and then held on to the connection for 5 minutes without sending ANYTHING down the wire multiple times. It doesn't tend to contain real MXes ever, and it's easy to whitelist an IP address that's known to behave a little strangely.
Unfortunately, mail is a fail sort of business - you have to strike a balance between all your users getting scads of spam and blocking the worst-behaved machines (temporarily) for their behaviour. It means if someone's provider has been a bad net citizen then their legitimate email might not get through for a bit.
Honestly, you sound like someone who's best off running their own mail service, because very few sites will provide the service you want (trust any random SMTP connection and accept whatever they spew) especially if they are big enough to become the targets of DOS attacks. Being trusting just doesn't scale out in the real world.
(and yes, I have missed wanted email in a deluge of spam before - my personal domain has been hit with so much different spam that I just didn't recognise the message in amongst the junk and deleted it. Thankfully I kept a full archive folder with copies of all incoming email and I could find it once I knew it had been sent. There's no perfect answer that gives you a clean feed of only the legitimate stuff)
Cool. Some day I would like to learn how IMAP service is distributed over several boxes. In the late 90s I thought about that problem and decided that I didn't have the sysadm skills to do it (so just threw more memory and faster disks at our IMAP server).
There's a whole blog post about it somewhere I think - but the brief summary is: lots of independent Cyrus configurations and disk partitions (we have up to 40 separate Cyrus instances on a single server - keeps the partitions small and damage contained if there's filesystem corruption for any reason). Then there's an nginx proxy in front of it all that talks to an authentication server which returns the IP address of the backend server to connect to.
We run one IP address (10.*) for each Cyrus master instance, and when we switch over to the replica the IP address goes with it. Keeps the authentication daemon simple!
So yeah - we do it by keeping everything totally separate. It means we can't share folders between "stores" as we call them - so if you create a business/family account, there's a background job that will notice you import users and move them all to the store where that account's master user was created. We also collect disk usage information every few minutes, and there's a background task that automatically balances the usage by moving users amongst the stores.
There's stuff that we block before we even know who it's addressed to. At one point (I haven't checked recently) we had over 1 MILLLION IP addresses that were being blocked from even connecting to our MX servers (for a 24 hour rolling block none less) because of their behavior.
But you can certainly turn the spam scanning right down to the point where anything that's not pretty ugly will be allowed into your mailbox. I have my spam scanning turned a fair way up, and the only false positives I've had are newsletters from companies that I do have a relationship with. Adding them to my address book fixes that up just fine.
Training my personal bayes database has certainly helped reduce the spam through to my Inbox as well (my personal domain address has been around for a while and gets ~400 spam/day)
Bron ( FastMail sysadmin )
fastmail.net is pretty good - we've had that for a few years now. Sadly we don't have .com. Plenty of other .coms though:
http://www.fastmail.fm/help/signup_domains.html
I haven't been paged yet (fingers crossed)
Fastmail runs the kind of system that I would have like to design.
Why thanks :) I designed a lot of the current system (Cyrus replication slots and stores plus the "10 minutes to reinstall any server" and "make -C conf install" to get config up to date on any server)
Bron ( sysadmin at FastMail )
I have no joke, I'd just like to quote:
"Suicides in Japan/South Korea jumped"