Re: pop3-login logging double Disconencted
On 26 January 2022 4.08.04 UTC, Noel Butler wrote: >Hi all, > >Wondering if anyone else is seeing this double Disconnected in the logs >with current stable version, it only happens for pop3-login, and only >with Too many commands... other pop3-login logging with Disconnected >like Connection closed (no auth attempts... etc are fine > >Example of anomaly - > >pop3-login: Info: Disconnected: Disconnected: Too many bad commands (no >auth attempts in ... > >If anyone running 2.3.17.1 sees this or does not see it on Too many >bad... or at all, kindly mind letting me know, not sure if something has >gone haywire here or its a bug that needs reporting since logs indicate >this only occurred after updating to the point 1 release. > That looks a lot like non-pop3 client trying to use pop3 port. The logging thing is likely a bug. We'll take a look. Aki
pop3-login logging double Disconencted
Hi all, Wondering if anyone else is seeing this double Disconnected in the logs with current stable version, it only happens for pop3-login, and only with Too many commands... other pop3-login logging with Disconnected like Connection closed (no auth attempts... etc are fine Example of anomaly - pop3-login: Info: Disconnected: Disconnected: Too many bad commands (no auth attempts in ... If anyone running 2.3.17.1 sees this or does not see it on Too many bad... or at all, kindly mind letting me know, not sure if something has gone haywire here or its a bug that needs reporting since logs indicate this only occurred after updating to the point 1 release. -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message.
Re: Received invalid SSL certificate: unable to get certificate CRL
‐‐‐ Original Message ‐‐‐ > > I thought that > > ssl_ca = > is worth a try. Does ssl_ca even apply to dsync/imapc ? Looking at the docs its all about client certificate authentication ? Something which does not apply to my environment, and even if it did, it would not apply to dsync/imapc because I am initiating the connection, not the remote end ?
Re: Received invalid SSL certificate: unable to get certificate CRL
Hi Laura, On 25.01.22 11:48, Laura Smith wrote: Thanks for your suggestion, I have a couple of questions about it though. > First, my understanding from the docs was that ssl_client_ca_* were override parameters and that in the absence of the parameters, Dovecot would default to using OpenSSL defaults ? (And building on that, as per my manual tests, you can see OpenSSL returns an "OK" on the validation). To be honest: I dont have a setup like yours to test it. I just remembered a mail from Aki in which he mentioned this part of the documentation and so I thought that ssl_ca = Second, I'm dealing with standard Let's Encrypt certs here, no private PKI certs here. Yes, I know. And it seems, that all is fine with them. Regards, Markus
RE: silly quesiton
> > Marc> Why? Just disallow login, and that is from the perspective that > Marc> a mail user should be limited mail resources. > >> > >> If the user does NOT need to login to the dovecot/mail servers, then > >> not having these users at all is more secure. > > Marc> No, because there is a difference between a need to login and > Marc> the presence of a uid. Lots of daemons run under accounts that > Marc> cannot login. > > > You're missing my point. Yes, the daemons running the services are > locked down. But the users using those services have no need to for > logins or access to the system. I am not missing the point. I am stating that it is very common to have users that are limited, nothing more nothing less. > They only need access to the > application. Incorrect, they also need to have access the file system. and if I process is spawned under the uid of the logged in user, then only those files having those uid's are available. So if there is some sort of problem in the code of the spawned process it is only limited to the current uid environment. > That's why virtual users are good. That is why the use of tooth paste is good! > Also, UIDs used to be limited to > under 65,000 seperate logins, but early on large FTP and ISP sites > disovered that they wanted to have more user than that, so moving to > virtual users was the solution. Again not relevant for the discussion > Marc> 1. if a user does not exist on the os, how can processes be > Marc> spawned as these uid's. Everything is running under the same > Marc> uid. > > Yes, the daemons/applications running the service being provided runs > under a single UID. Which is more secure becuase now you have just > one UID to lock down tight, using apparmour, selinux or other OS level > tools. Indeed so if you argue the running under separate uid's is more secure. How can you also argue exactly the opposite that running all virtual users as a single uid is more secure. These statements are contradictory. > Marc> 2. if you do not use separate users, everything is written under > Marc> the same uid. > > So? So if something is wrong with your application. Say a user can escape, all other users data are available. if the process runs under the uid, even if the user can escape it somehow, the linux os will limit this user to the files it is owning. > Marc> 3. most amateurs use a crappy mysql as backend for virtual > Marc> users. The likelihood of that being compromised compared to the > Marc> linux os is much and much higher. > > How would it be compromised? What makes you think that the backend > database is even exposed to the internet at all? In a smart setup, > it's configured so that only local access works, or only access from a > restricted set of IPs with restricted logins is allowed access. Is not relevant. > Marc> 4. Say you are more professional and setup an ldap server (with > Marc> correct acls (which is not trivial at all)) If you would have > Marc> dovecot use it as a backend for virtual users. Does dovecot > Marc> relay that user auth information or does it need some static > Marc> bind. The static bind is already an increased attack > Marc> surface. Better is have the os use the ldap backend and have > Marc> dovecot use the os. > > The static bind is fine, because you do not bind to AD as a root user, > but only as a user with the minimum needed access to do the queries. Incorrect, a static bind requires more privileges (searching acl etc) then simple auth request, ofter also on a lower ssf. But you are missing the most important point here. > Marc> 5. I would even argue that having dovecot 'outsource' the user > Marc> management to the linux os is more secure. Because dovecot > Marc> developers are more experienced in programming the email > Marc> application and have far less experience with authorization, > Marc> authentication than the linux developers. There is much more > Marc> scrutiny on the linux os than the dovecot user system. > > You really don't know how authentication and access to IMAP mailboxes > works, do you? I think my knowledge exceeds yours, although I do not see myself as an expert. > And how postfix submission port works. How is this relevant > Regular port > 25 SMTP traffic doesn't have access controls, but it's also not where > you accept email that gets sent to other domains, you only accept > email for your destination domains. How is this relevant > Submission port 587, for accepting outgoing email to be sent outside > your your domain, needs and requires authentication. It's part of the > specs that mail clients need to implement properly. How is this relevant > > Marc> You constantly apply incorrect logic. You think that "keeping > Marc> them off the server entirely" equals virtual user. "keeping them > Marc> off the server entirely" also includes /sbin/nologin. According > Marc> to your incorrect logic’s, you support my statement because in > Marc> my
Re: silly quesiton
> On 01-25-2022 11:35 am, Marc wrote: > 2. if you do not use separate users, everything is written under the same uid. IMO: So what? What is the difference between a linux user vs a virtual user permission wise? They are both equally unprivileged users. If dovecot can get to them, virtual or linux user, then a hacked dovecot can still get to them. You aren't saving anything. Dovecot can also be configured to use virtual users from a database, and each virtual user be assigned a different UID for reading/writing maildir files. > 3. most amateurs use a crappy mysql as backend for virtual users. > The likelihood of that being compromised compared to the linux os is much and > much higher. Even if SQL is compromised you aren't storing emails in SQL, just email addresses and passwords. That is why password hashing exist. If SQL is configured to only localhost connections then it is not getting compromised, unless your entire server is compromised, in which case SQL access is moot because they can just get the maildir files. I also doubt that gmail, outlook and yahoo have separate linux users for their millions of email accounts. I have not heard of a massive email breach where hackers gained access to all gmail messages. Saying all that, it is your server, do with it how you please. People here on the list are just telling you what is acceptable safe practice industry wide. Another drawback to using linux users is you will never be able to cluster/scale up. But if your preference is to use linux users go for it.
RE: silly quesiton
> "Marc" == Marc writes: Marc> Why? Just disallow login, and that is from the perspective that Marc> a mail user should be limited mail resources. >> >> If the user does NOT need to login to the dovecot/mail servers, then >> not having these users at all is more secure. Marc> No, because there is a difference between a need to login and Marc> the presence of a uid. Lots of daemons run under accounts that Marc> cannot login. You're missing my point. Yes, the daemons running the services are locked down. But the users using those services have no need to for logins or access to the system. They only need access to the application. That's why virtual users are good. Also, UIDs used to be limited to under 65,000 seperate logins, but early on large FTP and ISP sites disovered that they wanted to have more user than that, so moving to virtual users was the solution. Marc> I argue exactly the opposite. Keep as much as possible linux Marc> users. As linux has been engineered for allowing multiple user Marc> accounts, and most other virtual user providers that are used Marc> here, have not. >> >> I'm having a hard time to parse what you are saying here. >> >> I'm saying that if the mail/dovecot server is only providing mail >> services, then putting all the users (across multiple domains even) >> into a virtual user database is more secure Marc> No it is not more secure, eg. Marc> 1. if a user does not exist on the os, how can processes be Marc> spawned as these uid's. Everything is running under the same Marc> uid. Yes, the daemons/applications running the service being provided runs under a single UID. Which is more secure becuase now you have just one UID to lock down tight, using apparmour, selinux or other OS level tools. Marc> 2. if you do not use separate users, everything is written under Marc> the same uid. So? Marc> 3. most amateurs use a crappy mysql as backend for virtual Marc> users. The likelihood of that being compromised compared to the Marc> linux os is much and much higher. How would it be compromised? What makes you think that the backend database is even exposed to the internet at all? In a smart setup, it's configured so that only local access works, or only access from a restricted set of IPs with restricted logins is allowed access. Marc> 4. Say you are more professional and setup an ldap server (with Marc> correct acls (which is not trivial at all)) If you would have Marc> dovecot use it as a backend for virtual users. Does dovecot Marc> relay that user auth information or does it need some static Marc> bind. The static bind is already an increased attack Marc> surface. Better is have the os use the ldap backend and have Marc> dovecot use the os. The static bind is fine, because you do not bind to AD as a root user, but only as a user with the minimum needed access to do the queries. Marc> 5. I would even argue that having dovecot 'outsource' the user Marc> management to the linux os is more secure. Because dovecot Marc> developers are more experienced in programming the email Marc> application and have far less experience with authorization, Marc> authentication than the linux developers. There is much more Marc> scrutiny on the linux os than the dovecot user system. You really don't know how authentication and access to IMAP mailboxes works, do you? And how postfix submission port works. Regular port 25 SMTP traffic doesn't have access controls, but it's also not where you accept email that gets sent to other domains, you only accept email for your destination domains. Submission port 587, for accepting outgoing email to be sent outside your your domain, needs and requires authentication. It's part of the specs that mail clients need to implement properly. >> and more scalable. Marc> Not relevant, that is different discussion. >> General users don't need accounts on the mail server, and security in >> depth argues that keeping them off the server entirely is a good >> thing. >> Marc> You constantly apply incorrect logic. You think that "keeping Marc> them off the server entirely" equals virtual user. "keeping them Marc> off the server entirely" also includes /sbin/nologin. According Marc> to your incorrect logic’s, you support my statement because in Marc> my case users are kept off. Again, you're not being clear here. Marc> If your logic’s is incorrect, how can your conclusion be Marc> correct? Repeating this does not make it true, the alternative Marc> is far worse. You're telling me my logic is broken, but I keep giving you reasons why I stand by my assertion that having virtual users is more secure, because it lowers the attack surface. Marc> Linux always does a better job on permissions, users, Marc> authentication than whatever 3rd party software. And if you Marc> outsource this to linux you have even more possibilities by Marc> using selinux rules. You need to think of security happening in layers. Keeping users
RE: silly quesiton
> Marc> Why? Just disallow login, and that is from the perspective that > Marc> a mail user should be limited mail resources. > > If the user does NOT need to login to the dovecot/mail servers, then > not having these users at all is more secure. No, because there is a difference between a need to login and the presence of a uid. Lots of daemons run under accounts that cannot login. > Marc> I argue exactly the opposite. Keep as much as possible linux > Marc> users. As linux has been engineered for allowing multiple user > Marc> accounts, and most other virtual user providers that are used > Marc> here, have not. > > I'm having a hard time to parse what you are saying here. > > I'm saying that if the mail/dovecot server is only providing mail > services, then putting all the users (across multiple domains even) > into a virtual user database is more secure No it is not more secure, eg. 1. if a user does not exist on the os, how can processes be spawned as these uid's. Everything is running under the same uid. 2. if you do not use separate users, everything is written under the same uid. 3. most amateurs use a crappy mysql as backend for virtual users. The likelihood of that being compromised compared to the linux os is much and much higher. 4. Say you are more professional and setup an ldap server (with correct acls (which is not trivial at all)) If you would have dovecot use it as a backend for virtual users. Does dovecot relay that user auth information or does it need some static bind. The static bind is already an increased attack surface. Better is have the os use the ldap backend and have dovecot use the os. 5. I would even argue that having dovecot 'outsource' the user management to the linux os is more secure. Because dovecot developers are more experienced in programming the email application and have far less experience with authorization, authentication than the linux developers. There is much more scrutiny on the linux os than the dovecot user system. > and more scalable. Not relevant, that is different discussion. > General users don't need accounts on the mail server, and security in > depth argues that keeping them off the server entirely is a good > thing. > You constantly apply incorrect logic. You think that "keeping them off the server entirely" equals virtual user. "keeping them off the server entirely" also includes /sbin/nologin. According to your incorrect logic’s, you support my statement because in my case users are kept off. If your logic’s is incorrect, how can your conclusion be correct? Repeating this does not make it true, the alternative is far worse. Linux always does a better job on permissions, users, authentication than whatever 3rd party software. And if you outsource this to linux you have even more possibilities by using selinux rules.
Re: sieve-filter ignores -u argument
Hm, looks like I misunderstood initial error sieve-filter(root): Fatal: Unknown user filter-sieve do not understand -u postma...@domain.tld Where (root) is about who runs the command, not who is not found Anyway I've tried # cd /var/vmail/vmail1/domain.tld/t/e/s/test-2022.01.22.05.55.26/sdbox/mailboxes/ #sieve-filter -c /etc/dovecot/dovecot.conf -v /var/vmail/sieve/dovecot.sieve INBOX sieve-filter(root): Error: stat(/root/Maildir/tmp) failed: Permission denied (euid=2000(vmail) egid=2000(vmail) missing +x perm: /root, dir owned by 0:0 mode=0700) sieve-filter(root): Fatal: Couldn't open source mailbox 'INBOX': Internal error occurred. Refer to server log for more information. [2022-01-25 14:46:35] sudo -u vmail sieve-filter -c /etc/dovecot/dovecot.conf -v /var/vmail/sieve/dovecot.sieve INBOX sieve-filter(vmail): Info: Mailbox created: INBOX /home/vmail/Maildir was created after that and not in the current directory I've tried '-u test', '-u t...@domain.tld', '-u t...@mail.domain.tld' and passed config '-c /etc/dovecot/dovecot.conf.' And still got Fatal: Unknown user How do sieve-filters understand virtual users? вт, 25 янв. 2022 г. в 18:31, Eric Wood : > I read the sieve-filter man page so I'll speculate. Granted, I still > don't fully understand how sieve and virtual users work as I have never set > this up. > > "postmaster" is an alias of root and "vmail" is probably just a directory > name. So, from the root's command prompt, the environment variables > probably aren't totally set up for sieve-filter to understand virtual users. > > So, working from the command prompt, you probably have to explicitly > specify the .sieve path and leave off the -u argument > > # cd /location_of_virtual_user_INBOX > # sieve-filter -v /opt/some_global_rules/sieve/managesieve.sieve INBOX > > Would is be great if seive-filter had an argument to understand the > system's virual user's settings? Of course. I don't know why the > developer haven't included it. > > -Eric > > On 1/24/2022 7:59 AM, Андрей Куницын wrote: > > Hello > I try to test my sieve script, but found out that it is impossible to use > a sieve-filter tool with virtual mail users. It always uses a real user > name instead of passed via -u argument. > > > # sieve-filter -v -u postmas...@domain.tld ~/sieve/managesieve.sieve > INBOX > sieve-filter(root): Fatal: Unknown user > > sudo -u vmail sieve-filter -u postmas...@domain.tld > ~/sieve/managesieve.sieve INBOX > sieve-filter(vmail): Fatal: Unknown user > > Also there is the same question on serverfault, but without an answer. > > https://serverfault.com/questions/1055407/how-to-make-sieve-filter-use-virtual-users > > My environment is Ubuntu 20.04 > dovecot --version > 2.3.7.2 (3c910f64b) > > -- > Sincerely, Andrey Kunitsyn > > > -- С уважением, Куницын Андрей.
Re: sieve-filter ignores -u argument
On 2022-01-25 14:31, Eric Wood wrote: sudo -u vmail sieve-filter -u postmas...@domain.tld ~/sieve/managesieve.sieve INBOX sieve-filter(vmail): Fatal: Unknown user ~ is the users HOME dir, if -u is defined it possible could be another user so make sure shell define $(HOME) in dovecot auth i am not dovecot expert sorry read "as home" https://serverfault.com/questions/896236/getting-error-with-dovecot-when-authenticating-user-home-directory-not-set-for
Re: sieve-filter ignores -u argument
Hello What do you get for doveadm user postmas...@domain.tld Kind regards, Christian Mack Am 24.01.22 um 13:59 schrieb Андрей Куницын: > Hello > I try to test my sieve script, but found out that it is impossible to use a > sieve-filter tool with virtual mail users. It always uses a real user name > instead of passed via -u argument. > > > # sieve-filter -v -u postmas...@domain.tld ~/sieve/managesieve.sieve INBOX > sieve-filter(root): Fatal: Unknown user > > sudo -u vmail sieve-filter -u postmas...@domain.tld > ~/sieve/managesieve.sieve INBOX > sieve-filter(vmail): Fatal: Unknown user > > Also there is the same question on serverfault, but without an answer. > https://serverfault.com/questions/1055407/how-to-make-sieve-filter-use-virtual-users > > My environment is Ubuntu 20.04 > dovecot --version > 2.3.7.2 (3c910f64b) > -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature
RE: silly quesiton
> "Marc" == Marc writes: >> So just to be clear, each user has a login on your mail server in >> /etc/passwd? If so, I would strongly urge you to move to using only >> virtual users on your mail infrastructure. >> Marc> Why? Just disallow login, and that is from the perspective that Marc> a mail user should be limited mail resources. If the user does NOT need to login to the dovecot/mail servers, then not having these users at all is more secure. Marc> I argue exactly the opposite. Keep as much as possible linux Marc> users. As linux has been engineered for allowing multiple user Marc> accounts, and most other virtual user providers that are used Marc> here, have not. I'm having a hard time to parse what you are saying here. I'm saying that if the mail/dovecot server is only providing mail services, then putting all the users (across multiple domains even) into a virtual user database is more secure and more scalable. General users don't need accounts on the mail server, and security in depth argues that keeping them off the server entirely is a good thing. John
Re: Received invalid SSL certificate: unable to get certificate CRL
For the benefit of list, I've decided to work-around the problem using: imapc_ssl_verify = no Obviously I still welcome suggestions as to how I can get dsync working with Let's Encrypt certificates and when OpenSSL validates "ok" but Dovecot does not (despite Dovecot supposedly falling-back to OpenSSL). For the record, I have done this sort of dsync before (i.e. "dsync backup" from source that has Let's Encrypt cert), I've never had a problem before, so I'm wondering if it's something peculiar to Dovecot 2.3.17.1 (whether a bug or a feature, it would be nice to know what's changed since I would have thought this sort of scenario should work "out of the box").
Re: Sync via ssh fails when ssl is active
Hello Am 20.01.22 um 16:32 schrieb Johan: > > Jan 20 16:13:09 doveadm: Error: doveconf: Fatal: Error in configuration > file /etc/dovecot/conf.d/10-ssl.conf line 16: ssl_cert: Can't open file > /etc/letsencrypt/live/delta.oxyl.net/fullchain.pem: Permission denied Check permission on /etc/letsencrypt/live/delta.oxyl.net/fullchain.pem Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature
Re: sieve-filter ignores -u argument
I read the sieve-filter man page so I'll speculate. Granted, I still don't fully understand how sieve and virtual users work as I have never set this up. "postmaster" is an alias of root and "vmail" is probably just a directory name. So, from the root's command prompt, the environment variables probably aren't totally set up for sieve-filter to understand virtual users. So, working from the command prompt, you probably have to explicitly specify the .sieve path and leave off the -u argument # cd /location_of_virtual_user_INBOX # sieve-filter -v /opt/some_global_rules/sieve/managesieve.sieve INBOX Would is be great if seive-filter had an argument to understand the system's virual user's settings? Of course. I don't know why the developer haven't included it. -Eric On 1/24/2022 7:59 AM, Андрей Куницын wrote: Hello I try to test my sieve script, but found out that it is impossible to use a sieve-filter tool with virtual mail users. It always uses a real user name instead of passed via -u argument. # sieve-filter -v -u postmas...@domain.tld ~/sieve/managesieve.sieve INBOX sieve-filter(root): Fatal: Unknown user sudo -u vmail sieve-filter -u postmas...@domain.tld ~/sieve/managesieve.sieve INBOX sieve-filter(vmail): Fatal: Unknown user Also there is the same question on serverfault, but without an answer. https://serverfault.com/questions/1055407/how-to-make-sieve-filter-use-virtual-users My environment is Ubuntu 20.04 dovecot --version 2.3.7.2 (3c910f64b) -- Sincerely, Andrey Kunitsyn
Re: silly quesiton
On January 24, 2022 1:33:46 PM AKST, John Stoffel wrote: >steph> 1) How can I says sendmail to use the same passwd file ( with MD5) than >dovecot ? > >Ah... just saw this. And I don't know how to configure sendmail for >this. I would suggest you look on the sendmail.org site for help. Too many professional bulk mailers on all those lists. I for one don't like the documentation runaround. There's a lot of stuff that's getting more complicated than it needs to be. I need SPF+DKIM+DMARC for basic spam control. >steph> 2) Ideally, I would like to create virtual users for the same >steph> mailbox Is that possible ? I have a setup like that myself. Nothing to do with Dovecot. It's entirely up to postfix which mailbox to deliver incoming messages to, and the user's client to address outgoing mail with a proper ID. >steph> like 2 files Users and PAsswrds pointing out the mailbox : >steph> maildir :/home/mailbox/user1 ex : us...@foo.com passwrd1 >steph> /home/mailbox/generic_mails and user2 passwrd2 >steph> home/mailbox/generic_mails > >I do this myself using postfix and dovecot and it works well. I have >my users defined in an sqlite3 DB, though for a small number of users >I think a flat file is simpler. The performance of flat files really bogs down my system and causes me to lose mails if too many arrive or if the file grows too large. >The trick is to have the dovecot and postfix/sendmail using the same >files for the virtual users and their passwords. There are a number >of tutorials out there for doing this. > >John Without a doubt there are many useful tricks and tutorials out there. I have found several very helpful. Maybe a future programming project idea: I want a system that will store all mail messages and user account info in, say, a postgresql transactional database, a little more manageable and reliable than ad hoc databasing with those flat files all over the place cluttering up the system. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: noob maildir question
Hi John I've been using courier-imap for several years in a relatively small reality with about twenty users, in view of a migration from real box to a virtual server I'm exploring dovecot as a possible alternative. I am used to stopping the service at night simply to make backups and archiving with a consistent situation in the filesystem, not the best solution but my skills are not so strong :) ‐‐‐ Original Message ‐‐‐ Il lunedì 24 gennaio 2022 2:42 PM, John Stoffel ha scritto: > mikfum> thanks John for the reply > > No problem! I'm not an expert by any stretch, but I've been using > > dovecot for years and doing It for way too many years... LOL! > > mikfum> what I would like to do is implement an autoarchive function > > mikfum> at server level that, in the night while dovecot is down, > > mikfum> moves messages older than n days from the user inbox to a > > mikfum> subfolder of the same user (cur to cur) > > Why do you bring dovecot down? What maintenance are you running them? > > I'm curious because I never reboot my dovecot instance unless there's > > a problem. And these days, if you are running a business providing > > email service, it seems better to run a cluster of dovecot servers > > behind dovecot director to load balance things. > > I also feel that using the doveadm commands to do this work is the > > better way, since it will properly handle locking and consistency of > > the folder(s). > > Why do you think that doing this with dovecot is down is the best way > > to do this? > > John
Re: Received invalid SSL certificate: unable to get certificate CRL
> just an idea, but maybe that's the problem?: > > https://doc.dovecot.org/configuration_manual/authentication/proxies/ > > "Note > > ssl_client_ca_dir or ssl_client_ca_file aren’t currently used for verifying > the > > remote certificate, although ideally they will be in a future Dovecot > version. For > > now you need to add the trusted remote certificates to ssl_ca." > Hi Markus Thanks for your suggestion, I have a couple of questions about it though. First, my understanding from the docs was that ssl_client_ca_* were override parameters and that in the absence of the parameters, Dovecot would default to using OpenSSL defaults ? (And building on that, as per my manual tests, you can see OpenSSL returns an "OK" on the validation). Second, I'm dealing with standard Let's Encrypt certs here, no private PKI certs here. Laura
Re: Fwd: Dsync replication - delayed replication (Sync lock)
Hi, we have the same issue and the same configuration except for Dovecot version, ours is the latest into Dovecot repo; in addition we do not have DNS round robin. Does anybody have a solution? Kind regards On 07/09/20 15:53, Daniel Botting wrote: Dear Sirs, Further to my last email have any list members seen this before and are able to offer advice on how to resolve this please. I should note as well that we are running Dovecot from the upstream Debian packages at https://repo.dovecot.org/ce-2.3-latest/debian/buster . Kind regards Daniel Forwarded Message Subject:Dsync replication - delayed replication (Sync lock) Date: Tue, 1 Sep 2020 16:17:15 +0100 From: Daniel Botting To: dovecot@dovecot.org Hi, *Our setup:* Two Debian 10 machines that are setup to replicate mail between them, we have round robin DNS setup so a user can connect to either server. *What should happen:* Mail is delivered to either server and replicated across straight away to their mailbox on the other server so it does not matter which one they are connected to they will receive it fairly soon after delivery. *What actually happens:* In some instances the user will experience a delayed receipt of messages if they are not connected to the server that the message is initially delivered to, sometimes the delay is 5/10 minutes, we had a recent support ticket submitted where it was over an hour. Error message seen in mail.err: Sep 1 10:16:15 dovecot: dsync-local(): Error: Couldn't lock /path/to/mailbox/.dovecot-sync.lock: fcntl(/path/to/mailbox/.dovecot-sync.lock, write-lock, F_SETLKW) locking failed: Timed out after 30 seconds (WRITE lock held by pid 3697) Process 3697 is dovecot/doveadm-server. *Doveconf -n output:* # 2.3.10.1 (a3d0e1171): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.10 (67bf5bd7) # OS: Linux 4.19.0-10-amd64 x86_64 Debian 10.5 # Hostname: auth_verbose = yes default_vsz_limit = 0 doveadm_password = # hidden, use -P to show it first_valid_gid = 8 first_valid_uid = 8 last_valid_gid = 8 last_valid_uid = 8 lda_mailbox_autocreate = yes lda_mailbox_autosubscribe = yes mail_gid = 8 mail_location = maildir:~/Maildir mail_plugins = " notify replication" mail_uid = 8 managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex im ap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext editheader imapfla gs 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/dovecot-ldap.conf.ext driver = ldap } plugin { mail_replica = tcps:: sieve = ~/.dovecot.sieve sieve_dir = ~/sieve sieve_extensions = +editheader +imapflags } postmaster_address = postmaster@ protocols = " imap sieve pop3" replication_max_conns = 12 service aggregator { fifo_listener replication-notify-fifo { user = mail } unix_listener replication-notify { user = mail } } service auth { unix_listener /var/run/dovecot-exim-bridge { mode = 0660 user = Debian-exim } } service doveadm { inet_listener { port = ssl = yes } } service imap-login { inet_listener imap { port = 143 } } inet_listener imaps { port = 993 ssl = yes } process_limit = 512 process_min_avail = 4 service_count = 1 } service imap { process_limit = 1024 } service managesieve-login { inet_listener sieve { port = } process_min_avail = 1 service_count = 8 vsz_limit = 256 M } service managesieve { process_limit = 1024 } service replicator { process_min_avail = 1 unix_listener replicator-doveadm { mode = 0666 } } ssl = required ssl_cert = smime.p7s Description: S/MIME Cryptographic Signature
RE: silly quesiton
> So just to be clear, each user has a login on your mail server in > /etc/passwd? If so, I would strongly urge you to move to using only > virtual users on your mail infrastructure. > Why? Just disallow login, and that is from the perspective that a mail user should be limited mail resources. I argue exactly the opposite. Keep as much as possible linux users. As linux has been engineered for allowing multiple user accounts, and most other virtual user providers that are used here, have not.
Re: Received invalid SSL certificate: unable to get certificate CRL
Hi Laura, On Mon, 24 Jan 2022 at 08:25:12PM +, Laura Smith wrote: I'm having a frustrating problem trying to use "doveadm sync" to pull mails off a server for migration purposes. # 2.3.17.1 (476cd46418): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.17.1 (a1a0b892) # OS: Linux 5.10.0-11-amd64 x86_64 Debian 11.2 I have tried both explicit "ssl_client_ca_dir = /etc/ssl/certs" and commenting it out (i.e. relying on OpenSSL default per the docs) I always get the same: Info: Received invalid SSL certificate: unable to get issuer certificate: /C=US/O=Internet Security Research Group/CN=ISRG Root X1 (check ssl_client_ca_* se ttings?) just an idea, but maybe that's the problem?: https://doc.dovecot.org/configuration_manual/authentication/proxies/ "Note ssl_client_ca_dir or ssl_client_ca_file aren’t currently used for verifying the remote certificate, although ideally they will be in a future Dovecot version. For now you need to add the trusted remote certificates to ssl_ca." Regards, Markus