Slashdot Mirror
ISP Sued Over Suspended Email Account
Saint Aardvark writes "A Canadian woman is suing her former ISP over their suspension of her email account. Their accounting system screwed up, and they suspended her account while they sought payment from her. What she didn't realize was that email sent to that address continued to pile up, without any notification to the sender that she had no access to it. She lost a chance at a $65,000 contract job at the Discovery channel because of this. Read the article at CNet, the complaint she brought to the Canadian Privacy Commisioner, and further details from the woman herself on Cryptome.org."
No, it isn't reasonable. But that's not what happened here. She continued to pay her bill. They screwed up. Jesus, jsut read that article.
No. Just because something is in a contract doesn't make it legal. Happens all the time. You can sign a contract agreeing to kill someone, but obviously, that contract is null and void. Those trucks with the stickers plastered on back that say "not responsible for broken windshields"... they're responsible.
In this case, a judge is gonna say that the spirit of the contract was for x amount of Net service over x period of time. A lawyer obviously didn't even look at the ISP's contract before they started using it.
I can't believe, what, three-quarters? of the posts on here are people going "OH WELL SHE SHOULD HAVE PAID THEN DUH".
The accounting system screwed up, ok? She was already paid up and they wanted more money.
Now, the ISP terms said they wouldn't guarantee error-or-interruption-free service. BUT...this isn't covered under that. It was an accounting error, and they suspended her account. This is not the same as if, say, their DNS servers borked.
I'd say she deserves compensation. Definitely. I have had my share of burns from ISP's with OUTRIGHT SHODDY accounting and business practices. Fortunately, nothing so serious...yet. About the only problem was paying THREE TIMES at their suggestion because they said the transaction didn't go through....and then receiving a bill for all three charges. That was an immediate cancel, and lucky for them they credited back the amount.
I hope she wins the case, I'd like to see some of these ISP's get a little more professional. It is a business after all, not a geek club.
...
Email is becoming so important to our everyday lives that maybe laws should be passed to protect email, just like they where passed to protect normal mail
o m ).
Sure, and you're going to pay $0.35 per message for the protection. Oh, and that's only for non-guaranteed protected email. If you want a guarantee, we'll charge you $3.50.
What? Did you protection comes free? (Need to watch more Sopranos if you did).
Think about why email is free for a moment - you're paying for Internet transport (essentially layers three and four of the OSI model), and you're free to do whatever you want above that.
But now you're asking for application-layer guarantees. Here's what comes with your demand:
- specification of how you may and may not use your application layer. Count on Microsoft Outlook/Outlook Express as the only permitted email client. Do you think we have time to support your Linux system when 90% or more are happy with Outlook?
- creation of rules on what kinds of messages are permitted; e.g. attachments may not exceed 1 MB, must be known and permitted media types (no MP3s or ZIPs since the RIAA will quickly get into this game)
- a fee per message and per month for your "guaranteed email."
- government rules, regulations and restrictions on the whole business.
Understand that the USPS salivates at your demand for safety/protection/guarantee in a world that doesn't have them. They've prepared numerous proposals for guaranteed email (including my favorite that would make my email address something like sam_scoove_1234_north_elm_street_mycity_st@usps.c
So make sure you're ready to pay the price (in dollars and freedom) before you demand big brother makes email "safe" for you.
*scoove*
Check out his film while you're at it...
The google cache of the cryptome page.
"I don't trust goats," --To Catch a Spy
Her email address was ______@inter.net. That means the email address is the property of inter.net, not her. It's the reason when you change ISPs you loose your previous email account with the previous ISP.
If someone provides me a service with no contract stating terms of payment, they're free to try and bill me, and I'm free to try and not pay it.
She isn't entitled to free email, but nor is it clear the company is entitled to extort payment from her. If they chose not to bill her for 14 months, that's their loss. See: estoppel, laches.
Sounds like she was playing with fire and got burned. I imagine, though that she'll have her way since she's willing to assert her case in court. She never would if she just sucked it up and paid.
I don't need large brains to have a good time.
6. There is no indication that the potential employer even had the woman's phone number.
Reading the cnet article points out the following fact:
Carter and her potential employer had exchanged telephone messages about the position. Unbeknownst to her, the e-mail would have been the next link in that chain, but by the time she got it, the position had been filled.
So, had the message bounced, the potential employer would have been able to contact her by telephone.
No, it is.
As I said, Hadley v. Baxendale, 9 Ex. 341 (1854) is basically the seminal holding on the subject. The plaintiffs had a mill in Gloucester. A crankshaft broke, and in order to get a new one, the millers had to ship the old one back to the engineers in Greenwich so that they could copy it in making the replacement.
The plaintiffs gave the crankshaft to the defendants, who were couriers. They said that it needed to be sent immediately. However, there was a mix-up and it wound up being rather late, obviously reducing the profit of the plaintiffs, since their mill was totally out of commission during this time.
BUT the defendants only had to pay damages as to the speed of the shipping, and not as to the lost profits. This is because while it was obvious to them that they needed to be fast because that's what the customer insisted on, it wasn't obvious WHY. There was no way that they could have known the full extent of the damages that would result, nor is it commonplace for couriers to know that if they are late delivering _a_ package that someone will lose a fortune as a consequence. That's only true with regards to certain _specific_ packages, or a business that _mostly_ carries critically important packages, such as organ couriers.
The case is even more clear cut here. While people _do_ conduct business over email, a very large quantity of email is spam or personal mail that does not harm people if there is a problem with the non-performing party to the service contract.
Unless the ISP was specifically informed that this PARTICULAR email was of the gravest importance BECAUSE it was worth many thousands of dollars, then they should be able to treat it as though it is any generic email and not worth special care. After all, how could they have possibly known? Are they mind-readers? No. It's unfair to punish them for something that's unforeseen.
If we adopted such a rule, then the possible liabilities of entering into a contract would be so high that we would discourage people from ever so doing, or from doing so affordably in the general case. This is because the party subject to the liability has to predict uncertain and perhaps uncontrollable matters, such as the liklihood of outages caused by someone in a different country running a backhoe through a major fiber line, DDOSes, email viruses, etc.
Since we would rather have lots of transactions occur, we default to the general case, and do not make parties subject to unusually high liabilities unless they are specifically forewarned of them, and can opt not to enter into a contract such as that, knowing the risk they're being asked to take.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
Note that recent advances in spam fighting/filtering have greatly reduced the inherent reliability of the email system. It used to be that every box would happily relay your mail if it accidently ended up in the wrong place, for example. And nobody filtered their mail to /dev/null because it wasn't needed. And certainly people didn't hit `d' two hundred times in a row deleting spam.
Incorrect.Certainly, my mail client (mutt) doesn't send them out. And I don't want them sent out, certainly not without my knowledge. This would be great for spammers to verify addresses ...
sendmail used to send them out, but there were security issues with that, and so it's been disabled by default. For many years now, it appears. But there was a time that they were sent out as soon as your message was received by the destination sendmail.
Here's a reference for you. Return-Receipt-To: was a sendmail thing, not in any RFC, except for RFC-1865 (which only mentions it in passing.)
Simple solution: never rely on an ISP for your email. There are some totally hopeless ISPs out there; this woman's problems aren't a drop in the ocean. Instead, get a web-based mail account including IMAP access so you can use a non-web-based mailer. The best one on Earth is Fastmail, but you can even settle for Hotsnail or Yapoo if you must. Then, whenever your ISP dies, or you decide to dump them in favour of one that understands the concept of service and reliability, then you don't need to change your address.
The grownup version of this solution is to get your own domain name through a reliable provider of such services, and then when you change email systems you can just change a couple of MX entries or whatever and it's all done.
I have discovered a truly remarkable
At the ISP I work at, we simply change the shell in the user's password entry. The new shell will display a message explaining why they don't have access (non-payment, suspended, etc...), sleep for 10 seconds, and exit (disconnecting them if they are on a dial-up). Then we have pop3/imap modified to check /etc/shells to see if the customer is allowed to access their email.