Re: Simple backup of maildir folder

[Admin Beckspaced]

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_-_skript

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

greetings
Becki

Re: migrating dovecot to new server

[David Mehler]

Hello,

Thanks, the directory structure and files will all be the same so i'll
just rsync.

Thanks.
Dave.


On 5/29/20, Francis Augusto Medeiros-Logeay  wrote:
> I did what Aki said. Actually I moved it all to a new server and to docker
> containers. From Dovecot 2.2 to 2.3. And it worked fine. Of course one
> always forget something - the path for the certificates, the different
> directory for mounting storage, etc.
>
> But am surprise and happy that it worked very well.
>
> __
> Francis Augusto Medeiros-Logeay
> Oslo, Norway
> Sent from a mobile device / Enviado a partir de dispositivo móvel
>
>> On 29 May 2020, at 19:33, Aki Tuomi  wrote:
>>
>> 
>>> On 29/05/2020 20:12 Ralph Seichter  wrote:
>>>
>>>
>>> * David Mehler:
>>>
 I'd ideally like to back up all the mails in the maildir location,
 copy that over, load in my configuration files, and bring the system
 back up.
>>>
>>> I don't think this qualifies as "ideal" for migration. My recommendation
>>> is to set up the new server and configure Dovecot replication (see
>>> Wiki).
>>>
>>> If you configured things correctly, migration will happen without
>>> further intervention, and if there is a problem, you can resolve it in
>>> your own time, without damaging the existing server and data.
>>>
>>> -Ralph
>>
>> If your directory structure *and* namespace structure stays the same, you
>> can rsync files over.
>>
>> If you are going to change anything, do as Ralph suggests.
>>
>> Aki
>

Re: Current thinking on backups ?

[deano-dovecot]

I run a pair of dovecot servers for personal small domains with several 
layers of backup in place ...


- The two dovecot servers replicate to each via a Tinc vpn mesh. That 
gives email resiliency.
- All mail is replicated via offlineimap to a 3rd server over that Tinc 
vpn. It's on the mesh, it has space, so why not ?
- All mail is replicated as well as via mbsync to a zfs dataset on my 
main media server at home once an hour.
- That zfs dataset (and others) is snapshot'd hourly, and zfs send/recv 
to a backup box nightly.


Outside of dovecot procedures, I find mbsync to work extremely well.  It 
was easy enough to set up a systemd timer and service to pull the mail 
down.



mysync.timer

# Run the mbsync process to sync mail down to local mediabox

[Unit]
Description=mbsync timer
ConditionPathExists=%h/.mbsyncrc
ConditionPathIsDirectory=/stuff/Backups/Mailsystems/mbsync-backups

[Timer]
OnBootSec=15m
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target


mysync.service
==
# mbsync service

[Unit]
Description=mbsync backup from mailsystems
ConditionPathExists=%h/.mbsyncrc
ConditionPathIsDirectory=/stuff/Backups/Mailsystems/mbsync-backups

[Service]
Type=oneshot
ExecStart=/usr/local/bin/mbsync backup

[Install]
WantedBy=default.target


"backup" is the mbsync group that includes all the defined channels that 
determine what should be backed up.  Transparent.  In the background.  
Don't have to think about it, it's just there.


I've done test restores to test environments via mbsync, and it all 
works flawlessly.



On 2020-05-26 12:31 am, Germain Le Chapelain wrote:
Le 24 mai 2020 à 14:42, Laura Smith 
 a écrit :


Hi,

What are people doing for backups ?
My current process is LVM snapshot and backup from that to NFS share.
But there seems to be hints around the internet that people use/abuse 
"doveadm backup" for backup purposes even though it seems its original 
intention was for transferring mailboxes between dovecot instances.
Assuming its ok to "doveadm backup" to an NFS share, is it ok to use 
"doveadm backup" when dovecot has replication setup 
(replication-notify etc.)  ? Or will it interfere ?

Thanks!
Laura


This has came up in the past:

