RainLoop Webmail: Simple, modern and fast web-based email client | Hacker News Reader

RainLoop Webmail: Simple, modern and fast web-based email client

rainloop.net

115 pointsmintplant68 comments

The license (CC BY-NC-SA 3.0) kinda sucks. It's not Free or Open Source, but more importantly, "non commercial" for a webmail client is probably an impossibly high standard for the type of person who would be setting up their own webmail client. Even CC recommends against using CC licenses for software.

> We recommend against using Creative Commons licenses for software ... CC licenses may be used for software documentation, as well as separate artistic elements such as game art or music

http://wiki.creativecommons.org/FAQ#Can_I_apply_a_Creative_C...

Ugh. Rainloop has been on my "to-port" list for sandstorm.io but I hadn't noticed the license. If I want to make this available as a "free" package that can be installed on an open source platform, but I also want to sell hosting for that platform, am I using it for my own commercial advantage and thus violating the license? Who knows?

Guess I'll stick to mailpile and roundcube.

Try Modoboa? Link: http://modoboa.org/en/

Ooh, thanks, I'll add that to the list.

Apparently they want you to pay $85 a year for a real license, which is a complete shame, but rational given that there is at present a total of one reasonably modern open-source email client (Roundcube) and it's still pretty dreadful to work with, and in some cases hard to use. Rainloop don't have much in the way of open-source competitors to drive the market price near 0.

I don't know how I should feel about this secure method of generating a salt that is used for almost everything as it seems:

  // random salt
  $sSalt = '<'.'?php //'
  	.md5(microtime(true).rand(1000, 5000))
  	.md5(microtime(true).rand(5000, 9999))
  	.md5(microtime(true).rand(1000, 5000));
  
  @file_put_contents(APP_DATA_FOLDER_PATH.'SALT.php', $sSalt);

It looks like they just threw some cryptographic hash functions at things and hope it works out.

The main purpose of a salt is to defeat a rainbow table. I.e. using a precomputed table of all possibilities to lookup more than one password at once. If the salt is different for each password, that guarantees that the work used to solve one password cannot be used for the other. Cryptographic randomness is not necessary, just uniqueness.

I don't really know PHP, but what's the problem? A salt doesn't have to be perfectly random. It just should be unlike any other salt in use.

This looks like it would meet that requirement.

Edit: Since this is HN, I feel obliged to point out that there is a small vulnerability introduced by using a non-CSPRNG here. If an attacker is already surveiling you, and is able to perfectly deduce the state of your PRNG before you generate your salt, and the attacker plans to steal your db at some point in the future, he can get a head start in generating rainbow tables against your database.

But the main value of a salt is in being globally unique, which this is.

>he can get a head start in generating rainbow tables against your database.

While it is true that he can get a head start, a head start is quite useless because the work necessary to reverse one hash is independent of the work necessary to reverse a different hash. That means that you still have to brute force each password individually.

It's not my project, but I'm sure a pull request would be appreciated.

https://github.com/RainLoop/rainloop-webmail

How does it compare to Roundcube [1] which is solid, proven and has a better license? [1] https://github.com/roundcube/roundcubemail

It may have improved, but when I used roundcube on webfaction a year or two ago, it was unusably slow.

Try it again. Maybe WebFaction customized it? Roundcube is plenty fast.

I use it on a smaller host, and it's alright. It doesn't seem to support multi-selection of email so you have to delete or move messages one at a time, and it's not at all ajaxy.

Does this validate TLS/SSL connections? Roundcube has the option for TLS/SSL IMAP/SMTP but doesn't preform any validation :/

What's up with the Password setup here? It's using symmetric encryption rather than a slow hash?

I'm no cryptographer, but I always thought that was generally a terrible idea... Or am I reading that terribly wrong, it is 5.30pm here and my brain has shut off for the day.

https://github.com/RainLoop/rainloop-webmail/blob/be45d989f8...

Is that because it needs to know your password to pass it on to the mail server?

Ah hah, alright, that makes sense. I knew I was missing something, thanks.

Slightly off-topic - mobile.

Roundcube and this solves the webmail client send nicely. IMAP PUSH solves the desktop end nicely.

But the reason I switched away from self-hosting my email was due to the lack of IMAP PUSH on iOS (ironically this was never a problem on several generations of dumbphones I had before, which supported IMAP PUSH).

As far as I can tell, all the current alternatives to get your IMAP email pushed to your iOS device require giving a third party full access to your email. Or does anyone know of anything I've missed?

This is very promising. Ever since Gmail for domains and Outlook for domains became paid-only, I've been looking for alternatives. This looks like potentially a perfect solution.

You might want to look into roundcube [1] which is another PHP webmail application that has a very nice UI,, (more) mature codebase, and is on an (arguably) better license (GPL3). I can't say how it compares to rainloop because the demo servers are slammed right now, but I would recommend roundcube in general.

[1] http://roundcube.net/

Except nobody wants a PHP webmail application.

Could you share alternatives written in another language ?

Can you explain why?

Terrible security record of PHP apps, probably.

