This allows law enforcement to silently direct specific user's mails to them. This requires a ruling and the provider will be aware of it. Still, I think a company like this should mention this in a full disclosure spirit as it can render their promise "No disclosure: Your data remains with us. We never pass on any data to third parties without authorization." void.
---
I do not understand the Legal Certainty paragraph.
"According to TKG Section 113 (German Telecommunications Law), the public prosecutor and the police can access the user data held by telecommunications providers such as ourselves relatively easily. A simple information request suffices; no court order is needed. According to TKG Section 113, a telecommunications provider has no legal recourse against such a request; it must comply. It should also be noted that according to TKG Section 113 (II), the provider is required to treat such a request confidentially, and that the affected customer must not be informed about the request."
You should have included the next paragraph. They make a difference between user data and the users emails:
"Access to the log data of mail and web servers and to the e-mails contained in a mailbox, on the other hand, requires a search and seizure warrant signed by a judge, unless the investigative authorities can claim exigent circumstances. Telecommunications providers again have no legal recourse against search warrants; seizure of the log data cannot be denied."
A SINA Box is nothing else then a kind of VPN Gateway. A SINA Box does NOT provide direct access to a user's mailstore or something else. The still have to get in contact with the ISP to set the interception up and running. There's is no "silent access" just because of having a SINA box.
Anyway: mailbox.org does NOT have a SINA box installed.
This is the German implementation of the European Data Retention Directive [1]. The legal landscape across the EU is bound to be similar. The gist of the directive, regarding email is: providers must retain sender, recipient, date and IP address information for a period (6 to 24 months, depending on the country). This data may be requested by a court order, and only by court order.
The directive says nothing about the secrecy of the request, so this is up to the specific implementation in member states. In Germany it is secret, in Portugal it is public except for complex cases in investigative phase (a specific, well defined situation meant to deal with large organized crime). I don't know about other countries, but since our laws are usually modeled on the French version, I'd wager France is similar to Portugal (actually, it's the other way around)
Spam is REJECTED and not deleted. In cause of a possible false positive the sender (!) will receive a non delivery report. Deleted e-mails is always forbidden.
It is not exactly clear (on the website) what you mean by 'rejected', so the English text could be improved to make your meaning more explicit. Perhaps 'returned' would be better?
In a technical language, "rejecting" (I don't accept that message) and "bouncing" (I accept it, but I will send it back later) is clear defined. Returning would be "bouncing", because I do NOT return, I do NOT ACCEPT.
They should be slightly more explicit, but "...before the e-mails are accepted and reject anything that looks suspicious..." almost certainly means that spam is rejected with a 5xx message - or goes to your InBox, but is never accepted then hidden from you in a spam folder.
It's a good approach, and from a legal perspective I'm surprised more systems don't take this approach, because legally (at least in my local jurisdiction), you're deemed to have received an email when it "enters that information system" - i.e. when your SMTP server says 250.
This stuff matters quite a lot in the formation of contracts.
Yes, but the "bounce message" comes to the sender from their own mail system, saying "could not deliver".
This is important, because the receiving system doesn't have a guaranteed way of reaching the sender - modern spam typically fakes the "From:" and <return-path> fields - so well-run systems nowadays never try to do so for fear of generating what's referred to as email backscatter spam.
"Due to the legal regulations, anyone who business provides telecommunications services or it participates, to allow for the presence of a written arrangement authorized agencies monitoring and recording of telecommunications of an accused and to provide the relevant information. Whether and to what extent the persons liable for participation telecommunications companies must make arrangements for the implementation of monitoring activities or the provision of information, is governed by Section (§) 110 of the Telecommunications Act (the Act) and the Telecommunications Interception Ordinance (TKÜV). The Federal Network Agency is responsible for drawing up the technical specifications and the enforcement of the technical equipment and organizational measures"
This is another lavabit. They receive e-mails in clear text and then they encrypt it. This is not secure at all.
It would be ok if it they were clear about it, but it's exactly the opposite "[...]This means that no one can read your e-mails except yourself – no password thieves, no governmental or law enforcement agencies, not even us here at mailbox.org."
and our doodle film explains the benefit and risk.
Using the feature does not forbit to set up a "real" PGP end-to-end-encryption. Users should do that and our job is to help them -- step by step. And we're explaining that to them.
Our encrypted INBOX is useful in case an e-mail hasn't been sent encrypted, because there ARE many senders (like companies or unexperienced users) that do NOT encrypt their e-mail. That's how it is, so we have to deal with that. It's a kind of "add on".
Right today round about 10% of our inboxes are completly encrypted. That's great, but we'll still have to raise that level. An: > 10% of our users are familiar with encryption in their daily e-mail-usage. -And they will explain that to friends, business contacts and family. The usage and knowledge of encryption has to grow -- and having an encrypted INBOX is one (!) step to it.
In fact you can't use gpg in mailbox.org when you send an email. Gpg is only used to encrypt your mailbox (it encrypts the emails you receive) which is kind of weird. You can of course use GPG in command line or with an external program.
Yes, we HAD access to the plaintext e-mail. And we explain that and warn about that.
But after encrypting the e-mail, nobody will have access to that e-mail any more: Even hackers, phishers or the government. Many people are storing their e-mails for years in their INBOX. Great to protect those e-mails over the time.
But, anyway: The best way is always to use real end-to-end-encryption. In that case, you don't have to trust us any more. We're happy to help to set this up.
So I clicked the page to check if I can a) use my own domain. b) upload my public key and decrypt the mailbox locally to serve IMAP from localhost.
Then I read this
We're not native english speakers and we just got everything back from our translation office. We're still proofreading our website and the translations.
"marketing speech" is not our way of talking and if the translation office did a bad job there, we'll correct that. But there wasn't enough time to read and correct everything.
We just started last week with our englisch website, please give us some days.
This allows law enforcement to silently direct specific user's mails to them. This requires a ruling and the provider will be aware of it. Still, I think a company like this should mention this in a full disclosure spirit as it can render their promise "No disclosure: Your data remains with us. We never pass on any data to third parties without authorization." void.
--- I do not understand the Legal Certainty paragraph.