Slashdot Mirror
World's First 1GB Web Mail May Not Be From Google
xPertCodert writes "According to
this article, the world's first 1GB web mail is not going to be Google, but from the largest Israeli web portal. With 30Mb per attachment, it seems to be quite useful as well. Looks like an idea of extra-large e-mail storage is becoming really hot these days."
This definitely seems like an attempt to steal Google's thunder, but you have to ask if an Israel-local portal company really has the global reach that Google has to be able to offer high-performance ad-supported e-mail to everybody.
I'm not quite sure that they're going to have enough non-local ads in order to serve the world in the way that Google now seems pretty confident in its global geotargeting systems.
But..
a) Unknown and unheard of company
b) Physically quite a ways from most wired countries, as opposed to widespread google (Akamai?) servers
c) Israeli only so far, vs. however many localizations (let alone simple translations) google/gmail has/will have.
d) None of the advanced searching/sorting features that Gmail has been promising and actually do sound fairly nice.
Stuff.
Why a 30MB attachment limit? They could just say 50TB attachment limit and nothing would really be changed since most mail servers have a 5MB attachment limit, at most. Very few of them have a bigger limit.
So... if I wanted to make an attachment and my mail server didn't allow anything over 5MB (and under 30MB), I'd be screwed, right?
Wait! There's a free webbased email service that offers 1GB of space and has a 30MB attachment limit!!
Welcome to economics 101... encourage everyone to switch to your product...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Auto-reply to ACs: "Truly, you have a dizzying intellect."
to those to dumb to work a CD-RW. I mean that. I talk to people all the time whose computers are hosed, but they can't format and reinstall because they couldn't figure out how to write their god damned crap to a CD. With this, let'em send an email (they've already figured out email usually) and download the stuff later. Sure, it's a ridiculously dumb, slow way to back up their data. But hey, if they weren't too dumb to figure out thier CD-RW I wouldn't be posting this comment.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
So true, I run a couple of mail servers for ISPs and we have 3-5MB limits imposed on incoming file sizes. This is for a couple of reasons, firstly we shouldn't have to load up the virus scanner even more with huge files, as it stands the scanners will skip over files over a certain size, but I'm sure the virus writers are eventually going to note this and start sending multi-megabyte virus files.
Next is the dialup issue, if any of you have ever done tech support for a dialup pool you will have run across the clueless user who gets some huge attachment that will take at least 30 minutes to download, but clueless user is so used to his mail checks taking 30 seconds or less he never lets it download and at that point his email becomes "stuck" he thinks because everything behind said attachment is never being downloaded, nor is the attachment being deleted as it should.
Finally let's not forget here that email is one of the worst methods for moving files around, especially largish files, I mean the overhead required to encode the file in text format for sending means you practically double the original size of the attachment to send it. Throw in some bounces and you waste megabytes of bandwidth.
30mb attachments? 1GB storage?
NO NO NO NO!!! Email was not designed for this.
furthermore, many email clients are not equipped to deal with attachments to the tune of 30mb. Most notable examples are Outhouse/Outhouse Express. Their attachment limit is somewhere near 1.7mb (for a 36.6Kbps dialup connection) and around 5.4mb for most broadband (most mailservers capped at 128Kbps).
There is a hardcoded timeout interval in there that causes retrieval and sending of a message of that size to fail if it doesn't see EOF go by in a certain amount of time.
do() || do_not();