Doesn't make sense because Squirrelmail is also written in PHP and it's pretty solid. The next version will use HTTP-only cookies to further harden against attacks.

do you know of any particular reason that wasn't put in to place years ago? concern for legacy browsers at all costs? it sounds snarky, but it's a genuine question - I think I've set my apps to be http-only cookies for a while now, and am wondering why someone would only get around to it in 2014.

I wonder what does RainLoop use as ‘backend’ for communication with mail servers. Are there standalone libraries that fully support, say, Gmail IMAP features? Libraries one can build a mail management GUI on top of.

Last time I updated Apple Mail it included yet a few more fixes specifically for Gmail IMAP support. This makes me think that a compatible enough decent solution requires knocking together something custom at this point.

Are there standalone libraries that fully support, say, Gmail IMAP features?

If you have to call them "Gmail IMAP features" they really aren't IMAP at all and it would be better to call them proprietary Google-extensions.

Gmail does not follow standard IMAP, and no standard IMAP client can fully interop with Gmail. That's a decision Google made, and you can't blame anyone else for the consequences of that.

> no standard IMAP client can fully interop with Gmail

It's my understanding that no standard (as in, RFC standard) IMAP client can interop with pretty much any widely-used IMAP server. This is a topic that comes up whenever IMAP is discussed on HN. All IMAP clients and servers are full of hacks to deal with specific servers or clients.

It's been a while since I looked at it, but my impression had been that Gmail does follow IMAP, but some features of Gmail aren't represented in IMAP. A simple example is that IMAP expects a message to be in a single folder but Gmail allows you to use multiple labels. I'm pretty sure that this particular issue had no real impact, but there are others that do (difference in handling deleted messages sounds right?) IMAP has no concept of "Archive", which is a key Gmail feature. I think I remember some talk about how Apple deals with that.

I don't think you can blame either Google or Apple or IMAP for this. It's how standards work: good for interop, but don't always deal with innovation well.

What does the gmail android app do? Does it speak IMAP, IMAP-with-proprietary-extensions, or something else?

It uses a custom protocol. IMAP support in Gmail is there only for interop, if you stick to Google's software it's not used at any point.

Gmail's IMAP extensions follow the IMAP spec for custom extensions (using X- prefixes). They don't really violate the IMAP spec so much as provide access to gmail's custom features through the IMAP protocol.

Looks great, and it's awesome that it has pgp support, but it seems that unless your key is created specifically with the current email address you just can't use it? would be nice if you could use any key for which you had the secret part

Also, how does it handle verifying signed messages from keys which you don't have? does it have support for searching via keyservers/using pka stuff to find a key?

I hope it's going to be integrated into https://yunohost.org

The privacy policy says that personal information, such as my name or e-mail address, is private and confidential. I assume that personal information would include the contents of my emails. However, with email privacy policies I'd rather not rely on assumptions and see it spelled out more specifically.

http://demo.rainloop.net/ Resource temporarily unavailable - please try again later.

Hacker News effect, the demo takes ages to load. But the frontend looks cleaner than Roundcube, it might be worth a try.

There's a lot of php webmail software out there; the php script for installation just makes you want to run away.

Seems pretty sane to me: checks for dependencies, unzips the application files, chmods some data folders.

It may be a little complex, but that's understandable since PHP can be used on any platform.

You can download the zip file if you'd rather install that way.

What exactly is the "PLUS" in this client? How does it fare against RoundCube?

The colors could be better.

It seems to support GPG.

How does this compare to roundcube?

I did a Cmd-f for 'secure' and 'encrypt' on the front page got no hits.

You forgot PGP and SSL. http://rainloop.net/features/

Thanks!

Reporting a typo:

Purchase Subscription Key on gimroad.com

It should be gumroad.com

Going to be "that guy":

On the installation page, it says to do this:

    curl -s http://repository.rainloop.net/installer.php | php
    wget -qO- http://repository.rainloop.net/installer.php | php

This is incredibly dangerous. Because it's http, it can be Man-In-The-Middle'd, so you're basically executing arbitrary commands on your computer. (See: php function exec()). Also, even if it's non TLS/SSL, you're putting a lot of trust in Rainloop not being hacked or malicious.

If your network is Man-In-The-Middle'd you are probably fucked in more than one way, and a backdoored php install script is the least thing you should worry about.

It's no different to just download an installer and double click it.

Providing verification methods in alternative channels is essential if you need make sure everything is clean.

There's a small difference.

With a normal download, you're likely to wait until it's done before invoking it.

With a pipe-to-interpreter, the interpreter (php/sh/etc..) is possibly interpreting code as it receives in batches of (line/chunk/etc.).

A danger therein lies in the possibility of an unexpected pipe interruption (network, or software) feeding something that's technically runnable by the interpreter but logically broken.

Imagine coming down the pipe is "rm -rf /tmp/installer-data" but curl uses too much memory and the linux OOM killer nukes it and sh receives only "rm -rf /"

with "curl -s" at least, curl wont send anything onto the next process until it's done receiving (all) the data.

_If_ the pipe breaks up the incoming data, I assume its on 1 of these boundaries of 64kb-ish: http://unix.stackexchange.com/questions/11946/how-big-is-the...

