Risks of using Posteo (email provider without DMARC policy)

Privacy Questions
1

Posteo is not recommended by Privacy Guides because it does not have a DMARC policy.

This means that anyone can “spoof” your email. But I want to be sure that I understand this correctly.

Does it mean that if I set up a Posteo account, anyone can send emails from my email address and the recipient will think its me? I won’t even know it happened.

If so, it seems absolutely insane how Posteo choose not to allow this? Why would anyone take this risk if they are using email for business or a public account?

(also, what happens if the recipient responds? Does it go to me or the spoofer?)

But maybe I am missing something? Because this is unbelievable. The possibilities of abusing a Posteo user through exploiting this flaw are endless.

1 Like
2

No this is not really correct. DMARC is good to have and Posteo will probably add it soon, but even without a DMARC policy almost all email servers still check SPF and/or DKIM signatures, so nobody is able to just spoof posteo email addresses. Adding a DMARC policy just makes it more explicit to other email servers that SPF and DKIM should be checked.

It does not apply in the case of Posteo domains, but if somebody would be able to spoof an email, then a reply would still go to you and not to the spoofer.

Edit: I just checked. Posteo does have a DMARC policy. Where did you even get this? Just do dig _dmarc.posteo.de TXT and you can see for yourself.

Edit 2: I guess your source is that Posteo (email provider) or similar. It’s a bit wrong, though: Not having a DMARC policy is something completely different than having a “none” policy. A “none” policy is still a policy.

1 Like
3

Yes that is the main source, in which posteo is rejected as a tool suggestion on the basis that "anyone can spoof posteo domain and the remote mail server has no way of checking that. "

If you are right and most still check SPF and DKIM, then I wonder if the PrivacyGuides decision to not recommend it is justifiable.

4

https://www.golem.de/news/e-mail-spoofing-das-problem-mit-dmarc-2008-150099.html
Will need to be translated, but posteo is legit. At least as far as I read the article

5

Check for yourselves: Email test: posteo.de

Posteo uses a bad configuration when it comes to DMARC and uses weaker ciphers that are not recommended.

2 Likes
6

I really like the Dutch internet initiative thingy there, they’re doing a lot of good and important work. That being said, you still have to interpret the results in the context of the actual internet environment and what they mean, not just “number go up”-style. I’d like to say something about each of the test parts that they fail there:

  1. No IPv6 reachability for receiving mail servers

Yes, IPv6 is the future and I’d love it if we would just abandon IPv4 right now completely and go on with our lives. However, the situation currently is that mail servers don’t really use IPv6. The web etc. yes, almost everything does benefit from IPv6 connectivity, but mail servers not really. 99.9% of mail servers that are actually used out there are IPv4-only or dual stacked, there’s simply nothing to gain really from having IPv6 connectivity for a mail server right now.

  1. DMARC policy “none”

For company, SMEs, personal mail servers etc. yes, please have a strict DMARC policy. But mail servers where random people sign up to, we are not fully there yet that I would recommend this to everyone. Maybe when everyone supports ARC etc., then many pain points will go away, but DMARC, even though it does improve security in a way, does so in a way where it also breaks some normal email workflows that people want to use or rely on using. On the other hand, there is not much lost by having a “none” policy, most mail servers will still recognize spoofed mail without issues.

  1. Support for older/weaker TLS ciphers

Ok think for a second here: There is pretty much no mail server in the world right now that enforces TLS. So why is enforcing the newest ciphers gonna do much? Should you support them? Yes of course. But if you offer an unencrypted channel anyway, why care about having a few older ciphers also available? Older mail servers that you might communicate with now can at least use encryption in the first place, when they would fall back to an unencrypted connection if you would enforce the newest ciphers. Mail servers are not web servers, not everything that makes sense in HTTP land is also applicable to SMTP. Of course, if we get a point in the future where unencrypted SMTP is no longer used at all, then sure we can have this discussion maybe, but right now I just don’t see the actual benefit that is being tested here.

So yes, posteo might have 81% on this test and other servers 100%. But think about real life, does the 19%, whatever that is a percentage of, actually mean for privacy and security? I don’t think it amounts to much at all. And again, nothing against the test, it’s a handy tool to check some stuff, but interpret the results with care.

1 Like
7

While agree on your remarks on the ipv6, which I believe it or not also have written before here in another discussion, I firmly disagree with your other points.

Security settings should be enforced by your provider for two basic reasons. They are 1 to mitigate downgrade attacks, and 2 to set a higher standard. If nobody ever moves forward and still will accept old standards, less caring providers will never update the security. This is a strategy many big tech companies have followed in the past ( like f.x. Microsoft) and they are now paying the price for keeping all those options in the name of compatibility. This does actually seems to changing because of the security issues this causes.

3 Likes
8

Well the source is not wrong, our requirement is just being misinterpreted in this thread. We don’t claim their policy doesn’t exist, we said it doesn’t meet the following criteria (which is true):

If DMARC authentication is being used, the policy must be set to reject or quarantine.

The fact of the matter is that we have 4 excellent mailbox providers who can meet all of the requirements we’re looking for. Posteo also recycles deleted email addresses, which we find to be problematic.

That being said, using Posteo is probably not going to be super dangerous or anything if you understand these limitations (obviously much better than mainstream email providers). I think Posteo actually meets all our other requirements, which is fairly impressive (but don’t take my word for that because I haven’t looked at Posteo/email providers in like a year). But if Posteo isn’t going to live up to all the standards that other providers in the space already provide we’re still not going to recommend it. I don’t know of any reason it might be better than the alternatives at least. Hope that answers the OP’s question :slight_smile:

2 Likes
9

I’m not quite sure how that “crypto mail storage” is supposed to be compatible with IMAP and CalDAV as they say while still providing “zero knowlege” encryption. I mean, Protonmail and Etesync need their local bridge programs for a reason. I had similar concerns about Startmail’s “vault”, and they told me that essentially, when you’re using IMAP you’re transmitting the password that they can use to decrypt your email. It’s likely the same for Posteo.

10

Posteo’s zero-knowledge storage comes from their support for automatically encrypting messages with PGP, similar to Mailbox.org’s, so that’s the feature you’d want to look into.

1 Like
11

I believe mailbox.org also recycles addresses after 90 days of non-payment.

2 Likes
12

@Regime6045 The zero-knowledge part indeed as jonah said only comes from PGP or S/MIME. Posteo supports both for encrypting your incoming mails automatically. What you linked is another encryption layer: GitHub - posteo/scrambler-plugin: Dovecot plugin to enable encrypted storage (Dovecot plugin) This is not zero-knowledge, but if you trust Posteo to not save your password in a readable way, if someone would just confiscate their servers, then all your data would be additionally encrypted with your password.

And yes Mailbox.org does recycle addresses. You can easily test it yourself :slight_smile: