Hi,

On 26.05.20 09:21, mj wrote:

One doubt I had: "disable_plaintext_auth = yes" sounds as if only the authentication part is secured, and the rest is kept plain text, whereas with 993/SSL, *everything* would be encrypted?

Or am I missing something? (then perhaps someone can point it out?)

here you can read the details:

https://doc.dovecot.org/admin_manual/ssl/dovecot_configuration/

"There are a couple of different ways to specify when SSL/TLS is required: [...]"

Regards, Markus

On Tue, 26 May 2020, mj wrote:

On 25/05/2020 23:04, Voytek wrote:

...

jumping here with a question, if I use 143 with STARTTLS, and, force TLS/SSL in configuration, that's equivalent from security POV, isn't it? and, same for 110 STARTTLS? Or am I missing something?

There's an important clause here that often becomes overlooked: "force TLS/SSL in [client] configuration". If you don't fulfil this condition, STARTTLS can fall prey to downgrade attacks. This has been done, and not by small players:

https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks

Some mail readers, like macOX Mail, will happily reconfigure your mail reader server settings to use plaintext unless you disable it.

Interesting point, after some googling, I think you are right, and as long as we have set "disable_plaintext_auth = yes" (and we have that) we should be fine keeping 143 open. Right?

Yes, provided the above condition is met. However, unless you control all endpoints, that's hard to enforce.

One doubt I had: "disable_plaintext_auth = yes" sounds as if only the authentication part is secured, and the rest is kept plain text, whereas with 993/SSL, *everything* would be encrypted?

Once STARTTLS negotiations are over, it is equivalent to SSL: all data is encrypted. However, I see your point: the configuration label suggests it's limited to authentication data, as opposed to all data. Something like "ssl_forbid_decline" or "ssl_not_optional" might have been clearer.

Joseph Tam jtam.home@gmail.com

Le 29 mai 2020 à 11:17, Stuart Henderson stu@spacehopper.org a écrit :

On 2020-05-26, mj lists@merit.unu.edu wrote:

...

Hi,

On 25/05/2020 23:04, Voytek wrote:

...

jumping here with a question, if I use 143 with STARTTLS, and, force TLS/SSL in configuration, that's equivalent from security POV, isn't it? and, same for 110 STARTTLS? Or am I missing something? Interesting point, after some googling, I think you are right, and as long as we have set "disable_plaintext_auth = yes" (and we have that) we should be fine keeping 143 open. Right?

In the case of 143, nothing stops the client *sending* a plaintext login request. Login may be denied, but the password is already leaked. Also if you have only the server side (not the client side) deny plaintext logins, a MITM can just strip off the STARTSSL capability from the server response.

And doing that it can as easily inject a LOGIN capability, making non-broken client also send the password in plain text. (Only broken client will send password if LOGIN is not present).

That’s why this RFC exists: https://tools.ietf.org/html/rfc8314 https://tools.ietf.org/html/rfc8314

In a setting where you want to protect the clients from accidentally exposing secrets by misconfiguration, allowing only 993/995 (and 465 for SMTP; 25/587 have the same problem) is the safe way.

Port 25 is a special case and should never be used by client, but only for (unauthenticated) server to server communication. There is no way to use implicit TLS for SMTP as the SMTP transport MX infrastructure has no way to specify a port.

Client should always use the submission port (587, or 465 for submission over TLS).

Hi,

I want to do a simple backup of my maildir. I read here that maildirlock is not to count on in the future and the recommended option was to use doveadm backup. However, it seems that this requires to setup another dovecot server.

My questions are:

