I do, Aki.

This is not the point, however.

The point is that the default is not GDPR compliant, and a first easy alternative is also not GDPR compliant, and decoupling the user scheme from the server storage scheme is not at all obvious. Adopting a GDPR-compliant default would send out the information that the project cares about legal compliance, and a solution is supported by default.

-------- Original Message -------- On 2/10/25 11:39, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:

...

On 10/02/2025 12:23 EET Rupert Gallagher via dovecot <dovecot@dovecot.org> wrote:

Dovecot aligns the password encryption scheme used by the imap client with the password storage scheme used by the server.

Since the default is set to plain text, the client sends the password in plain text (tls tunneled), and the server local storage of passwords is a plain text file.

For minimum protection, just enough to say you are not using plaintext, you can use md5, so the client sends the hashed password and the server's local storage is a plain text file containing hashed passwords.

Last year a GDPR commissioner filed a hefty monetary sanction to a company because they used md5 to store passwords.

Therefore, Dovecot's plain text default, and the md5 option, are both non-GDPR compliant.

To avoid monetary sanctions, Dovecot ought to change how it stores passwords by default.

Please do not ignore this message.

You do understand that it's the admin's responsiblity to choose a safe password storage, not ours?

Aki

A default dovecot (el9 rpm) install is compliant as it does not work and does not do anything, it is just a bunch of binaries on a disk.

and how exactly this answer is useful ? oh my, I am feeding the troll again .... Bitranox

*Von:* Marc via dovecot <dovecot@dovecot.org>

*Gesendet:* Montag, 10. Februar 2025 um 13:56 MEZ

*An:* Rupert Gallagher <ruga@protonmail.com>, aki.tuomi@open-xchange.com <aki.tuomi@open-xchange.com>

*Kopie:* dovecot <dovecot@dovecot.org>

*Betreff:* RE: Dovecot's default password storage scheme is not GDPR compliant

...

This is not the point, however.

The point is that the default is not GDPR compliant, and a first easy alternative is also not GDPR compliant, and decoupling the user scheme from the server storage scheme is not at all obvious. Adopting a GDPR- compliant default would send out the information that the project cares about legal compliance, and a solution is supported by default. A default dovecot (el9 rpm) install is compliant as it does not work and does not do anything, it is just a bunch of binaries on a disk.

---

dovecot mailing list --dovecot@dovecot.org To unsubscribe send an email todovecot-leave@dovecot.org

On 2/10/25 5:07 AM, Robert Nowotny via dovecot wrote:

...

A default dovecot (el9 rpm) install is compliant as it does not work and does not do anything, it is just a bunch of binaries on a disk.

and how exactly this answer is useful ? oh my, I am feeding the troll again ....

I see it as a useful editorial comment, albeit phrased in a trollish way. And, as trolls will be, it does not show a lot of gratitude for an enormous amount of sincere work that has been put into Dovecot.

A more constructive--though still negative--version might be "A default el9 RPM install of Dovecot does not work, it requires significant effort before it does anything useful.".

That is useful news. My default install of Dovecot 2.3 on Debian 12 (and on several versions before) all *did* work for me, with a minimal amount of appropriate effort.

I have since discovered that replication/dsync on Debian 12 is a little like the above "default dovecot (el9 rpm) install": It does not work. At least not without significant effort. And even though I now *seem* to have it working (no crashes reported in this morning's logwatch e-mail!), to get this far I had to make my own very unnerving guess at how to fix sources and compile my own custom .deb files. Even a completely vanilla build of Debian sources had two failing tests and no help on the mailing list as to whether that is something to worry about or not…so I commented them out and crossed my fingers. I don't consider Debian an obscure distribution, so this seems like news, too.

I wish I had known all this *before* I had embarked on setting up my new servers. When I was searching around about how to configure replication some comments along these lines (snarky or not) would have been useful to me. Even now I would still like some information as to how much I should trust this last edition of replication, the swansong before it was removed for version 2.4. (As cobbled together by me, I got no response at to whether my patch was sensible or not.)

A program like Dovecot is the sort of thing that is hard to know whether it works until one has switched real work over to it, at which point it can be too late. So reports from those who precede, even snarky reports, are useful.

-kb

Thumbs up for that. It costs nothing and adds value. Cant see any downsides (which might exist, aki might elaborate). Bitranox

*Von:* Rupert Gallagher via dovecot <dovecot@dovecot.org>

*Gesendet:* Montag, 10. Februar 2025 um 13:51 MEZ

*An:* aki.tuomi@open-xchange.com <aki.tuomi@open-xchange.com>

*Kopie:* dovecot <dovecot@dovecot.org>

*Betreff:* RE: Dovecot's default password storage scheme is not GDPR compliant

I do, Aki.

This is not the point, however.

The point is that the default is not GDPR compliant, and a first easy alternative is also not GDPR compliant, and decoupling the user scheme from the server storage scheme is not at all obvious. Adopting a GDPR-compliant default would send out the information that the project cares about legal compliance, and a solution is supported by default.

-------- Original Message -------- On 2/10/25 11:39, Aki Tuomi<aki.tuomi@open-xchange.com> wrote:

...

...

On 10/02/2025 12:23 EET Rupert Gallagher via dovecot<dovecot@dovecot.org> wrote:

Dovecot aligns the password encryption scheme used by the imap client with the password storage scheme used by the server.

Since the default is set to plain text, the client sends the password in plain text (tls tunneled), and the server local storage of passwords is a plain text file.

For minimum protection, just enough to say you are not using plaintext, you can use md5, so the client sends the hashed password and the server's local storage is a plain text file containing hashed passwords.

Last year a GDPR commissioner filed a hefty monetary sanction to a company because they used md5 to store passwords.

Therefore, Dovecot's plain text default, and the md5 option, are both non-GDPR compliant.

To avoid monetary sanctions, Dovecot ought to change how it stores passwords by default.

Please do not ignore this message.

You do understand that it's the admin's responsiblity to choose a safe password storage, not ours?

Aki

---

dovecot mailing list --dovecot@dovecot.org To unsubscribe send an email todovecot-leave@dovecot.org

On 10.02.25 14:18, Aki Tuomi wrote:

I am not sure how we should actually implement this. Do you mean that we should require that you always provide a password scheme for credentials, or require explicit {PLAIN} prefix or what? Everything costs something and has unexpected side-effects, like breaking everyone's master password authentication, in this case.

My deminickel: IIUC (someone correct me if I'm wrong), there still isn't any widely available authentication scheme (for SMTP/POP/IMAP) that would simultaneously avoid a) some secret being sent to the server upon login and b) storing the secret on the server (effectively) in plaintext. Depending on implementation details, *either* can qualify as a violation of GDPR - or whatever other legislation you're under.