http://stackoverflow.com/questions/4624071/pipe-buffer-size-...

In general, when I've seen this technique used in Ruby (RVM?, back in the day) and/or PHP (Composer recommends a similiar Curl install technique, but composer.phar is an digest-archive of sorts ....) the installer code tends to be about a paragraph worth of text.

All in all I understand your point. But your contrived example of rm -rf seems a little too contrived. In this case we're were talking about PHP code ... the chunked-piped code would still need to be valid PHP of what "rm -rf /" is not as it's missing important tokens to denote valid php expression(s).

It seems like it would be equally worrisome to worry about Brownian Motion flipping a bit in memory and catastrophically affecting my program execution -- possible but unlikely.

FWIW I used the word "pipe" very loosely to mean everything to the left of the interpreter. That means the unix pipe itself, but also the curl program, OS feeding it, network it's on, remote server feeding it, etc.

There are several scenarios where that logical pipe can fail. It doesn't have to happen cleanly on a 64-kb unix pipe buffer boundary. Some examples may include someone bouncing an office router and all TCP connection states getting reset, a neighbor microwaving lunch and WiFi radios croaking, a carrier having networking issues and connections timing out, the remote server restarting the web server after a software upgrade, etc..

I'm not sure curl (even with -s) will gracefully handle all of these cases defensively (doubly-so if the HTTP server was sending back chunked-encoding without explicitly specifying a Content-Length)

(anecdotally, since you mentioned flipping bits, it's possible but unlikely until you have to deal with it - http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-so... )

At the end of the day, having not even considered what an active attacker could do but just what could naturally blow-up a small percentage of the time I'm inclined to say "that's bad, mmkay?" and try to persuade developers not to push that as a safe installation method. Even if they've triple-checked that the code they've written + interpreter can not possibly do harm in that case, the signal we should be sending (primarily to end-users) is that this may be an unsafe operation.

> curl wont send anything onto the next process until it's done receiving (all) the data.

Huh? How do you explain I curl | tar -zxvf gigabytes of file without consuming all of my RAM and swap?

> ... OOM killer nukes it and sh receives only "rm -rf /"

If curl was SIGKILLed, wouldn't that result in a "broken pipe", therefore causing the shell to abort? The only way the "rm -rf /" would be executed would be if the pipe shut down cleanly and the shell saw an EOF (since obviously there would not be a newline in the scenario you described).

The classical "broken pipe" typically occurs when a process is writing to a closed pipe, not reading (which usually gets a vanilla EOF)

See my longer reply to tenken for some other scenarios I could think off.

You have a good point.

It's good practice to download, verify checksum/cert, then run.

  > If your network is Man-In-The-Middle'd you are probably
  > fucked in more than one way, and a backdoored php install
  > script is the least thing you should worry about.

Connecting to MITM'd networks is extremely common, and millions of people (even technical people) intentionally do so every day. If you've ever used a free Wifi hotspot with one of those click-through use agreements, you've used a MITM'd connection.

The only reasonable security stance towards the security of your local internet connection is to assume that it's got something malicious on the other end of it. That's why using HTTPS is so important.

  > It's no different to just download an installer and
  > double click it.

Most people install applications via app stores nowadays, which verify signatures on the application before installing. HTTPS is widely used in non-app-store distribution systems.

>>Also, even if it's non TLS/SSL, you're putting a lot of trust in Rainloop not being hacked or malicious.

I'm assuming that "non" shouldn't be there, so... I don't know how I feel about the whole curl/wget [url] | [interpreter] trend. In theory, it shouldn't really be that different from the days of downloading "setup.exe" and running it.

If for some reason you don't trust Rainloop then you shouldn't install anything of theirs no matter what the delivery method is.

> Also, even if it's [on] TLS/SSL, you're putting a lot of trust in Rainloop not being hacked or malicious.

It seems like no matter how you install the software, you likely have to put at least that level of trust in them. Unless you run it in its own VM or other sandbox, of course.

The TLS point is totally valid, though.

I prefer to see these scripts on github, over https, with a commit hash specified. That's harder to hack.

For a long time the officially documented way to install GNOME was to lynx -dump http://go.gnome.org and pipe it to a root shell. Looks like the industry hasn't learned much in twenty years.

Couldn't you say the same thing about downloading and running any installer from the internet? There is nothing special about PHP that makes this insecure, the exact same attack you describe could be done when you are downloading a Windows installer executable from a browser and double clicking it.

>There is nothing special about PHP that makes this insecure

He didn't say it was because of PHP, he said it was because of http (i.e., because it's not over SSL).

> the exact same attack you describe could be done when you are downloading a Windows installer executable from a browser and double clicking it

Exactly, which is why people who are security conscious never simply execute a Windows installer downloaded from the browser (or wget, for that matter). At a minimum, one checks the file hashes. Ideally, one confirms that the executable has been properly signed and not tampered with (by right-clicking the file, clicking 'properties' and looking at the 'signature' tab, or else manually checking if it's been GPG signed).

The point is there's no SSL.

Nice!

Reply on news.ycombinator.com