• How much to I need to configure this new server? Do I need to setup user by user, or even install postfix (that's where my users are configured) to get it all backed up? I tried to install dovecot and running doveadm backup, but it complains the users are not there.
• What's the simplest way to configure dovecot without mirrowing my server so that this can work?

Best,

Francis

Francis Augusto Medeiros-Logeay Oslo, Norway

On 2020-05-30 07:49, Admin Beckspaced wrote:

Am 29.05.2020 um 17:37 schrieb Francis Augusto Medeiros-Logeay:

...

Hi,

I want to do a simple backup of my maildir. I read here that maildirlock is not to count on in the future and the recommended option was to use doveadm backup. However, it seems that this requires to setup another dovecot server.

My questions are:

• How much to I need to configure this new server? Do I need to setup user by user, or even install postfix (that's where my users are configured) to get it all backed up? I tried to install dovecot and running doveadm backup, but it complains the users are not there.
• What's the simplest way to configure dovecot without mirrowing my server so that this can work?

Best,

Francis

---

Francis Augusto Medeiros-Logeay Oslo, Norway

Hello Francis,

I also have maildir as mailbox format and use the following script to do daily backups

https://github.com/tachtler/dovecot-backup

There's also a more detailed how-to which explains how to do a restore. But it's only in german language

https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:dovecot_backup_-_skri...

Google Translate is your friend ;) perhaps this might help?

greetings Becki

Thanks a lot Becki. I read your script, but the thing is that I want to backup to a remote server. Your script seems to be focused on a local backup. Did I get it right? But it still gives me a good idea of a possibility of backing up locally and rsyncing to another server.

-- Francis Augusto Medeiros-Logeay Oslo, Norway

On 29 May 2020, at 23:49, Admin Beckspaced admin@beckspaced.com wrote:

I also have maildir as mailbox format and use the following script to do daily backups

https://github.com/tachtler/dovecot-backup

A couple of notes on this quite useful script:

My mktemp does not support -p (FreeBSD 12.1) is I had to change the script to:

DIR_TEMP=$($MKTEMP_COMMAND -d $TMP_FOLDER -t $SCRIPT_NAME)

Which gives a temp folder along the lines of

/tmp/dovecot_backup.IiZ00GyZ

I also changed the various date strings to date -Iseconds and date -R for the mail handling since the format in the script is not to spec, using

Fri, 29 May 2020 23:49:31 (-0600)

Instead of the

-R, --rfc-email output date and time in RFC 5322 format. Example: Mon, 14
2006 02:34:56 -0600

-- FRIDAYS ARE NOT "PANTS OPTIONAL" Bart chalkboard Ep. AABF23

On 31 May 2020, at 11:13, Laura Smith n5d9xq3ti233xiyif2vp@protonmail.ch wrote:



Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

...

On Sunday, 31 May 2020 09:35, @lbutlr kremels@kreme.com wrote:

A couple of notes on this quite useful script:

My mktemp does not support -p (FreeBSD 12.1) is I had to change the script to:

In my scripts I tend to create a tempdir and then tempfiles within that. It makes the cleanup routine neater, e.g. at the top of my scripts :

TEMP_DIR=$(mktemp -qd || { doLog "Failed to make temp dir !"; exit 1; }) rmTmpFiles() { rm -rf "${TEMP_DIR}"; } createTempFile() { local MYTEMP=$(mktemp -qp "${TEMP_DIR}" || doLog "Failed to create temp file"; exit 1); echo $MYTEMP; }

I don’t think I need to clean up, and my “temp_dir” will end up being permanent, as to make doveadm backup snappier I will simply maintain the directory there and use crown jobs to update the dir.

Also my backup scripts have locking procedures built-in so as to avoid race conditions.

Also not sure if that’s needed when using doveadm backup, as it takes care of the potential race conditions.

So the idea is to use doveadm to a local folder, then rsync it to a remote server where snapshots can be easily created.

It annoys me have to do the doveadm to the local server - seems like a waste of disk space, but since maildirlock is not working and since doveadm backup to a remote server requires a bit more work to, well, to work, so I guess this is a simple and quick solution.

Best,

Francis

On 31 May 2020, at 03:11, Laura Smith n5d9xq3ti233xiyif2vp@protonmail.ch wrote:

On Sunday, 31 May 2020 09:35, @lbutlr kremels@kreme.com wrote:

...

A couple of notes on this quite useful script:

My mktemp does not support -p (FreeBSD 12.1) is I had to change the script to:

In my scripts I tend to create a tempdir and then tempfiles within that. It makes the cleanup routine neater, e.g. at the top of my scripts :

The script linked in my message has most, if not all the features you mention below. I was simply pointing out for anyone who followed this that FreeBSD's mktempo does not support the -p flag and the changes I made to the line that created the temp directory in order to work.

TEMP_DIR=$(mktemp -qd || { doLog "Failed to make temp dir !"; exit 1; }) rmTmpFiles() { rm -rf "${TEMP_DIR}"; } createTempFile() { local MYTEMP=$(mktemp -qp "${TEMP_DIR}" || doLog "Failed to create temp file"; exit 1); echo $MYTEMP; }

Also my backup scripts have locking procedures built-in so as to avoid race conditions.

-- "Are you pondering what I'm pondering?" "Well, I think so, Brain, but I can't memorize a whole opera in Yiddish."

On 29/05/20 11:27 pm, mj wrote:

Thanks to all who participated in the interesting discussion.

It seems my initial thought might have been best after all, and discontinuing port 143 might be the safest way proceed.

Yes and no. Some of the attack vectors mentioned are not reasonable and it really depends on the client. Thunderbird, for example, used to have settings for plain text, TLS and "TLS if available", but the latter setting has not been available for some time which forces the user to choose either plain text or TLS at setup time now. This means that the user would now have to change the setting in their client for a downgrade attack to work. I can't speak for all MUAs but if they similarly have removed their "TLS if available" option or if the users explicitly don't pick that option (you can ask them not to in your setup instructions) then that type of downgrade attack cannot occur.

The other possible downgrade attack which was not mentioned but is equally mitigated by the client is where the MITM intercepts the connection, connects to your server and issues a STARTTLS itself but presents the resulting connection as plain text to the client. This means that enforcing STARTTLS on the server side will not prevent a plain text connection through a MITM from the client. But do keep in mind that if the client is configured properly to only connect via TLS then it will refuse the connection if it is not presented with a STARTTLS option that works.

So yes the safest way to go is to just use port 993, but as long as the client is not set to a "TLS if available" option then port 143 is also safe.

Also note that the same concerns apply for your submission server (likely postfix) using the submission port (587) and enforcing STARTTLS vs the submissions port (465) which is a direct TLS connection.

Peter

On 31/05/20 6:50 pm, Jean-Daniel wrote:

...

Yes and no. Some of the attack vectors mentioned are not reasonable and it really depends on the client. Thunderbird, for example, used to have settings for plain text, TLS and "TLS if available", but the latter setting has not been available for some time which forces the user to choose either plain text or TLS at setup time now. This means that the user would now have to change the setting in their client for a downgrade attack to work. I can't speak for all MUAs but if they similarly have removed their "TLS if available" option or if the users explicitly don't pick that option (you can ask them not to in your setup instructions) then that type of downgrade attack cannot occur.

The other possible downgrade attack which was not mentioned but is equally mitigated by the client is where the MITM intercepts the connection, connects to your server and issues a STARTTLS itself but presents the resulting connection as plain text to the client. This means that enforcing STARTTLS on the server side will not prevent a plain text connection through a MITM from the client. But do keep in mind that if the client is configured properly to only connect via TLS then it will refuse the connection if it is not presented with a STARTTLS option that works.

So yes the safest way to go is to just use port 993, but as long as the client is not set to a "TLS if available" option then port 143 is also safe.

I don’t think you can call an option safe if it relies on the users to properly configure their client. We all know that users are usually bad at following instructions ;-)

Fair enough, but this attack vector can only happen if it's on a client that supports a downgrade option (I should hope that most don't nowadays, but someone did mention MacOX Mail earlier) *and* the user selects that option when configuring as opposed to the stricter "TLS only" (or equivalent) option. At that point it still requires a MITM attack to downgrade the connection, and that MITM must not only be able to read the packets but also intercept them and present different data to the user. I can see this type of attack happening in wifi environments and coming from ISPs that want to snoop on people's email, though.

As I said (and I stand by it) the safest approach is to just limit to port 993, but port 143 is also safe if properly configured on both the server and client side.

Peter