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
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?
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.
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.
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.
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.
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.
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?
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.
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.
>>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.
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.
[+] [-] adambatkin|11 years ago|reply
[+] [-] sheetjs|11 years ago|reply
http://wiki.creativecommons.org/FAQ#Can_I_apply_a_Creative_C...
[+] [-] kentonv|11 years ago|reply
Guess I'll stick to mailpile and roundcube.
[+] [-] vertex-four|11 years ago|reply
[+] [-] TimWolla|11 years ago|reply
[+] [-] chacham15|11 years ago|reply
[+] [-] jnbiche|11 years ago|reply
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.
[+] [-] mintplant|11 years ago|reply
https://github.com/RainLoop/rainloop-webmail
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] marco1|11 years ago|reply
[+] [-] jonahx|11 years ago|reply
[+] [-] ehPReth|11 years ago|reply
[+] [-] girvo|11 years ago|reply
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...
[+] [-] LeoPanthera|11 years ago|reply
[+] [-] kalleboo|11 years ago|reply
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?
[+] [-] taneem|11 years ago|reply
[+] [-] prg318|11 years ago|reply
[1] http://roundcube.net/
[+] [-] goblin89|11 years ago|reply
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.
[+] [-] josteink|11 years ago|reply
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.
[+] [-] therealidiot|11 years ago|reply
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?
[+] [-] alex_duf|11 years ago|reply
[+] [-] Cowicide|11 years ago|reply
[+] [-] lazyant|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] TimWolla|11 years ago|reply
[+] [-] damm|11 years ago|reply
[+] [-] fredsted|11 years ago|reply
It may be a little complex, but that's understandable since PHP can be used on any platform.
[+] [-] johnchristopher|11 years ago|reply
[+] [-] ForFreedom|11 years ago|reply
The colors could be better.
[+] [-] eng_monkey|11 years ago|reply
[+] [-] jiggy2011|11 years ago|reply
[+] [-] coherentpony|11 years ago|reply
[+] [-] fredsted|11 years ago|reply
[+] [-] chanux|11 years ago|reply
Purchase Subscription Key on gimroad.com
It should be gumroad.com
[+] [-] edwardio|11 years ago|reply
On the installation page, it says to do this:
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.[+] [-] est|11 years ago|reply
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.
[+] [-] smtddr|11 years ago|reply
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.
[+] [-] kentonv|11 years ago|reply
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.
[+] [-] thrownaway2424|11 years ago|reply
[+] [-] gtCameron|11 years ago|reply