dovecot.list.index.log
HI Is it safe to delete the file dovecot.list.index.log (as I am still struggling with using any protocol for network storage of the emails (dbox), and now dovecot complains that my dovecot.list.index.log is corrupted) Thank you ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot replication
That's a nice suggestion. Thanks John. On Fri, Jul 12, 2024 at 11:25 PM John Fawcett via dovecot wrote: > > > On 12/07/2024 13:05, Jeff Pang via dovecot wrote: > > Hello, > > > > Does the community version of dovecot have the replication feature? > > When one dovecot was down, another one could take over the tasks. > > > > Thanks. > > > > _ > > Jeff > > Replication is in the current dovecot version but will go away in 2.4. > > The doveadm sync feature is staying. So with some work you can set it up > what you are requesting. > > I used to use replication and now I'm thinking about using sync but have > not implemented it. The following are thoughs on it. > > There are some points to be addressed that are outside dovecot. I think > you'd have to make sure that your sync happened frequently enough that > you could live with losing the emails that arrives bewteen syncs for > example. That would tend to lead to a requirement to sync more > frequently and reduce risk of email loss. But then you'd need to avoid > more than one sync being active simultaneously (that is my assumption > that this would not work, but I don't know if it is a real problem). > > The failover would require you to stop people accessing the old server, > stop syncing and start the backup instance. When the main instance is > available to come back on line, you'd need to stop the backup instance, > sync in the opposite direction and then start dovecot and re-enable the > sync mechansim towards the backup. > > You need to ensure people don't connect simultaneously to both > instances. So some thought would be needed about those cases where the > main node goes and then comes backup to ensure that your sync is not > still active at that point and replicates the old state onto the backup > server and to ensure then people don't start connecting to it again > without being able to control it. > > It's a disaster recover rather than high availability solution, but I > think it can work. Others may already have got working implementations > and thought through some of the implications. > > John > > > ___ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-le...@dovecot.org > > _ Your E-Mail. Your Cloud. Your Office. eclipso Mail Europe. https://www.eclipso.de ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot replication
On 12/07/2024 21:14, James Cook wrote: On Fri, Jul 12, 2024 at 06:28:13PM GMT, John Fawcett via dovecot wrote: Hi James I want to avoid the -1 parameter because it doesn't do deletes in the target. -l, not -1. Thanks I missed that - so locking can be done within Dovecot John ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot replication
> On 07/12/2024 1:14 PM MDT James Cook via dovecot wrote: > > On Fri, Jul 12, 2024 at 06:28:13PM GMT, John Fawcett via dovecot wrote: > >Hi James > > > >I want to avoid the -1 parameter because it doesn't do deletes in the > >target. > > -l, not -1. No, it's -1 - as in one(1)-way sync. -l (lowercase L) is for locking. michael ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
doveadm auth lookup fails for system user
Hi all,
next step with my auth problem with dovecot.
I want to authenticate a system user. The user exists, can log in, can
sudo -i etc.pp. SASL with sql passdb and userdb works fine.
root@bywater /etc/dovecot/conf.d # doveadm user qno
field value
uid 1001
gid 1001
home/home/qno
mailmaildir:~/Maildir
system_groups_user qno
But:
root@bywater /etc/dovecot/conf.d # doveadm auth lookup qno
passdb lookup: user qno doesn't exist
And no surprise:
root@bywater /etc/dovecot/conf.d # doveadm auth test qno
Password:
passdb: qno auth failed
extra fields:
user=qno
root@bywater /etc/dovecot/conf.d # doveconf -n
# 2.3.16 (7e2e900c1a): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.16 (09c29328)
# OS: Linux 5.15.0-113-generic x86_64 Ubuntu 22.04.4 LTS
# Hostname: bywater.qno.de
auth_debug = yes
auth_debug_passwords = yes
auth_verbose = yes
auth_verbose_passwords = plain
listen = 65.21.136.15, [::]
mail_location = maildir:~/Maildir
mail_privileged_group = mail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date index ihave duplicate mime foreverypart extracttext
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
args = /etc/dovecot/tables.d/dovecot-sql.conf.ext
driver = sql
}
passdb {
args = blocking=no
driver = passwd
}
passdb {
driver = pam
}
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
}
postmaster_address = postmas...@qno.de
protocols = " imap sieve"
service auth-worker {
user = vmail
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
user = dovecot
}
service imap-login {
inet_listener imap {
port = 143
}
inet_listener imaps {
port = 993
ssl = yes
}
}
service lmtp {
unix_listener lmtp {
group = postfix
mode = 0600
user = postfix
}
}
ssl = required
ssl_cert = ssl_cipher_list =
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
ssl_dh = # hidden, use -P to show it
ssl_key = # hidden, use -P to show it
syslog_facility = local0
userdb {
args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%u
driver = static
}
userdb {
driver = passwd
}
verbose_proctitle = yes
How can it be that a user is found by userdb passwd, but not by passdb
passwd or PAM?
TIA
QNo
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot replication
On Fri, Jul 12, 2024 at 06:28:13PM GMT, John Fawcett via dovecot wrote: Hi James I want to avoid the -1 parameter because it doesn't do deletes in the target. -l, not -1. As for the lda to doveadm sync script, I have been wondering too about how to close the gap for emails arriving between syncs, even though the risk might not be so significant. With delivering to two dovecot servers before accepting the email, either one going down will stop email delivery. I was thinking my script will accept the email anyway if the sync fails. It would do this: 1. Pass to dovecot-lda. If dovecot-lda fails, something is seriously wrong, so stop and fail. 2. Fork a background process that attempts to doveadm sync. 3. Wait for the background process to finish, or a maximum of 2 seconds. Then return success regardless of whether sync worked. This guards against a hard disk crash or filesystem failure on one machine, but falls back to single-homing the email if a server is down. This is inspired by the documentation at https://doc.dovecot.org/configuration_manual/replication/ -- James ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot replication
On 12/07/2024 17:38, James Cook via dovecot wrote: Replication is in the current dovecot version but will go away in 2.4. The doveadm sync feature is staying. So with some work you can set it up what you are requesting. I used to use replication and now I'm thinking about using sync but have not implemented it. The following are thoughs on it. There are some points to be addressed that are outside dovecot. I think you'd have to make sure that your sync happened frequently enough that you could live with losing the emails that arrives bewteen syncs for example. I have been thinking of writing a hacky delivery script that passes the email on to dovecot-lda, then runs doveadm sync, and only returns success after the sync is done (or after a timeout). No idea what problems I will run into, but the idea is to never accept an email until it's guaranteed replicated. That would tend to lead to a requirement to sync more frequently and reduce risk of email loss. But then you'd need to avoid more than one sync being active simultaneously (that is my assumption that this would not work, but I don't know if it is a real problem). Doesn't the -l option protect against simultaneous syncs? Just based on reading the doveadm-sync man page. (I guess it could cause a problem if you start sync processes more quickly than they can finish.) NB I'm just running a one-person email server so don't take my ideas too seriously :) Hi James I want to avoid the -1 parameter because it doesn't do deletes in the target. It might not be an issue, but I'd like to keep the target the same as the source. I don't know if it would protect against simultaneous jobs, but I dont' know even if that is an issue. I was making the assumption it could be so I plan to avoid it somehow. As for the lda to doveadm sync script, I have been wondering too about how to close the gap for emails arriving between syncs, even though the risk might not be so significant. With delivering to two dovecot servers before accepting the email, either one going down will stop email delivery. That's an inconvenience but without necessarily introducing risks for losing the emails. Ultimately it depends on where those undelivered emails are being kept in the meantime (presumably MTA queue) and whether they are safer there than being delivered to a single instance. Though that is related only to the downtime. When both are up the risk would be mitigated by the solution. Other idea I was thinking of is a replicated file system. That could make emails available in real time to both dovecot instances assuming a functionality to sync to disk on both/multiple nodes before replying back to dovecot to accept the email. I believe there would still need to be only one dovecot instance active at a time. However, I have heard of but don't know personally of horror stories about email outages on clustered file systems, which leads me to believe that there would still be sufficient residual risk to require a backup copy of the mailboxes with doveadm sync or other tools. John John ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot replication
Replication is in the current dovecot version but will go away in 2.4. The doveadm sync feature is staying. So with some work you can set it up what you are requesting. I used to use replication and now I'm thinking about using sync but have not implemented it. The following are thoughs on it. There are some points to be addressed that are outside dovecot. I think you'd have to make sure that your sync happened frequently enough that you could live with losing the emails that arrives bewteen syncs for example. I have been thinking of writing a hacky delivery script that passes the email on to dovecot-lda, then runs doveadm sync, and only returns success after the sync is done (or after a timeout). No idea what problems I will run into, but the idea is to never accept an email until it's guaranteed replicated. That would tend to lead to a requirement to sync more frequently and reduce risk of email loss. But then you'd need to avoid more than one sync being active simultaneously (that is my assumption that this would not work, but I don't know if it is a real problem). Doesn't the -l option protect against simultaneous syncs? Just based on reading the doveadm-sync man page. (I guess it could cause a problem if you start sync processes more quickly than they can finish.) NB I'm just running a one-person email server so don't take my ideas too seriously :) -- James ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot replication
On 12/07/2024 13:05, Jeff Pang via dovecot wrote: Hello, Does the community version of dovecot have the replication feature? When one dovecot was down, another one could take over the tasks. Thanks. _ Jeff Replication is in the current dovecot version but will go away in 2.4. The doveadm sync feature is staying. So with some work you can set it up what you are requesting. I used to use replication and now I'm thinking about using sync but have not implemented it. The following are thoughs on it. There are some points to be addressed that are outside dovecot. I think you'd have to make sure that your sync happened frequently enough that you could live with losing the emails that arrives bewteen syncs for example. That would tend to lead to a requirement to sync more frequently and reduce risk of email loss. But then you'd need to avoid more than one sync being active simultaneously (that is my assumption that this would not work, but I don't know if it is a real problem). The failover would require you to stop people accessing the old server, stop syncing and start the backup instance. When the main instance is available to come back on line, you'd need to stop the backup instance, sync in the opposite direction and then start dovecot and re-enable the sync mechansim towards the backup. You need to ensure people don't connect simultaneously to both instances. So some thought would be needed about those cases where the main node goes and then comes backup to ensure that your sync is not still active at that point and replicates the old state onto the backup server and to ensure then people don't start connecting to it again without being able to control it. It's a disaster recover rather than high availability solution, but I think it can work. Others may already have got working implementations and thought through some of the implications. John ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
dovecot replication
Hello, Does the community version of dovecot have the replication feature? When one dovecot was down, another one could take over the tasks. Thanks. _ Your E-Mail. Your Cloud. Your Office. eclipso Mail Europe. https://www.eclipso.de ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot imap_zlib
Hi, I think you should following these steps I am sure they will worked properly and also important to access: 1. Check Documentation and Changelog: Look at the latest Dovecot documentation and changelogs to see if there are any notes about the imap_zlib plugin being moved renamed or deprecated. 2. Rebuild with Plugin: Ensure you have the necessary dependencies installed for zlib and then rebuild Dovecot with plugin support by configuring it explicitly. You can use the configure with zlib option before compiling. 3. Check for Alternative Repositories: Sometimes plugins may be maintained separately. Check if there is an independent repository or branch that includes the imap zlib plugin. 4. Contact Dovecot Community: If the plugin has been removed, consider reaching out to the Dovecot community or mailing list for alternative solutions or to understand the reason for its removal. this sounds like a ChatGPT answer. What's the purpose of it? Regards ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot imap_zlib
Hi, I think you should following these steps I am sure they will worked properly and also important to access: 1. Check Documentation and Changelog: Look at the latest Dovecot documentation and changelogs to see if there are any notes about the imap_zlib plugin being moved renamed or deprecated. 2. Rebuild with Plugin: Ensure you have the necessary dependencies installed for zlib and then rebuild Dovecot with plugin support by configuring it explicitly. You can use the configure with zlib option before compiling. 3. Check for Alternative Repositories: Sometimes plugins may be maintained separately. Check if there is an independent repository or branch that includes the imap zlib plugin. 4. Contact Dovecot Community: If the plugin has been removed, consider reaching out to the Dovecot community or mailing list for alternative solutions or to understand the reason for its removal. Thanks ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