https://dovecot.org/pipermail/dovecot/2020-February/thread.html#118206

I ended up developing my own system based on forwarding all emails to
a program (from which I back-up as they come in.)

I am hoping if disaster and/or misfortune were to strike my server, I
could simply cat >> back all those files in order (or not come to
think of it) in the /var/mail/ (or somewhere even better fit
in Postfix.)


I am not interested in saving the state of the mailbox as much as all
the mails that ever come in (or go out.)


--
Dean Carpenter
deano is at areyes dot com
203 six oh four 6644

Re: Running doveadm without config file?

[Joseph Tam]

On Fri, 29 May 2020, Sami Ketola wrote:


# echo plaintextpass | doveadm pw -s BLF-CRYPT
doveadm(user): Fatal: Error reading configuration: 
stat(/etc/dovecot/dovecot.conf) failed: No such file or directory

Is there a way to circumvent the need for a configuration file?


I don't think so. But you can specify the location of the config file with -c 
/path/to/file
like

echo -n plaintextpass | doveadm -c /root/emptyfile.conf pw -s SHA1


Thanks, Sami.

I tried this with /dev/null and /tmp/empty.conf but ran into another wall

doveadm(root): Fatal: execv(/usr/bin/doveconf) failed: No such file or 
directory

Joseph Tam 

Re: Running doveadm without config file?

[Sami Ketola]

> On 29. May 2020, at 23.09, Joseph Tam  wrote:
> 
> 
> It would be useful to run the "doveadm" utility on a non-dovecot server e.g.
> generating password hashes:
> 
>   # echo plaintextpass | doveadm pw -s BLF-CRYPT
>   doveadm(user): Fatal: Error reading configuration: 
> stat(/etc/dovecot/dovecot.conf) failed: No such file or directory
> 
> Is there a way to circumvent the need for a configuration file?

I don't think so. But you can specify the location of the config file with -c 
/path/to/file

like

echo -n plaintextpass | doveadm -c /root/emptyfile.conf pw -s SHA1

Sami

Running doveadm without config file?

[Joseph Tam]

It would be useful to run the "doveadm" utility on a non-dovecot server e.g.
generating password hashes:

# echo plaintextpass | doveadm pw -s BLF-CRYPT
doveadm(user): Fatal: Error reading configuration: 
stat(/etc/dovecot/dovecot.conf) failed: No such file or directory

Is there a way to circumvent the need for a configuration file?

Joseph Tam 

Operation not permitted - fchown() failed for /run/dovecot/login

[Dshah]

# dovecot --version
2.3.10.1 (a3d0e1171)

Dovecot is unable to start, I see error " Fatal: fchown() failed for
/run/dovecot/login: Operation not permitted"

what could be the problem?
any help please


$ls -la  /var/mail/
drwxr-xr-x1 root root  4096 May 29 17:32 .
drwxr-xr-x1 root root  4096 May 28 17:08 ..
drw---2 root root  4096 May 29 17:32 domains

# cat /etc/dovecot/dovecot.conf=
auth_mechanisms = plain login
auth_username_format = %Lu
auth_verbose = yes
auth_debug = yes
auth_debug_passwords = no

log_timestamp = "%Y-%m-%d %H:%M:%S "
login_greeting = IMAP server ready

disable_plaintext_auth = no

protocols = imap pop3
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_location = maildir:/var/mail/domains/%d/%n

first_valid_gid = 105
first_valid_uid = 102
last_valid_gid = 105
last_valid_uid = 102

service anvil {
client_limit = 2100
}

ssl_cert = 

Re: migrating dovecot to new server

[Francis Augusto Medeiros-Logeay]

I did what Aki said. Actually I moved it all to a new server and to docker 
containers. From Dovecot 2.2 to 2.3. And it worked fine. Of course one always 
forget something - the path for the certificates, the different directory for 
mounting storage, etc. 

But am surprise and happy that it worked very well. 

__
Francis Augusto Medeiros-Logeay
Oslo, Norway
Sent from a mobile device / Enviado a partir de dispositivo móvel

