Slashdot Mirror
Why Email is a Bad Collaboration Tool
An anonymous reader writes "Isaac Garcia follows up his popular "The Good in Email" article with "The Bad in Email or (Why Steve Ballmer is the CTO of Microsoft)":
"In spite of email's universal success (as a collaboration tool), and in spite of its many good traits, email contains deep, inherent flaws that force users and markets to seek alternatives to collaborating via email."
Wait a few minutes
Yeah, I think I'd pretty much wait for you in the parking lot after work. And I wouldn't be there to give you a hug, ifyaknowwhatimean.
Oh, by the way, my boss has it somehow set to default that it's urgent and he needs a response once I've read it. Same with his secretary. Urge to kill rising
My work here is dung.
An intelligent user of email considers whether sending an email is appropriate for the communication at hand. That's the way it is with so many tools--they're often misused, but that doesn't mean they don't still have their proper place.
The summary states the title of the article as: "The Bad in Email or (Why Steve Ballmer is the CTO of Microsoft)"
Two problems with that:
Problem #2 is especially difficult to understand, as the article itself correctly identifies Ray Ozzie as Microsoft's CTO.
____
~ |rip/\/\aster /\/\onkey
Steve Ballmer != CTO
What I mean by silo'ed is that email traps information into personalized, unsharable, unsearchable vacuums where no one else can access it - the Email Inbox. Think of your Email Inbox as a heavily fortified walled garden. Not mentioning the difficulties many have accessing their Email Inbox outside the corporate firewall, the Email Inbox contains a hodgepodge of business, personal and private information that most people do not want to share with others.
Unfortunately, the Walled Gardens of our Email Inboxes are deceivingly warm and cozy. This feigned-comfort of safety whispers into our ears like a wily devil to, "Just email the document to me" or "Just email that document to yourself" with the false-belief that it will remain safe, secure and locked away. But that is just it......its locked away so that NO ONE ELSE CAN ACCESS IT. This is counter-culture to team collaboration.
And how many times have you sent out a document for comment and gotten back 30 different versions with markups, which you then have to reintegrate into one document and somehow handle inconsistencies and overlap? Then of course you need the document, but don't have a copy where you're at, so you retrieve one from an email and use that, but it's an old version, so you have to recreate revisions. And then someone always emails you their revisions late, after you think you're all done (usually it's your boss, so it's not like you can just leave them out).
If nothing else, you need a document collaboration tool, to avoid this nightmare of multiple files, and email is not it.
GetOuttaMySpace - The Anti-Social Network
I believe the problem with Email is usually only 10% of what you are trying to communicate is actually understood.
:-)
Sort of like posting on slashdot.....
RTFG - Read The F#$%ing Google!
From the article:
The single worst trait of email is that it's silo'ed.
Then he says:
For many folks, the Email Inbox contains their most intimate secrets all mashed together into a single location: business correspondences, contracts, proposals, reminders, tasks, love letters, indiscreet online purchases, dirty jokes, pictures of your spouse (and kids), time-wasting games, inappropriate messages from co-workers and friends and lets not forget spam.
To me it seems like the perfect argument for why email should be silo'ed, and that it's one of the reasons why it is still so popular. I completely agree with his comment that there is a wealth of information hidden within emails that others could/would find useful. However, there obviously is even more that most would find useless or that the inbox owner wouldn't want visible. To me email represents the best, if flawed compromise. If the inbox owner wants to, they can redistribute their emails to a wider audience. This can be done by forwarding, or in Outlook, simply dragging the email to a public folder. I think the alternative approach, assume that everything is public and force the user (either sender or receiver) to selectively "hide" or "target" emails falls too far on the "other side" for most companies.
In development over the last 5 years I think the most useful tools are IM (or IRC) and Wiki. Email can be used to setup a time to meet/work on things, from there constant talk back/forth via IM is perfect. Hashing out overall ideas via the Wiki is perfect for before and after, and allows for ones ideas to get fully out there, then edited by others during critque.
This has been true for me working on OSS at night with a partner in Qubec as well as working in the same office with a developer two aisles away.
fak3r.com
"The Bad in Email or (Why Steve Ballmer is the CTO of Microsoft)"
:)
Except the article says :
Therefore, we'd like to present The Bad In Email, or Why Ray Ozzie is the CTO of Microsoft.
There's a bug somewhere... maybe bad RAM, or buggy software, maybe between the chair and keyboard (if your chair hasn't been thrown away by Steve, that is)
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
A fairly insightful article, but it misses a couple of points:
It's difficult (if not impossible) for the average user to discern who an e-mail is actually from. Most people have no idea about message headers or IP addresses. It is trivial to send e-mail spoofing the address, and have 95% of people unquestioningly believe it's from the address you specify. This is one of the biggest and easiest to exploit weaknesses in e-mail.
E-mail is incredibly easy to ignore. Really, really, really easy. Claiming you didn't receive an e-mail is a get-out to any number of problems in collaborative projects, mostly because it's so common - it's fairly easy for an e-mailto not get to its recipient, be it an over zealous spam-filtering policy, a misconfigured mail server somewhere along the line or a lack of space on a company intranet (combined with badly configured mail servers which are relatively common).
Good day to you, troll.
I am not a troll.
There is a real opportunity here that I believe the OSS community is missing, which is why I was deliberately provocative.
Image if sending emails between OSS clients like Thunderbird was actually better than using, for instance, Outlook. I could say to my contacts, hey use Thunderbird for your email and you'll know that I've received it. They might then say to their contacts the same thing, and the uptake spreads. Firefox spread because it is better than IE. Thunderbird would spread like wildfire if it could do secure, guaranteed (to arrive, or notification if not) email.
I have that turned off. You will never know :) And no one can even read my calendar, let alone insert ( except the exchange admin of course, which i am one )
Oh, and if you tag it as important. i ignore it that much faster.
Yes i know you were joking.. however i wasnt...
---- Booth was a patriot ----
Where's the problem, again?
"If you are using POP or IMAP, you need to know that they both require you to send unencrypted authentication (username/password)."
Ah, not necessarily. Especially in the IMAP world, see IMAP over SSL.
[insert story about linux box and IMAP/SSL/MUTT]
Here's the real problem: You tried to scare your audience with concepts that your target audience doesn't understand. You can't scare ignorant people, see low limit Texas Hold'em.
Anything is possible given time and money.
Crap. Crap. Crap.
Good, now that that's out of my system, I'll explain.
Email WITHIN my domain is guaranteed. Honest. If someone (say joe@jupiter.lan) sends mail (to, say, jane@earth.lan), its going through.
If joe@jupiter.lan sends mail to peter@scrape_me.com (whatever), it is rewritten to joe@scrape_this.com, and forwarded to forward_this_shite.net.
After which IT ISN'T MY RESPONSIBILITY. If it can't be forwarded on, it WILL be returned to joe@jupiter.lan. Once accepted, though, I don't care. Not my network. And this makes the world go around.
If there are problems within your LAN or your system, its your responsibility. The original Unix just dropped the mail into the file system. Which is as reliable as the file system. No delivery issues. Linking networks together; as reliable as the linking/forwarding services used.
I can't and won't be responsible for other peoples networking and administration skills.
Ratboy
Just another "Cubible(sic) Joe" 2 17 3061
Some great quotes :
Email is NOT Secure (Part 1)
[...]
(Anyone using cryptographic e-mail is in the minority and the exception to the rule.)
Anyone needing secure e-mail is in the minority and the exception to the rule.
there is no way to 'retract' your email.
And how are you retracting your mail ?
Email is Prone to Viruses
There is no need to elaborate here.
You should make an effort. I do not understand.
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Hey! I know!
SMTP offers guaranteed delivery. It's a connection oriented protocol. If it fails, it lets you know, and it only fails if the other server isn't there. So the only problem beyond that is that local delivery is misconfigured...not really a problem in software design, is it?
I guess that solves the first problem.
Now to make it secure...Kerberos! That's about as secure as you can get. But how to do kerberos+smtp? What about POP3 or IMAP? Can we kerberize those, too? Maybe we can let MIT take care of it...
Oh, wait, they have! MIT makes it and uses it on their own servers and clients! Did we win? Yay!
Turns out that secure+guaranteed aren't actually hard requirements to meet - that they have already been met before. What people really want is the stuff that exchange provides - which is neither of those things.
However, if that's what YOU want, then may I suggest that you look for it a little?
Mod me down and I will become more powerful than you can possibly imagine!
There is a way to use e-mail as such a tool, which was the preferred method used by the Spanish Al-Queda cell:
1. Open e-mail account (on your own web mail server, preferably) and publish username/password to members of cell/department/workgroup.
2. Write e-mail detailing plan and save as "draft."
3. After connecting by SSL, other co-workers/conspirators view and edit draft or attach comments for all to browse and update.
4. If server is owned by group, files are as secure as the passwords and OS. If a public/commercial server is used, drafts and connection IPs may be discovered and will persist on backups and logs.
Part of this article drives me nuts, and I see the same crap in /. comments all the time:
2. The data is often 'NSFW' (Not Safe For Work).
Why did he use the acronym if he defines it directly after use. The only reason he should do this is if he used 'NSFW' elsewhere in the article, which he does not. The writer should decide whether he feels this acronym is recognizable enough to use without a definition. If it is then use it, otherwise don't!
Fixed:
2. The data is often not safe for work.
nothing
E-mail will have been dead for close to a decade in 3 years. Yes, we all still use it. Yes, it is a primary form of communications for anything over 30 miles. And yes, the horse is dead but we'll still beat it.
I stopped using e-mail as my primary form of communications almost 7 years ago (about the time I started using SMS en masse, combined with instant messaging when available). For me, e-mail is no different than TV, radio and telephone -- all technologies that should have been replaced eons ago but for whatever reason have been held back from evolving.
I agree that e-mail is a terrible collaboration tool, but considering when it was "invented" and how few real iterations of change we've seen with in, I don't expect it to ever blossom into a truly useful tool for productivity. I would have to guess that while e-mail is more efficient than a fax or a letter, it is not a telephone replacement, nor is it a replacement for even a simple post-it note. The only collaboration-friendly element of e-mail is the idea that it leaves a log or an audit trail of exchanges, but it is missing all the other important elements for group-think or idea creation.
I believe the future of connecting everyone within a group to one another plus incorporating outside groups into the "conversation" will likely come out of a different technology than e-mail. I see great possibilities in RSS and XML as a platform for long term collaboration, and the Wiki idea is a step in the right direction. Combine both with a tagging feature and incorporate more than just text, and you have a mess of protocols that together can really make a difference for building and sharing ideas. Maybe a little slashdot-style user-modifiable open-view moderation, too. Before any protocol or format can be created that really is the end-all solution, we need the underlying platform to be finalized. We need the Net available all the time, everywhere, at low cost (commodity-priced) and at high speed. I believe that the EDGE/3G networks are getting us closer (I am typing over an EDGE-connected T-Mobile link now), but we're not there yet. When information can be accessed immediately, when notifications can become part of the data stream, and when the ability stream your thought into a final product with anyone else, I think we'll see that product that many of us are waiting for without knowing it.
I've given a lot of thought to collaboration tools of the future, and I know exactly what I want. I just know that even if I implemented it today, most of my workers, friends, co-writers and readers would not be able to mesh with the Wiki-XML-SMS-Slashdot-tagging tree with the speed that I would think is necessary to make that collaboration better than a simple whiteboard and a boardroom.
Another few months, maybe. A few years, for sure.
Overzealous spam filters. I've recently tried to send PDF and JPG files to some people, and failed. The recipients' ISP's filters blackholed either the attachments or the entire message. Nuts! .exe. Being able to tell Outlook "yes, I know what's at stake, show me the damn attachment anyway" would help.
Another intended recipient has a local spam filter that somehow checks the messages while still on the POP server. This takes bloody ages, causing the transfer to time out. Lather, rinse, repeat. As a result, he has to use a webmail client to receive large messages.
And then there's Outlook's inability to receive executables. Yes, I know viruses blah blah blah, but there are times when I've a legitimate reason to send someone an
When I phone someone, and there is a problem with their telephone or telephone system, I get an engaged tone or equivanent.
All I'm asking is if I send someone an email, and they don't receive it for whatever reason, I know about it. An engaged tone for email, if you like. And no, the email system does not do this.
I guess that solves the first problem.
No it doesn't. Emails do not get through and sometimes no notification is given. I don't care why this happens, but it does. and that, quite frankly, is rubbish.
Why do you guys always rush to the defense of email. It's a crappy system.
And watch your SPAM levels increase exponentially as it's instantly confirmed that your address is valid. This is the kind of address verification that email harvesters/list sellers would kill for.
And watch your SPAM levels increase exponentially as it's instantly confirmed that your address is valid. This is the kind of address verification that email harvesters/list sellers would kill for.
Unless of course I could approve notifications, i.e. if a message comes from an address that isn't already in my address book I can choose to accept messages from that address or not.
Oh, wait, they have! MIT makes it and uses it on their own servers and clients! Did we win? Yay!
There is more:
Apparently, the author never heard of SMTPTLS, which, incidentally, GMAIL has implemented.Now, not may mail servers support TLS, but to say that there is no encryption is wrong. I can send and receive emails to gmail and it is encrypted end-to-end from my home network to gmail.
I would argue that the problem with GMAIL is that only the sign-on is encrypted. I don't think anything that is displayed on the screen is encrypted.
The real "Libtards" are the Libertarians!
Use registered post. Seriously. IP itself is unreliable. The Internet is reliable in the sense that the global network does not go down even if some sites (or backbones) do.
Modern email is pretty much reliable. What is not reliable is the "business" need driven content filters which cause mail to disappear.
SMTP is best effort, and that effort is very, very good. End users can make the best efforts of clued administrators fail.
Reject my email if you think it is spam. Don't filter it out, because then I have no feedback (and no, read receipts aren't acceptable).
I can throw myself at the ground, and miss.
You *only* get that accurately if both parties are in the same switching network. The same administrator has end to end control of the network.
If it crosses networks, no such guarantees exist. But, since a positive connection has an "immediate" result, it doesn't matter. Your "busy" or "no connect" signal may, however, be due to any number of reasons (not just that the other party cannot take your call now).
Email, though, is a step away from immediate results. It can be delivered though severly constrained channels, where immediate communication is impossible.
In other words, use the phone (or IM) for immediate communications, with direct connection feedback. Use email for deferred communication. If you need deferral with a "delivery guarantee", use a common server (tools like wiki, or lotus notes).
Ratboy.
Just another "Cubible(sic) Joe" 2 17 3061
When I worked at Unisys, we had it with OFISLink (a mainframe-based corporate e-mail system), and they took it away and replaced it with internet mail.
When I worked at NWA, we had it with PROFS/OV (a mainframe-based corporate e-mail system), and they took it away and replaced it with internet mail.
Whose fault is the current situation again?
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
1. "If you are using SMTP (the universal pipe, remember?), you need to know that it doesn't encrypt data/messages. If you are using POP or IMAP, you need to know that they both require you to send unencrypted authentication (username/password)."
None of these is true. Encrypted SMTP, POP and IMAP all exist and we've been using encrypted POP/IMAP where I work for over two years now.
2. In the discussion of encrypted e-mail, he jumps straight into certificates with no acknowledgement or apparently even clue that PGP/etc. exist and are a lot simpler to set up and use (even in Outlook, or even manually if you have to).
3. "Eudora Security Flashback: I still don't know what the hell Kerberos is and what it has to do with a dog much less my email?"
Considering that this guy is, judging from the content of his post, very Microsoft-centered, for him to not know what Kerberos is suggests he is not even close to any kind of expertise in the field.
4. "Most companies spend a fortune locking down their IT infrastructure. This results in either Total Lockdown, also known as Paralysis whereby no one can do anything without a password, passkey, keycard, signature and sign-in sheet; or in No Lockdown, also known as Free-Love-Utopia whereby everyone is equal because everyone is an Administrator."
Um... no? He says "This results" as though these alternatives are the only two possible. This is probably just sloppy writing, but it still sticks out at me.
5. "If everyone used Outlook (70% of Central Desktop users use Outlook), then the ability to assign priority to each message would actually work. But we don't live in a Microsoft world (in spite of what many of you might think) and instead, we usually measure and weigh the importance of an email message by the number of people included in the carbon copy. This is highly subjective and fails to address the need to order and sort messages and task by importance."
I know from personal experience that Eudora among others had the capability to set and recognize a Priority or read-receipt header as long as 10 years ago. Priority fell out of favor because of abuse by spammers, but it does exist. And that was valid for any message sent to or from anyone on the Internet. Can we trust Outlook's read-receipt and priority flags to be as portable?
6. "Its still challenging for multiple people to share business email accounts (i.e. support, bugs and sales messages). IMAP sort of works, but presents its fair-share of limitations."
Such as? How could IMAP be better? Given the inherent needs and limits of sharing what is essentially a file folder, I think IMAP is designed about as well as it can be. There could be improvements, but nothing I can think of that would make me go "wow! It's a whole different IMAP!"
7. "Email is Prone to Viruses - There is no need to elaborate here."
Yes there is, because (say it with me!) E-MAIL IS NOT PRONE TO VIRUSES. E-MAIL CLIENTS ARE.
There are some good points in this article, but you have to filter them out from the sophistry.
-- Old Man Kensey
I'm going to be starting on a spare-time open source project pretty soon and was wondering what people recommend for collaboration. The biggest project I worked on was the jboss portal server(previous version) and communication to developers(non-jboss employed at least) seemed to be mostly by email and forums. It was a little hard to know for sure if someone else was working on the same thing as me until a cvs commit. All the jboss guys I delt with were really helpful, but because of some of the reasons outlined in the article I kind of always wanted a better way...
Thankfully the new project I'll be working will have 2 main developers in the same city so we'll actually have some sit down sessions but so far almost everything is in email. What are good collaboration practices(the article mostly just said email sucks)? For software I'm currently investigating gforge with the wiki plugin. Does the slashdot community like wikis for collaboration between developers on software development projects or something else? Does all this really get solved when you have a dedicated project manager? Should your collaboration tool also be your project management tool? Any good project management tools(esp. ones that combine collaboration software). Thanks!
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
In fact, SMTP offers a number of secure alternatives, included TLS within an otherwise unencrypted pipe, or SMTP/SSL on port 463. POP and IMAP both support TLS for 110/143, as well as POP3S/IMAP4S over 995/993, and have not required plain-text login since the introduction of capabilities negotiation more than a decade ago -- both of them support a version of the AUTH verb. (To give you a sense of time, the relevant RFC's were published before Netscape developed SSL v1, back when sending creds over the wire in clear text was completely standard.)
The guy's trying to sell something, but it would help if he could sell things without lying about them.
Excuses.
All I want is a little red dot next to emails in my sent folder that weren't received by the recipient. I don't think that's impossible. It may be difficult. It may not be to do using the current way email works.
But we'll have it one day and it would be better if it was the OSS community that provided an open way to do this.
You obviously don't know anything about email, do you? Thunderbird and Outlook are just mail clients. The mail routing, mail storage and so on is done by mail servers. You can have the best mail client in the world, but if some administrator misconfigured his mail server, you can't do anything about that.
I was working as an IT Manager for years and you won't believe me, how often users came to me and asked me what happened to the email they sent around the world or they were expecting a reply to a mail and haven't received it. 99 per cent of the time I had to explain that the world doesn't consist of only our own mail servers.
Most of the time the "problem" was the user. Misspelled mail addresses and ignoring the error notification and so on.
That already exists - read receipts. I always refuse them because I find them annoying.
Whose fault is the current situation again?
I'm not blaming anyone for anything. I think the OSS community rocks. It's just this particular problem is waiting for a solution, and nobody seems to be trying to find it.
Thunderbird would spread like wildfire if it could do secure, guaranteed (to arrive, or notification if not) email.
It can. For many people, it does. Also, you're confusing a client issue (secure content) and an only partially client issue (secure delivery) with pure server issues (guaranteed delivery) which the client should not and in fact cannot address. And that issue is solved anyway, in SMTP, for what, 30-some years now?
-- Old Man Kensey
That already exists - read receipts.
No, read receipts are not the same. That is for an individual email. I'm talking about the person it comes from, not the email.
And yes, they are extremely annoying.
Kerberos is an authentication protocol; it only allows hosts on a network to reliably determine one another's identity. It can't (by itself) prevent snooping if the message, or to prevent alteration of a message in transit. The only thing(s) that could reliably prevent snooping would be message level encryption/signatures.
Use registered post.
what kind of an answer is that?
I have posted this plea for better email numerous times on Slashdot and all I ever get is a bunch of responses full of excuses for the current system or reasons why it is not possible or is too difficult.
All I want is a little red dot next to a sent message if it has not been received (or if the system can't tell if it's been received). Yes, I know that there are all kinds of reasons why with the current way email works doing this is problematic. But that's the whole problem. Come on guys, why all the negativity about this subject?
Most senders I've received E-mails from assume I received and read the mail within 5 minutes of their sending it. Scheduling a meeting for 20 min after sending the mail notification is rediculous, or sending it right at the end of the workday (or later) and assuming I'm so eager to read it I access my work E-mail from home. If its that important PHONE ME! Just because you sit all day at your desk with your E-mail open doesn't mean I do, two way communication is the only way to confirm a message is received.
Sounds like delivery / read receipts to me, and they've been around for a long time. Some people turn them off. Some clients will return the receipts if the requestor is in the address book.
See - once you add the "if I can approve" it bit, you necessarily forego the "guaranteed" aspect. Hence the problem with receipts. Your request would be to simply re-invent this wheel.
Winston Churchill once said "Democracy is the worst form of government except all the others that have been tried." You could say the same thing about email as a collaboration tool -- it sucks, but for the average user it sucks less than every other option.
None of these objections are so large that they can't be overcome; many people use the tools above successfully. But for the average user, who accepts defaults and isn't interested in learning a new skill just to organize a meeting, they all have flaws that outweigh the flaws of e-mail.
I hate collaboration-by-email as much as the next guy, but until we can come up with something that is an order of magnitude better for the average user right out of the box, we shouldn't be surprised if they keep shooting e-mails around. (sigh)
Read my blog.
The grass is only greener, if you don't take care of your own lawn.
As a business user I need something that has guaranteed, secure delivery. I don't care how it is done, but that's what I need.
Because you don't know how it's done you will not understand the explanation of why that is not possible in this universe.
Perhaps what we need are business users who understand that the universe contains no guarantees and how to deal with that simple fact. Might I suggest the use of return reciepts? That's how they do it with snailmail too. It at least gives you some knowledge of the delivery status.
KFG
Why do you guys always rush to the defense of email. It's a crappy system.
Email is a great system with a few flaws. Gauranteed delivery is not one of them.
Virtually all email programs will let you request a recieved receipt, and that's about as good as you're going to get. You could probably also find an addon that will notify you by sending an image or other HTML element that tracks back to a server that will send you a reciept. I'm sure someone will sell you that solution, too (or give it to you free if you look for it).
But the recipient has no obligation to implement either of those, and in some cases can not.
The bottom line is that if you want guaranteed delivery, email probably will never be your solution.
I do wonder why you sound so bitter about it, though. Is there some specific problem you've been having? My email always does get delivered, and in the odd cases it does not, I get a bounce.
It doesn't have to be like this. My mother runs a counseling service and I installed gpg and a plugin for SquirrelMail - and now my mother, my father, and yes, my grandmother can easily send encrypted mail back and forth. And we have to, if we want to discuss clients over email and stay HIPAA compliant.
Sysadmins, install gpg on your servers, and let everyone set up a key pair! It's ridiculously easy these days to install basic cryptography into email now. Thunderbird even has great plugins.
Did you ever notice that *nix doesn't even cover Linux?
Email is like the weather, everyone complains about it, but no one does anything about it.
Too right! Just read all the other responses in this thread. It makes me depressed.
One day someone will come out with a better messaging solution and it will take off like wildfire. But if Slashdotter are representative of the OSS community then it looks like it is unlikely to come from the OSS community.
hmm. what exactly are excuses ?
as i saw, ratboy stated that this can not be guaranteed unless all participants comply with common rules or all links are controlled by a single entity.
if all links in an email-processing chain (your mail client -> your computer -> your server -> some other mailserver -> other computer -> other mail client) are working as they should, the message simply will be delivered.
now, wether it will be read... no, read notifications is not a good idea.
generally mail system is supposed to notificate you whenever there is a problem delivering the message - wether it would be unaccessible recipient server, incorrect recipient address, unaccepted content or whatever.
it will usually do this by sending you an email message stating that the message was not delivered and telling you why. in some cases you might get notified immediately, if your server can find a problem while your mail client is talking to it.
once the message has left your mailserver, it's completely the responsibility of other server[s] to inform you as a sender about any problems that result in inability to deliver the message to the final recipient.
phone conversation isn't exactly a good analogy as it's a two-way interactive communication. unless you propose one mail client talking to another, there always will be intermediate servers that will pass the mail, check it for viruses etc.
if you ever get unreliable mail delivery (meaning mail is getting simply lost), that SHOULD NOT HAPPEN. really. contact your administrator, together with him try to find the cause for it. once it is found (you might have to contact destination/sending party), push for it to be resolved.
now, the only case i can think of missing mail (that is not because of some massive network or infrastructure outages that you should be noticing anyway) is spam filters. yes, spam filters that discard messages can cause this, but anyway are controlled by one of the sending/receiving party, thus finding which has snapped the mail and preventing that from happening should be done as soon as possible. and the message itself still must be possible to retrieve from the spamfilter if, for example, it's your organisation's infrastructure that has classified the message incorrectly.
other approach is flagging all the mail and letting it to fall in a separate mailfolder at user's client. that is easy to do with current tools and probably is the best thing to do at your organisation if losing email can be critical and users are sophisticated enough to find the occasional filtered away message (and they have the possibility to set individual thresholds so that one would have more manual spam-hunting to do, other would cope with a mail getting classified incorrectly now and then).
Rich
Maybe the programmers figured the people wanted to read the mail once it got delivered...
May contain traces of nut.
Made from the freshest electrons.
I do wonder why you sound so bitter about it, though.
I find the attitude of the OSS community depressing about this subject. They are too close to the technology and can't see the flaws in it.
Dear Business Community,
We in the OSS Community understand that you have needs. We have needs too, so it isn't difficult to empathize. We see that you desire custom email client/server software. Well, that will be very easy to achieve. I can in fact give you a great example of how to make this happen for you. Do what I did! It's really simple and requires no special training or even education. What you do is you go to your favorite bookstore (remember to support your locally owned businesses, they like you, are the backbone of your community) and purchase a book on how to program. That's what I did, and it worked great! I started with just one manual, and I was well on my way to having the custom designed audio synthesis software I'd always dreamed about.
Or, you could hire a programmer to do it for you, but you'd lose the rich and fulfilling experience of "pulling yourself up by your bootstraps". Remember, if you're a lazy bastard who expects other people to do things for them out of the goodness of their hearts when you don't even ask nicely, the terrorizorists win.
P.S. If you'd asked instead of insulted, perhaps someone would have pointed you to some OSS that already does what you ask.
P.P.S. Instead, you had to be an asshat.
Say bad words about my book, in cold oatmeal, or I shall sue!
A pretty decent solution already existed. It's just that folks went with the bandwagon instead of sticking with technology that worked.
That might not be true in smaller organizations, but it certainly was in those two. The mail servers they replaced PROFS with at NWA were a huge step backwards, IMO.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
what oss has to do this at all ?
silent loss of a legitimate email is a technical problem. solve it, or find somebody who is responsible for your email system. it can be opensource or proprietary, that doesn't matter much as communication protocols are open.
if you have a problem with your car, you probably find somebody who knows how to fic it or fix it yourself. you don't go around crying that cars are bad.
losing emails is not supposed to happen in current email system, so i don't see the point in blaming it as broken in this context.
Rich
Print out the email, and deliver it in person.
That is not a solution to the problem stated.
That's the only way you would be certain that it arrived and that no one changed the message.
Because this end is not the desired goal. This end is knowledge of the delivery status, not guaranteed delivery. The two are rather different.
What he is really asking for is the right to assume delivery, a priori, without evidence of such, but life is, like it or not, uncertain. He might slip and break his neck on his way to hand delivering his message. The people who do best in this world are those who develop viable strategies for coping with things going wrong.
If this life is causing you to drink
Sittin' 'round what's the use what to think
Well I've got some consolation
Give it to you if I might
I don't worry 'bout a thing, becuase. . .
Nothin's goin' to turn out right
- Mose Allison
KFG
Why is BCC so bad? Because someone else makes a unilateral decision to make you a *secret* recipient of an email. I never know if it's ok to acknowledge that I got to email or do I have to play dumb if one of the *real* recipients talks to me about it.
Always be polite.
Unfortunately SMTP as a protocol is not designed to operate in this way. Email works on the basis of a store and forward system, such that your email may flow through a number of servers to get to its destination. Each of these servers may accept the email without knowing whether the final destination is valid, and then become responsible for forwarding it on to the next hop. There is no direct connection from your computer to the final destination, and no way of signalling the transit of the email, other than sending an email back to you. This used to be done by default in the way of "bounce messages" "Non delivery reports" and "timeout messages". Because of the volume of spam using forged sender information (as sender information is not authenticated in standard SMTP), these are usually turned off, as otherwise you suddenly find your email inundated with thousands of bounces and NDR's etc when someone uses your domain to spam from.
"Use a new protocol then" is usually the response here, but that is unlikely given the number of existing, working, SMTP installation. If spam is defeated, however, maybe you will find NDR's etc being used again. So, in summary, SMTP already does this, but it's disabled because of people misusing a system that was designed when people were trusted not to abuse it.
silent loss of a legitimate email...
The system should be designed so that emails can never be silently lost. If an message doesn't get through because there's a problem with the recipients system, then I want to know about it. The fact that emails can be silently lost is a major flaw in its design.
The OSS community could come up with a better solution, but it seems that they would prefer to defend an imperfect system.
well, maybe the problem is that you are not listening or trying to understand ?
let's try this again...
current email system technically provides everything you wanted (though maybe not in the exact ui style you requested).
legitimate email is not supposed to vanish without a trace. if it does, bug somebody who could help you to find the cause and eliminate it. if all you do is whine on slashdot that the system itself is broken (which isn't), don't wonder that people will be telling you how it really is.
Rich
Other then DNS checks, or RBL lists...there is no effective way of providing proof that your mail server is who it is. Most sys admins and ISP's absolutely refuse to enforce these rules. So spam is a huge reason it's not good collaboration practice.
I filter mail for several large businesses, including my work place. When discussing a blocked mail marked for them...they make it sound like you are breaking into thier bank account and stealing revenue directly from their business. Get real people.
Email isn't a form of dependable communication in a business environment. It's only effective about 98% of the time. PICK UP THE PHONE AND CALL...Geez. Email is a great form of communication when you are enforcing the effectiveness of a phone call (meeting notes, etc.)
It'll never happen with the current philosophy of email, that's too much information given away to a remote system, it's an invasion of privacy. You have to have the cooperation of the receiving system and I, for one, won't ever give that to you on my mail servers.
You need to come up with a new protocol that allows for immediate delivery and a backwards flow of delivery information. Something like... hmmmm... I don't know, maybe IM! Which someone already suggested!
It already exists, use it.
Besides, just because it got delivered to the remote server doesn't mean it didn't get lost somewhere on that server, or the disk didn't die and lose all the mail, or the server didn't catch on fire, or the recipient didn't delete it without reading it, or die in a car accident before they got to work. You think you're being clever, but you're not.
09F911029D74E35BD84156C5635688C0
Jesus loves you, I think you suck
oh, gawd. the moderation has gotten you right this time.
;)
take a hammer and "print" this on your wall :
"Misspelled mail addresses and ignoring the error notification and so on."
re-read it every day. once you can grasp it, try to come up with a list of problems you see in current technical implementation and NOT come up with some problems you have experienced and "don't care why they happened".
i've got to go now so, please, stop this, ok ?
Rich
Too true. It isn't your responsibility to secure others' networks, but that isn't the issue. The issue is, if you can't secure the process totally, it isn't secure. So your users, although you have done your job, are still exposed later in the process.
Of course, I have no ready alternatives to offer up. The tech community is pretty good at finding holes in any system. :)
An important change for education.
I'm a developer, but I actually agree with you about the excuses thing. It would, howveer, require everyone to cooperate on the protocol, so it's not something the community could implement unilaterally (ie it would only work if every link in the chain conformed).
Not an email expert but I think this problem is simply (if not easily) solvable by requiring a positive confirmation from each mail server, with a final confirmation when the recipient client "pulls" it, upon which the confirmation signal would follow the return chain back to the sender. This would require every conforming mail server to keep a log of all "open transactions", which would probably get very sizable for high-traffic servers and/or with delays.
geez. try citing (and reading) it a little further, will you ?
cars are not supposed to lose a wheel when driving. they are not supposed to develop cracks in a windshield without a visible reason. shit happens, and _when_ it happens, it must be resolved.
currently you are arguing that a perfect and never failing system must be created, not that failures which usually happen because of human error (be it user or some administrator) should be analysed & eliminated.
current system does not lose mail just like that. why don't you pursue each case when a mail is lost, find a reason, push to get it solved if that is a technical problem - and THEN come up with a list of global problems you can find ? i'm sure you will come up with one and that will be human errors or incompetence on system administrators' part.
Rich
And there are several, was that people should have never been allowed to save a document in their perspective mailboxes. Any documents should have been automatically saved in some form of folder on a file server.
If the notification of reception is automatic and mandatory then SPAM can easily authenticate addresses. If notification relies on the user to authorize, then it cannot be reliable. Even if you ignore the SPAM problem, you can't determine if a user _READ_ the email, only that their client displayed it. If I am clicking delete, delete, delete to get rid of email, I may not notice that _your_ email flashed up onto the screen in the middle.
Even registered US mail only tells you that I signed for the envelope, it doesn't tell you I read it. It could have got sat on the entry table with the rest of the junk mail and tossed out by my wife.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
Ironically, Apple sends out emails tagged appropriately as Low Priority. I get my ADC emails in Outlook with the blue down arrow :-)
If you need collaboration use a web forum. If you need collaboaration on content creation use a wiki.
Mail is for personal exchanges and is very primitive.Instant messaging/IRC/webchat already
outdoes it by a wide margin.
Only sites that insist on registration
require email adresses for verification,
or mere formality.Email is a thing of the past along with usenet.It will eventually be superseded by something like webmail integrated into forum or chat(private messages on forums already exhibit similar features,though they are different and lack several features of email,adressing schemes being one of them ).
some future Metaforum with various integrated tools,will provide all services of the web(webpages(with separate format then threads),forum,p2p integration(a tracker),inter-forum mail(by a agrred upon scheme),web chat(a feature reduced,realtime text channell/thread),calendar,file database,and content management features(wiki,cvs,sql)).
You are describing read reciepts + the assumption that all email is lost until a reciept is recieved.
It's a good thing I don't have any karma to speak of, because I'm sure I'm about to burn a bit, but...
"The only thing worse than one walled garden are many walled gardens."
Why do people do things like this? It's confusing. And it's not hard to get it right. Didn't the author read this out loud before publishing it to tens or hundreds of thousands of people? It's not tricky, guy. The subject is 'thing'. 'Thing' is singular. So your verb also needs to be singular (is). How do you fuck this up?
Unpleasantries.
So to summarize the point you seem to have missed: what you are saying isn't the fault of the protocol (SMTP), any mail server (postfix, sendmail), or any of the free clients (pine, mutt, Evolution).
In any of these, this doesn't happen. The *protocol* is not connectionless. When one mail server contacts another, the conversation is something like this:
Server 1: Are you a mail server?
Server 2: Yes.
Server 1: I have a message for userX@yoursystem.com. Take it and deliver it.
(One of these three, usually):
Server 2: I have no userX@yoursystem.com.
Server 2: I can't deliver it because "X". (Presumably X is to be reported back to the client).
Server 2: I've delivered the message
If *at any point* either of these exchanges fail, then both of the servers should know about it. Server #1 is responsible for reporting this information so that you know that the message was delivered. The only way these can fail is that one of them isn't doing it's job, and saying that it does.
Do you blame the internet itself if your cable modem stops working? Why should you blame the e-mail system if your server isn't doing what it's supposed to do to obey the protocol?
Mod me down and I will become more powerful than you can possibly imagine!
I think the issue is mostly how people use email in collaboration situations, not the actual technology. This fact pretty much dooms other technologies to be no better; even people using the ideal collaboration software can (and will) sometimes send a personal email instead of using the tool.
The solution is to train people in using the tool. On the linux-kernel mailing list, the policy is that you cc the list on any reply to a message on a list, and cc all recipients. If you violate this rule, people complain. This means that the whole discussion is archived and publicly searchable. It also means that everybody participating in the discussion gets a copy addressed to them of each message, and doesn't have to try to find messages that are part of the discussion in the huge volume of mailing list traffic.
The whole point of the exercise is for thousands of people to edit a huge document (the kernel source) at the same time, and most of the changes go through email to the list, too. Here, the policy is to cc anyone who is likely interested (like the appropriate maintainer, if you want the change to actually stick).
Of course, this requires people to set up their email appropriately; you ideally want to get your direct copies of messages in your inbox and all of the mailing list mail filtered out. But anyone on linux-kernel pretty much has to have their email set up cleverly, because the traffic is too high to deal with directly (I think the non-spam on there is higher traffic than most people's spam before filtering).
About the only thing that would make it better would be if there was a URI scheme for message IDs, supported both by mail readers (which would take you to the message in that folder) and web browsers (which would take you to an online list archive you've chosen). Currently, it's a bit awkward to refer someone to an old message; what people do is use the URL for their favorite web archive, but that isn't convenient for responding by quoting portions of it, or if the recipient happens to hate the sender's favorite archive, or if recipients want to know if they've received it before.
Of course, they're also a lot of hidden stuff: source code is a whole lot easier to do concurrent modifications on than office documents, because of tools like diff and patch and the use of filesystem structure within the document, as well as the compiler's support in cross-referencing things. So the collaborative editing task is a whole lot easier than word processing, which is stuck in the early 70s.
Steve Ballmer is CTO of Microsoft because it' is Microsoft. Somebody's got to take responsibility of becoming flop of Windows Vista... ;)
-Seeing the problem is ½ of solution-
Email is and should be recoginized and used for what it is, "Electronic Mail". Not "URGENT NEEDS A REPLY INSTANTLY"... NO! I do not check my email every five minutes, once or twice per day.
If you need an instant reply, how about use something like "Instant Messaging", VOIP, a phone call, or come over in person?
I really hate people who expect email to be almost the same thing as instant messaging. Email is a lower priority messaging system, it should not be used for something that you need an instant reply to.
The system should be designed so that emails can never be silently lost.
/dev/null. Once /dev/null reads the contents of the e-mail, it is read as far as the software is concerned. You'll think I read the e-mail while I'm blissfully unaware that you ever sent it. Redesign e-mail all you want, but it's impossible to guarantee that any form of computer information exchange happens successfully when you aren't in control of the receiving end.
Care to share exactly how you would ensure that is true? It can't be solved at the protocol level, the receiving end could make a mistake, or simply lie.
What if the admin accidently pointed my mailbox to
Yes it's annoying having to guess if your e-mail made it or not, but this problem can only truly be solved socially.
Most of the problems mentioned in the article are overcome by using "Reply to All" -- which is how e-mail collaboration has always worked in my experience. The only one I see it not solving are the security concerns, which can be overcome with authenticated SMTP and IMAP.
Saying email is broken is like saying your screwdriver is broken because it won't drive nails into wood. The real problem is most people are stupid, and don't know how to select the right tool for the job. Since you seem to advocate that the phone is better than email, I submit that you are one of those people.
Like many people on Slashdot, I work in a team of people. (Well, actually, I work in a couple different teams of people.) If I need to communicate with someone else, sometimes email is the right thing to do. Sometimes a phone call is the right thing to do. Sometimes it's best to walk down the hall and bang on their office door. I do some of each every single day.
The biggest problem with phone calls or face-to-face meetings is that you are taking up a significant chunk of the other person's time and not allowing them to pick when that time is. If I need somebody to up a software rev on a system, or I need them to review a spec, or look at and comment on some code, there is no reason to waste 5-10 minutes of their time communicating this vocally when they can get the same information in a few seconds reading an email.
The 2nd biggest problem with phone calls and face-to-face meetings is you can't have them if the other person isn't available. Maybe they went to lunch. Maybe they have another phone call. Maybe they don't wear deodorant. Email allows asynchronous, ageographical communication, and that's important.
Which brings us to the bane of my existence: Voicemail. Any organization that has email service should get rid of their voicemail service for internal communication. Voicemail takes longer to get, it takes longer to listen to, and doesn't do anything for you that email doesn't.
paintball
Do we really need an article to tell us that email is a poor collaboration tool?
No.
What's with all the useless articles on here these days. Makes me wanna just troll because I am so bored here otherwise.
Install COX in your backend today!
Slashdot is the best place to collaborate.
The server is always up.
Comments are never deleted.
Good ideas are moderated up.
And perfect strangers can contribute.
It's not for the NSA to use for collaboration, but it does save them time when others use Slashdot instead of email.
Oh You POS
My initial theory on the summary was that it was trying to suggest that Steve Ballmer was CEO in name but CTO in action, but I don't know why anyone would want to suggest that.
Email is like the weather, everyone complains about it, but no one does anything about it.
And even if someone did, noone would switch over to use it.
There's no place like ~/
IMHO a simple improvement to email would be no more than twice a day delivery.
Let me guess. You have stock in fax machine manufacturer?
Things sent with "High Priority" are almost always sent by an admin and are almost always about some silly bureaucratic thing. Why anyone things corporate goobledegook is important is beyond my understanding. Some exampels:
-Everyone needs to take silly class to infuse us with some sort of "corporate culture".
-It could be abot quarterly meeting where they tell us how well the company is doing. These meeting are so filled with spin as to be uniformative.
The following things are sent with normal importance:
-Customer X is having failures with our product and will stop buying if we do not fix it.
-If we change Y in the manufacturing process we can easily improve yields by x% and save a few million dollars per year.
A modest proposal. Let e-mail readers vote on if the "important" emails are important. If they are not important, the first several readers can "mod them down".
Religion is the main cause of atheism.
Email is a best effort much like USPS. You could always try certified post, certified courier, singing telegram, or just hand deliver it yourself, but none of those garauntee that your message will get to its intended recipient.
The biggest flaw with current email is SPAM. The solution to fixing SPAM is not primarily a technical one. Mostly, it is a social, legal and economic one. A primarily legal means poses to many limitations on my freedoms; I have too little faith to expect social constraints to fix the SPAM problem; and most economic solutions are not viable as well. Come up with a solution to SPAM and the issues with email just disappearing go away.
The security thing is easy, use GPG/PGP.
Just a Tuna in the Sea of Life
The fact of the matter is that emails that many people suffer a lot of problems with emails, from my old ma to the CEOs of large companies. The current email system is flawed. Telling me that it's perfect or that it already does everything that everyone want is just frankly rubbish. The reason I find this subject so annoying is that one day there will be a better messaging system than email, but it looks like it's not going to come from the OSS community.
.... uh .... I never got the email. Yeah." People lie. Deal with it-- it's not the email protocol's fault, nor is it the protocol's job to police it.
OK, here's where I think you are confused; perhaps no one has taken the time to explain things to you without getting too technical.
There are three* types of "undelivered" email, that would all get your mythical red dot, if I understand you correctly:
1. Email that was sent to an invalid address. A user sends an email to joe.m.bloe@company.com, except that he meant to send it to joe.t.bloe@company.com. In this case, the company.com mail server will "bounce" the email: the sender will get an email message saying, essentially, "I cannot deliver this message because there is no user named joe.m.bloe." If this bounce response is not sent, it is the fault of the administrator, not of the email protocol.
2. Email that has not yet been read. Some people might consider this "undelivered", although the server considers it delivered because it made it to the right mailbox. What happens after that is the responsibility of the recipient. If you simply HAVE to know when your message is read, then attach a read receipt, which is built right into the protocol. (Please note: most people don't like being spied on, and will not send a receipt when asked by the email client.)
3. Email that simply goes missing. This breaks down further into two categories:
a. Filtered email. The administrator of an email server can choose to filter mail, either to take out spam, curb inappropriate content, do virus checking, or whatever. False positives in this situation (non-spam email that was filtered and deleted) are the fault of the administrator/spam-blocker, not of the email protocol. The sender should be notified if a message he sent was filtered.
b. "Lost" email. "Oh, the reason why that report isn't finished yet is because
So the reason why most people on Slashdot aren't taking to your idea is that the current system can handle all the various contingencies that might come up. If your emails really are just disappearing without a trace (and you're sure no one is lying about it) then you need to have a serious talk with your administrator about what can be done, because there is something wrong with your company's mail system.
Many email servers are poorly administrated, it's true. But no amount of coding by the OSS community will fix that. It's not a technical problem at that point; it's a social one. The current protocol contains everything necessary to "guarantee" mail delivery, if such a thing is possible when humans are part of the system.
On the other hand, if you're just looking for an email client that will place a red dot next to an email conversation that received an Undeliverable Bounce from the server, then you might want to go suggest that feature to the Thunderbird people.
----------
*There is a fourth category--where an email was not forwarded on by one of the middleman servers between point A and point B--but given the generally robust nature of the internet, unless you are using some shady email server that might flake out at any moment (again, the fault of the administrator) or sending your email through shady proxies, the chances of this happening are so very slim as to be completely negligible.
For security, the MD5 hash of this message and sig is 09f911029d74e35bd84156c5635688c0.
I guess your company must not have as smart of management as mine does, because my managers solved this problem years ago:
This space intentionally left blank.
I don't agree with the troll moderation, and I can't find an answer I like to this question so far in the responses, so let me give this a try:
... I guess it wasn't that important, was it?
Unlike phone systems or paper mail systems, which have comprehensive international-body and governmental regulations to follow, email is a voluntary system specifically designed to work as well as it can in an imperfect and heterogeneous network of networks. What rules that email clients and servers do follow are technical specifications written as early as 1982 -- before business uses of the Internet were even allowed.
So there is no one who *can* make any delivery guarantees, as there is no central control of the system. Also, there are people who like the fact that there isn't central control, and attempts to create a central control would lead to the balkanization of email (like the current system with IM).
There were (and in a way, still are -- Exchange, Notes/Groups) competing email systems, but they were burdened by commercial licenses and the inability to easily transmit messages between systems. Regular Internet email won (in part) because it provided a universal (and licensing free) way to send and receive email messages -- not because it was the system with the best features.
From here, change would be very difficult.
If someone created another commercial/governmental system for email I think it would be doomed, unless the developer managed to make SMTP email illegal in a good percentage of developed countries.
To change Internet email to add the feature of "guaranteed, secure delivery" the feature would either have to be backwards compatible with every existing Internet email client and server (which means the feature wouldn't work) or you would have to convince *everybody* to move to new clients and servers -- good luck on that.
Certainly email has and will continue to evolve, but to go on about your status as a "business user" (who isn't, these day?) isn't likely to be very productive.
In the mean time, go head with the faxes and certified letters -- and if what you are sending isn't important enough for that, well
-- I browse at +5 with stripped sigs
If the e-mail server correctly conforms to SMTP it will be impossible to lose e-mail unless
/dev/null
a) the server has been misconfigured e.g. it delivers your mail to
b) the server suffers some catastrophic failure while the e-mail is queued on it e.g. hard disk failure.
Neither of these issues is limited to open source software. SMTP itself has nothing to do with open source. Even Microsoft implements it.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
But back to my main reason for liking email: accountability. A number of decisions I make for the two departments I manage, I get guidance from my legal counsel so if anything goes wrong and I get asked by the executive team what happened and whether I did my due diligence, I can go back to my email trail and show them that I consulted legal, brought up certain issues with executives. My having this has covered my rear end time and time again. To the point where if I am being asked to make a decision on an issue, I want it in email so that everthing is laid out and if anything goes wrong, I am 100% covered.
IMHO a simple improvement to email would be no more than twice a day delivery.
It is better to set the urgency of delivery T measured in time units by specifying when do you expect to get an answer.
* If T exceeds threshold Th1, then e-mail is send at night.
* If T is below threshold Th2, then e-mail is sent immediately.
* If T is between these thresholds, it is sent in T/2 time units (not immediately).
Recipient should know the urgency.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
It talks about why email is bad and doesn't take into consideration the simple fact that email is good because it closely imitates reality. That is the reason for what he calls a 'walled garden'; email only puts in 0s and 1s the way people communicate.
While he has some valid points about such issues as email folders not being searchable, not being shared easily, not secure enough etc. his main argument seems to stay the same: the problem is that email makes us act in a bad, counter-productive way. My opinion is that this is where he is fundamentally wrong. It's all about that usability thingie, and usability is often about imitating what you would do in reality. Email is perhaps the most user-friendly service that Internet has, and thus is expected to be used by the people the way they would do similar things in reality.
And most people around us are not geeks; they don't think in terms of 'how online collaboration should work'. (Not even all geeks do, either.) They most often have a vague comprehension of the fact that data shared by everyone is much more valuable than data that somebody has in private. So until people actually feel the need for a better collaboration engine, until they understand why it's better and how it makes them, their groups and companies more efficient at their tasks, email will stay the information medium of choice.
I'm somewhat skeptical myself about the 40yos and 50yos being able to learn the new ways of handling information; it seems to me that at least a decade should pass before people en masse actually realize what email can and what email cannot do and move on to better collaboration tools, such as forums/wikis/whatnot. Until then, there's only so much we can do: work on the Web 2.0 and patiently wait until somebody puts the new toys to serious use and hopefully proves their efficiency. From that point on, as money starts talking, things get moving...
Myself, with my projects I make heavy use of both the intranet forums and the IRC. I don't put much trust in IMs because they suffers from pretty much the same problems as e-mail does. However, only the young and open-minded are feeling themselves comfortable in this environment; even 30yos often have problems communicating online and there is almost no hope for those on the wrong side of 40 to adapt. Oh well.
I think this article misses the point of email entirely. Email is good for sending a message from one place to another. I don't think the originators of email saw it as a document management tool, a revision manager or any of the other hundred things people try to jam into it. It's amazing what people've been able to do with such a simple set of protocols, but it's kind of like complaining that your car doesn't make a good hot dog stand. Sure, you can sell hotdogs from it, and you can put buns in the glove compartment or paint it cool colors or advertise on it, but at the end of the day, it's a thing that gets you from point a to b.
Blaming Microsoft because they've added things to make it possible to collaborate badly is just silly. They've just added a pink bun warmer to a honda civic. Extraneous and barely functional? Sure. Their fault this doesn't make it the perfect hot dog stand? Not really.
But it can be. I work for a company that develops a collaboration tool (amongs other stuff), and it uses a feature of Outlook that is sending an attachment by saving it into a SharePoint workspace (SharePoint is Microsoft's collaboration tool, they expect it to be a strong selling point of Office 2003 and beyond), that way every time someone opens it it's opened from the central workspace and edits are seen by everyone.
The collaboration tool we sell adds e-mail search and catalogation too.
So e-mail can potentially be adapted into a collaboration tool - I guess there must be an open source version of what I described hopefully.
There are three kinds of lies: lies, damned lies, and statistics.
SharePortal services?
The summary completely skimped on the best part of the article. The author cited a link when he mentioned how emails contain time wasting games!
legitimate email is not supposed to vanish without a trace.
There is no feature in the design of SMTP email to guarantee this.
if it does, bug somebody who could help you to find the cause and eliminate it.
There is no feature in the design of SMTP email to allow the user to know when to do this.
don't wonder that people will be telling you how it really is.
There is not feature in the design of Slashdot to encourage factually correct posts.
I find the attitude of the OSS community depressing about this subject. They are too close to the technology and can't see the flaws in it.
email is a very old and very entrenched system. The spec for it is really rather good. Your mail should always be delivered. If it isn't, you should always get get a bounce message.
But it is impossible to make everyone follow all the rules.
It's just like the regular mail system. Very very simple. Everyone agrees that mail should be sent, and should be delivered or returned - but that isn't how it always works out. The faults in the regular mail system are often similar to the faults in email: the local postmaster ignores/drops mail, the local postman discards the mail, there is a disaster that destroys mail in process, the destination address is scrambled/old/no longer valid - and so is the sender address. The list goes on and on.
I ran the same mail system on an 8086 running DOS, of all things, back in '88. And somewhere in the [3rd] world someone is still running it on similar hardware.
On the other hand, email is flexible enough to let you bolt any number of [partial] fixes onto it - and many have done so. But you can't expect all the bolted on stuff to work on that 8086, far away. Nor can you get everyone to adapt a new [revised] email system.
email isn't perfect, and there are a few things I would sure like to see it do much better (at all). But is really is quite good, and nearly impossible to change.
The alternative is to default to having acknowledgement on delivery, and assuming a lack of acknowledgement is affirmative evidence that the message was not delivered, but then you a) increase the traffic without providing a real benefit in most cases and b) still have false negatives where you get no acknowledgement (because of an act-of-God issue that prevents you from getting it) even though the message itself actually was delivered. I don't see how Thunderbird (or any other mail client or any mail server or protocol) is supposed to deal with issues like those that exist under its OSI communications layer.
SMTP has mechanisms to inform the sender about message rejection or failed delivery. They are pretty robust and I can't remember the last time I genuinely failed to receive a message that the sender just didn't get a bounce notice for. It's always been either I got it but overlooked it, they got a bounce but overlooked it, the sender didn't get the bounce because they misconfigured their e-mail client with an incorrect sender address, or I got it and fibbed to the sender.
You're trying to make a store-and-forward protocol do things a store-and-forward protocol just can't do. You'd have to make a point-to-point connection to every single recipient for every e-mail session to do what you want to do. (We have that, actually -- it's called VOIP, or any number of other client-to-client chat/messaging protocols.)
-- Old Man Kensey
I've just finished a university assignment with a classmate. We worked on http://www.jot.com/ where you can get a wiki. It was far easier than having emails flying between us, and easier than always trying to figure out which file was the latest. Instead, the latest work was on a private webpage, and I could see what she'd done since I last looked at it.
I used to do similar things, but then we got a corporate instant messenging system, and I think it's a much better solution for the problem you're describing.
I only very rarely use the system to actually send messages to anyone, but we all use it constantly to see who's around and available. (You can set it to available, away, or "don't bother me", which is a nice addition to the standard available/away. In the third case it suppresses all incoming messages.)
I don't find it intrusive, and it keeps people from dropping by my cube when I'm on the phone or otherwise occupied, assuming I've remembered to change my indicator appropriately.
Frankly I think you could really just make a buddy list program without the instant messaging features and retain about 90 percent of the usefulness, at least in my situation (everyone in the same physical office, mostly).
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Any organization that has email service should get rid of their voicemail service for internal communication. Voicemail takes longer to get, it takes longer to listen to, and doesn't do anything for you that email doesn't.
Thank you and Amen. I agree; the only thing that saves me from really, really hating voicemail (more than I have, since the advent of email), is that we now have a VM-to-email system that sends me voicemail messages as email attachments. It still requires me to waste my time listening to someone stammer away on the phone when I could have skimmed their message in a few seconds on my screen in text form, but it beats having to pick up the phone and spend several minutes navigating through the prompts to retrieve my messages.
I understand there are some valid reasons for still having voicemail (people can send you one from anywhere, etc.) but they're rapidly dwindling as the number of places you can send email from grows.
I guess the solution is not to eliminate it completely just yet, but really to impress upon people that it's a nonpreferred method of communication, and should only be used when absolutely necessary.
Personally, part of my voicemail message is a warning that I don't check the system very often and that email is my preferred method of communication for anything sensitive.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I wholeheartedly believe that online communities - be they social, technical, or business - are best served with tools that help build a sense of community. I believe there's a mostly forgotten but very effective tool - for several years now I've been part of a small MUD community. We're all technical people - some programmers, some not. None of us use the MUD for gameplaying, but rather for the social aspects. The ability to implement tools in code and give them physical characteristics through descriptions and interactive commands makes (eg. notes, loggers, rooms) adds another dimension to a space. Something that IRC, Instant Messaging, and certainly email lacks. The idea of being "present" with someone else in a room helps to develop personal relationships between participants. I've never had that with email or instant messaging, and have felt it with IRC, but it never lasts. Being able to exclude people from rooms, gag them, ignore them, or virtually stab them in the face and have them bleed for several hours are added benefits. The great "Web 2.0" collaboration doesn't quite meet expectations either, but it's aiming for something similar.
Larger communities even have types of Governments and democracy. A well managed MUD can cope with many thousands of people. Look at LambdaMOO.
A member of the MUD has used it as the primary point for collaborating development of a large software project, and it was quite effective. They didn't go so far as interfacing bug tracking (not that many developers & testers), but they could have.
I could see a MUD being used in a multinational organisation to enable easy group collaboration and bonding. When I was working for a multinational in Europe, the American guys didn't feel like part of my team, no matter how many conference calls we shared. I think being able to be part of their musings in a less formal atmosphere would've made a big difference.
The big problem with MUDs? If you're not careful, they can be time-wasters.
People communicate it's just a fact. by direct contact or by phone or by writing. If you think you cann't use email to colaborate then think again when the web was introduced java junk and asp fastfood came all over, money seeking people went to web services to write their own gadgets. For a great deal mimicing plain old conversations acka mail flow, the realy smart kids went back to their mail servers and wrote colaboration software on it. So at these environments you see a mail client open yeah.. only one app instead of having lot's of screens lots of databases lots of databases (out of sync) and all require a lot of IT overhead. The worse thing is just most people don't program against a mail server for workflow, because i think it requires a bit more knowledge, while creating a web page in a develpor environment is almost plain out of the box. Terrible because it result in hundred of company apps, which in large companies becomes a management nightmare.
I know you're out there. I can feel you now. I know that you're afraid. You're afraid of us. You're afraid of change.
"Where's the problem, again?"
Well, it might be when you have 5 business analysts. The scenario you use implies only one silo, which is fine but not universal.
Exchange is reasonable as a mail server, and particularly for laptop users using Outlook 2003, you have one of the best online/offline/webmail combinations out there. Very compelling for laptop users who are mobile often.
However, there is alot of movement against using Exchange as a document management or general purpose storage engine (ie, Public Folders).
The preferred setup is to use Sharepoint in combination with Exchange and Office 2003. And to be honest, Sharepoint does a pretty good job at this, allowing deeply delegated administration, WYSIWYG editing of pages, plus you can write custom web parts to run on top of it if you're so inclined.
And sharepoint is included with Windows 2003 Server, so you can just run it on the same machine as running your OWA for Exchange, and it wont cost you anything extra.
If you're willing to deploy the full MS stack its pretty compelling, and the integration amongst the parts is very nice.
There are also plenty of very reasonably priced consultants that will come in and do a one-time setup of Exchange plus Sharepoint, so that its well configured from the start. And at that point, the products are all very reliable, and pretty much just require the occasional patching (which windows will do for you if you want it to) and backups.
If your boss is committed to Exchange, and you arent religiously against an MS stack, take a look at Sharepoint in addition to Exchange.
- Administrators may (mis?)configure thier systems, and programmers may code to not return NDN / DSN.
- Administrators may configure thier systems, and programmers may code to lie about the delivery status of a message.
- Disks die, and when they do, they may (unknowingly to any software), take your carefully crafted email with it.
- Administrators may accidently (or intentionally) remove your mail from a queue before it can be delivered.
- The recipient may have configured his client to forward your message to another desination instead of storing it locally. Has such a message been truly delivered?
None of this is known, or can be known, in a store-and-forward system. Your only assurance of final delivery is, and can only be, if the recipient chooses to notify you via response to a return receipt request or by responding to the message.