In the case of a), one needs to properly secure the channel through which the password is sent (and then some, like scrubbing the memory after the OK ...) to avoid the liability. I doubt that it can be construed that the dovecot developers are somehow responsible for the server operator's duty of keeping the SSL privkey secret, the server cert exchanged before expiry, the CA that issued it in the good graces of whatever trust anchor set's maintainers, etc. etc..

As it is, a default dovecot installation is appropriate for slapping it onto one's laptop, fiddling with only a couple config lines, temporarily starting it, and moving a bunch of e-mails to local archive files with one's MUA running on the same laptop; trying to install it for a serious public-facing mailserver with similar ease SHOULD not succeed IMHO, because it'd be proof that the person doing that never spent a thought on important design decisions (storage backend yadda yadda ad nauseam).

If it is indeed possible to make all those decisions on the admins' behalf and deliver an *actual* turnkey "unwashed Internet access grade" variant, feel free to call it "dovecot-ee" or somesuch ...

Kind regards,

Jochen Bern Systemingenieur

Binect GmbH

...

Therefore, Dovecot's plain text default, and the md5 option, are both non-GDPR compliant.

To avoid monetary sanctions, Dovecot ought to change how it stores passwords by default.

Please do not ignore this message.

GDPR is some piece of bull*it regulation made by the EU.

:D It is putting power back into the hands of customers. The European Union has done the most for consumer interests than any nation. Regulating privacy, regulating they own their data. Even this forced warranty on phones, that is longer in the EU than any where else. How dumb you need to be, to not see the advantage.

Dovecot is an international software with many users living outside of the EU and are therefore not legislated to those braindead EU regulations.

There is only one braindead person, the one continuing the path thinking a company will serve your interests better than .. you. :D

So, after my mandatory rant :D, the DEFAULT setup of dovecot should actually be as simple as possible.

I would disagree, it should be hard, so you do not get the wordpress type to install a mail server. This way you get more educated and responsible people managing them. This attitude of giving anyone access to everything is not good, see what you get when you give anyone a gun, the lunatics are shooting in schools. Why should the luntatics be able to manage someone else's email?

It is not the job of the Dovecot maintainers to try to enforce senseless regulations in some parts of the word.

:D are educated by sesame street? Most common and well known are the encryption export regulations. Or eg the digital services act of the EU. Maybe check what happened to telegram for not complying with regulations. :P

or wordpress, as an example, is also coming without that stupid cookie consent thing by default. You have to install a plugin to annoy your website visitors first. :)

Yes take wordpress as an example. These dumb #$@#$@# don't know anything of backporting and if you tell them how to reduce ~50% of their ftp commands during an update, the morons don't do anything.

On 2025-02-12, Steven Varco via dovecot <dovecot@dovecot.org> wrote:

Dovecot is an international software with many users living outside of the EU and are therefore not legislated to those braindead EU regulations.

btw, (like some of the USA's tax stuff) the UK and EU GDPR legislations are extra-territorial. They apply if you provide services to users in those areas, even if you're not in those areas yourself.

still, from what Rupert posted:

"the client sends the password in plain text (tls tunneled)"

...I find it hard to believe that using a TLS channel wouldn't be considered good enough for sending login information. Surely a salted hashed password database (who isn't using that anyway?) with disable_plaintext_auth would be acceptable.

(If you want to open a can of worms, consider the contents of the emails themselves, which are often much more sensitive than the passwords...)