> On 29 May 2020, at 19:33, Aki Tuomi  wrote:
> 
> 
>> On 29/05/2020 20:12 Ralph Seichter  wrote:
>> 
>> 
>> * David Mehler:
>> 
>>> I'd ideally like to back up all the mails in the maildir location,
>>> copy that over, load in my configuration files, and bring the system
>>> back up.
>> 
>> I don't think this qualifies as "ideal" for migration. My recommendation
>> is to set up the new server and configure Dovecot replication (see Wiki).
>> 
>> If you configured things correctly, migration will happen without
>> further intervention, and if there is a problem, you can resolve it in
>> your own time, without damaging the existing server and data.
>> 
>> -Ralph
> 
> If your directory structure *and* namespace structure stays the same, you can 
> rsync files over.
> 
> If you are going to change anything, do as Ralph suggests.
> 
> Aki

Re: migrating dovecot to new server

[Aki Tuomi]

> On 29/05/2020 20:12 Ralph Seichter  wrote:
> 
>  
> * David Mehler:
> 
> > I'd ideally like to back up all the mails in the maildir location,
> > copy that over, load in my configuration files, and bring the system
> > back up.
> 
> I don't think this qualifies as "ideal" for migration. My recommendation
> is to set up the new server and configure Dovecot replication (see Wiki).
> 
> If you configured things correctly, migration will happen without
> further intervention, and if there is a problem, you can resolve it in
> your own time, without damaging the existing server and data.
> 
> -Ralph

If your directory structure *and* namespace structure stays the same, you can 
rsync files over.

If you are going to change anything, do as Ralph suggests.

Aki

Re: migrating dovecot to new server

[Ralph Seichter]

* David Mehler:

> I'd ideally like to back up all the mails in the maildir location,
> copy that over, load in my configuration files, and bring the system
> back up.

I don't think this qualifies as "ideal" for migration. My recommendation
is to set up the new server and configure Dovecot replication (see Wiki).

If you configured things correctly, migration will happen without
further intervention, and if there is a problem, you can resolve it in
your own time, without damaging the existing server and data.

-Ralph

migrating dovecot to new server

[David Mehler]

Hello,

I'm needing to migrate my dovecot installation it's 2.3 on FreeBSD
12.1 to a new server. I'd ideally like to back up all the mails in the
maildir location, copy that over, load in my configuration files, and
bring the system back up. I doubt it's that easy, any pitfalls I
should watch out for?

Thanks.
Dave.

Re: identify 143 vs 993 clients

[@lbutlr]

On 25 May 2020, at 12:48, mj  wrote:
> I would then ask them to move over to 993, and finally disable port 143 
> altogether.

From personal experience the only way to do this is to stop listening to port 
143. I dropped support for non-encrypted mail ports ages ago, and I didn't get 
a single user to switch from 143 to 993 until I disabled 143.

Send an email to your users "You must make this change bu (date+2 days)" and 
then drop port 143 in 2 days as promised. If you have a web server, but a large 
red box on it "Can't login?" With a link to the email you sent.

(And do not allow users to send mail un-encrypted either, force them to use 587 
or 465 by not accepting user mail on port 25).



-- 
This is Art holding a Mirror up to Life. That's why everything is
exactly the wrong way around. --Wyrd Sisters

Simple backup of maildir folder

[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

Re: identify 143 vs 993 clients

[mj]

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.


Thanks again, valuable insights!

MJ

On 5/29/20 11:48 AM, Jean-Daniel wrote:



Le 29 mai 2020 à 11:17, Stuart Henderson > a écrit :


On 2020-05-26, mj mailto:li...@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


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).

Re: identify 143 vs 993 clients

[Jean-Daniel]

> Le 29 mai 2020 à 11:17, Stuart Henderson  a écrit :
> 
> On 2020-05-26, mj  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 


> 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).

Re: identify 143 vs 993 clients

[Stuart Henderson]

On 2020-05-26, mj  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.

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.