Re: virtual user list in a passwd file (without linux user)
Hi Paul, On 22.03.24 22:38, p...@virtuadv.com wrote: So, I got it to work by following your suggestion (2). I'm glad to hear that it works - thank you for the feedback! :) # removed all domains that were already in virtual_mailbox_domains mydestination = localhost.$mydomain, localhost That's good because a domain can only be either in mydestination or in virtual_mailbox_domains. Now on to DKIM... Good luck and regards :) Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: virtual user list in a passwd file (without linux user)
Hi Paul, On Fri, 22 Mar 2024 at 02:58:00AM -, p...@virtuadv.com wrote: 1. I got the yahoo/gmail solved but my emails go to their spam... I will try to add DKIM and DMARC next to see if it helps. yes, and if it not already exists: an SPF record is also helpful. 2. I am trying different ways to create those abuse and postmaster emails for all my web sites with the least amount of email accounts. I think aliases worked for site1 when I added: ~~~ postmaster: postmas...@site1.com abuse: postmas...@site1.com ~~~ Please remember that /etc/aliases (alias_maps) has aliases that apply only for local recipients on the machine itself. But I am having trouble forwarding the other sites to site1 in order to have only one email account for all these. I tried different things and the latest I tried is by adding this in file virtual: ~~~ ab...@site2.com abuse postmas...@site2.com postmaster ab...@site3.com abuse postmas...@site3.com postmaster ~~~ It seems like it is trying to send to postmas...@mail.site1.com which dovecot does not find, and it discards those emails. Not sure what is the easiest way of doing this. Yes, if you only use 'postmaster' in virtual it will expand to this address as you have 'mydomain = mail.site1.com', and so Dovecot cannot find it. I'd suggest the following, based on your current config: (1) Extend your main.cf -> virtual_alias_maps this way: virtual_alias_maps = hash:/etc/postfix/virtual, pcre:/etc/postfix/virtual_rfc (BTW, I suggest to use 'hash' instead of 'texthash' you used as with the former Postfix is able to automatically detect changes of these maps and a 'Postfix reload' isn't necessary.) In virtual_rfc something like this: /^postmaster@/ postmas...@site1.com /^abuse@/ postmas...@site1.com /^hostmaster@/ postmas...@site1.com /^webmaster@/ postmas...@site1.com (Hint: in contrast to hashed tables (see above) pcre lookup tables are simple text files, so you have to do a 'Postfix reload' after changing them.) or (2) Alternatively and instead of such a pcre map you could still use: virtual_alias_maps = hash:/etc/postfix/virtual and put all these aliases in the virtual file: ab...@site1.com postmas...@site1.com ab...@site2.com postmas...@site1.com postmas...@site2.compostmas...@site1.com ab...@site3.com postmas...@site1.com postmas...@site3.compostmas...@site1.com ab...@site4.com postmas...@site1.com postmas...@site4.compostmas...@site1.com [...] --> after editing of course a 'postmap /etc/postfix/virtual' It depends on the number of domains which option is less expensive. As this all is mostly MTA/Postfix related and so quite off-topic here maybe it's better to switch to direkt e-mail if we have to look at it further? Best regards, Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: virtual user list in a passwd file (without linux user)
Hi Paul, thanks for the information last week and today. I was/am quite busy and couldn't reply earlier. On 21.03.24 16:04, p...@virtuadv.com wrote: It took me a while to understand that smtpd parameters affect both incoming and outgoing mail, and in my case, they need to be different. I needed to override the parameters from main.cf. In case someone is having similar issues, I was able to fix my in/out mails by changing the following in master.cf: ~~~ # port 25 incoming mail from other servers smtp inet n - y - - smtpd -v -o smtpd_relay_restrictions=defer_unauth_destination -o smtpd_recipient_restrictions=permit_auth_destination,reject # port 587 outgoing mail from thunderbird client submission inet n - y - - smtpd -v -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated -o smtpd_helo_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject -o smtpd_recipient_restrictions=permit_sasl_authenticated just in case you're interested in, here's a snippet of my master.cf: # == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (no)(never) (100) # == smtp inet n - y - - smtpd [...] ## ### ### STARTTLS, port 587 ### submission inet n - y - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_sasl_security_options=noanonymous -o broken_sasl_auth_clients=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_relay_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject ## ### ### SMTPS, port 465 ### smtps inet n - y - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_sasl_security_options=noanonymous -o broken_sasl_auth_clients=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_relay_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject [...] In my case all the restrictions for port 25 are in main.cf. And in general I don't offer client authentication on port 25 but use it only for mail transfer from/to other MTAs. Two questions: 1) Did you get your sending problem to yahoo/gmail solved? 2) What's exactly the problem with this?: ~~~ Now I am trying to get postfix/dovecot to get my internal mail from/to postmaster & root. Right now I have this in my file 'aliases': ~~~ postmaster:root ~~~ Your /etc/aliases looks good. Are there any errors while sending/receiving mails to/for these aliases? What does not work and in which cases? Best regards, Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Bug/Warning not sure which
As Aki wrote: In that tune, due to a bug in mailman, some of the recent mails have failed to make it to the list, so if you have sent a mail after 3rd of March (last seen mail in the archive), you may want to send it again. and as my mail (March 3rd) couldn't be found in the archive, here it is again - just to be safe: Hi Richard, On 24.02.24 22:38, Richard Shetron wrote: I've always used mail.sgeinc.com as my incoming and outgoing server. At various times mail has been an alias for another machine. It's currently on the same address as sge.sgeinc.com. On the update forced on us on 2/22/24 or 2/23/24 it stopped working. It still works as an outgoing server but incoming POP3 it stopped working. It started working when I changed my incoming server to sge.sgeinc.com. unfortunately you didn't send the Dovecot logs. But anyway - I did the following tests: (1) $ host mail.sgeinc.com mail.sgeinc.com has address 159.89.179.40 $ host sge.sgeinc.com sge.sgeinc.com has address 159.89.179.40 $ host 159.89.179.40 40.179.89.159.in-addr.arpa domain name pointer sge.sgeinc.com. BTW: the latter is relevant for outgoing mails from this machine, as correct configured receiving servers should do this reverse lookup. (2) $ telnet mail.sgeinc.com 110 Trying 159.89.179.40... Connected to mail.sgeinc.com. Escape character is '^]'. +OK Dovecot (Ubuntu) ready. --> works (at least the POP3 daemon listens) (3) $ telnet sge.sgeinc.com 110 Trying 159.89.179.40... Connected to sge.sgeinc.com. Escape character is '^]'. +OK Dovecot (Ubuntu) ready. --> as expected: works too (at least the POP3 daemon listens) Now the same with STARTTLS: (4) $ openssl s_client -connect mail.sgeinc.com:110 -starttls pop3 CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = sgeinc.com verify return:1 --- Certificate chain 0 s:CN = sgeinc.com i:C = US, O = Let's Encrypt, CN = R3 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256 v:NotBefore: Feb 22 14:45:49 2024 GMT; NotAfter: May 22 14:45:48 2024 GMT 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT [...] (5) $ openssl s_client -connect sge.sgeinc.com:110 -starttls pop3 CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = sgeinc.com verify return:1 --- Certificate chain 0 s:CN = sgeinc.com i:C = US, O = Let's Encrypt, CN = R3 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256 v:NotBefore: Feb 22 14:45:49 2024 GMT; NotAfter: May 22 14:45:48 2024 GMT 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT [...] As you can see in (4) and (5): in both cases your server is also answering correctly if I'm using POP3 with STARTTLS. And the server has a valid certificate. But IMHO here could be the reason for your problem (unfortunately too: you didn't tell anything regarding your mail client / MUA and how it's configured): Look at the CN and the SANs: --- snip --- Certificate: Data: Version: 3 (0x2) Serial Number: 04:1e:b2:84:50:b3:3f:21:f5:06:37:aa:89:8d:4e:77:3e:3e Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let's Encrypt, CN = R3 Validity Not Before: Feb 22 14:45:49 2024 GMT Not After : May 22 14:45:48 2024 GMT Subject: CN = sgeinc.com [...] X509v3 Subject Alternative Name: DNS:sge.sgeinc.com, DNS:sgeinc.com, DNS:www.sgeinc.com [...] --- snip --- There's nothing for mail.sgeinc.com. And if your mail client ist strictly checking this cert, then maybe it refuses the communication with your server. Did you get any error messages on your mail client, if yes: which? And the cert could also be the reason for: It started working when I changed my incoming server to sge.sgeinc.com. because then the server name is one of it's SANs. Also the time is important. Your wrote: on 2/22/24 or 2/23/24 it stopped working Have a look at the cert's validity: --> Not Before: Feb 22 14:45:49 2024 GMT All these details seems to be matching IMHO. So I would suggest: create a new LE cert with an additional domain 'mail.sgeinc.com' and I'm quite sure that you can receive mails using 'mail.sgeinc.com' as your incoming server again after that. This could be made quickly, so please give it a try. ;-) HTH and regards, Markus ___ dovecot mailing
Re: Bug/Warning not sure which
Hi Richard, On 24.02.24 22:38, Richard Shetron wrote: I've always used mail.sgeinc.com as my incoming and outgoing server. At various times mail has been an alias for another machine. It's currently on the same address as sge.sgeinc.com. On the update forced on us on 2/22/24 or 2/23/24 it stopped working. It still works as an outgoing server but incoming POP3 it stopped working. It started working when I changed my incoming server to sge.sgeinc.com. unfortunately you didn't send the Dovecot logs. But anyway - I did the following tests: (1) $ host mail.sgeinc.com mail.sgeinc.com has address 159.89.179.40 $ host sge.sgeinc.com sge.sgeinc.com has address 159.89.179.40 $ host 159.89.179.40 40.179.89.159.in-addr.arpa domain name pointer sge.sgeinc.com. BTW: the latter is relevant for outgoing mails from this machine, as correct configured receiving servers should do this reverse lookup. (2) $ telnet mail.sgeinc.com 110 Trying 159.89.179.40... Connected to mail.sgeinc.com. Escape character is '^]'. +OK Dovecot (Ubuntu) ready. --> works (at least the POP3 daemon listens) (3) $ telnet sge.sgeinc.com 110 Trying 159.89.179.40... Connected to sge.sgeinc.com. Escape character is '^]'. +OK Dovecot (Ubuntu) ready. --> as expected: works too (at least the POP3 daemon listens) Now the same with STARTTLS: (4) $ openssl s_client -connect mail.sgeinc.com:110 -starttls pop3 CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = sgeinc.com verify return:1 --- Certificate chain 0 s:CN = sgeinc.com i:C = US, O = Let's Encrypt, CN = R3 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256 v:NotBefore: Feb 22 14:45:49 2024 GMT; NotAfter: May 22 14:45:48 2024 GMT 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT [...] (5) $ openssl s_client -connect sge.sgeinc.com:110 -starttls pop3 CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = sgeinc.com verify return:1 --- Certificate chain 0 s:CN = sgeinc.com i:C = US, O = Let's Encrypt, CN = R3 a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256 v:NotBefore: Feb 22 14:45:49 2024 GMT; NotAfter: May 22 14:45:48 2024 GMT 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT [...] As you can see in (4) and (5): in both cases your server is also answering correctly if I'm using POP3 with STARTTLS. And the server has a valid certificate. But IMHO here could be the reason for your problem (unfortunately too: you didn't tell anything regarding your mail client / MUA and how it's configured): Look at the CN and the SANs: --- snip --- Certificate: Data: Version: 3 (0x2) Serial Number: 04:1e:b2:84:50:b3:3f:21:f5:06:37:aa:89:8d:4e:77:3e:3e Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let's Encrypt, CN = R3 Validity Not Before: Feb 22 14:45:49 2024 GMT Not After : May 22 14:45:48 2024 GMT Subject: CN = sgeinc.com [...] X509v3 Subject Alternative Name: DNS:sge.sgeinc.com, DNS:sgeinc.com, DNS:www.sgeinc.com [...] --- snip --- There's nothing for mail.sgeinc.com. And if your mail client ist strictly checking this cert, then maybe it refuses the communication with your server. Did you get any error messages on your mail client, if yes: which? And the cert could also be the reason for: It started working when I changed my incoming server to sge.sgeinc.com. because then the server name is one of it's SANs. Also the time is important. Your wrote: on 2/22/24 or 2/23/24 it stopped working Have a look at the cert's validity: --> Not Before: Feb 22 14:45:49 2024 GMT All these details seems to be matching IMHO. So I would suggest: create a new LE cert with an additional domain 'mail.sgeinc.com' and I'm quite sure that you can receive mails using 'mail.sgeinc.com' as your incoming server again after that. This could be made quickly, so please give it a try. ;-) HTH and regards, Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: virtual user list in a passwd file (without linux user)
Hi Paul, On 19.02.24 21:05, p...@virtuadv.com wrote: Now the query with doveadm works if I specify us...@site1.com. thanks for the feedback and glad to hear that it works. :) I am still struggling with how postfix connects to dovecot. As with Dovevot: beside the error logs, please send the output of 'postconf -n' and 'postconf -M'. Otherwise it's nearly impossible to help you. Kind regards, Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: virtual user list in a passwd file (without linux user)
Hi Paul,
On 15.02.24 18:55, p...@virtuadv.com wrote:
> The passwd file:
# user:password:uid:gid:(gecos):home:(shell):extra_fields
us...@site1.com{PLAIN}password1::
us...@site2.com{PLAIN}password2::
on one of my servers:
foo:{plain}bar:5000:5000:::/bin/false::
---^
Look at the difference: IMHO the colon ':' between username and password
field is missing in your file. Maybe that's the reason for this error?
All in all I have the same set-up: Postfix together with Dovecot and both
using the accounts in the users-file.
Regards,
Markus
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: [SOLVED] Dovecot with Postfix "no SASL authentication mechanisms"
Hi Willy, On Mon, 04 Sep 2023 at 09:32:02PM +, Willy Manga wrote: It works now ! thanks for the feedback - I'm glad to hear that it works. :) Was it because I disabled 'plaintext' while at the same time allowing it through Dovecot? Not only allowing, you force it ;-): doveconf -n [...] auth_mechanisms = plain login ^^^ But that's OK and the only thing you had to do was enabling plaintext on the Postfix side. Best regards, Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Dovecot with Postfix "no SASL authentication mechanisms"
Hi Willy, On 04.09.23 19:54, Willy Manga wrote: I updated a little bit my configuration . Here is the current one with at the top the error I get if I try to send over submissions (port 465) http://paste.debian.net/1290927/ could you please try the following changes: 1) remove smtpd_sasl_security_options = noanonymous, noplaintext from your main.cf 2) just to be sure, add the follwoing: -o smtpd_sasl_security_options=noanonymous to both the 'submission' _and_ the 'submissions' entries of your master.cf 3) the submission entry of master.cf is missing an: -o smtpd_sasl_type=dovecot Restart Postfix, have a look at the log and try to send e. g. via submissions / port 465. Regards, Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: rename virtual user?
Hi Joe, On 08.07.23 19:43, joe a wrote: Possible to change a virtual user account, in passwd file, to another name and or domain? yes, that's possible. BTW and according to your former question regarding the authentication issue and your 'doveconf -n' output: I would suggest to not use 'driver = passwd' for virtual users but instead use 'driver = passwd-file' or an SQL database for the virtual accounts. IMHO it's easier and more flexible to handle within Dovecot and Postfix as well. Regards, Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Shared folders?
Hi Joe, On 09.07.23 00:53, joe a wrote: Is it possible to setup shared folders between virtual users on the same server? yes it is - here's the starting point within the documentation: https://doc.dovecot.org/configuration_manual/shared_mailboxes/ Regards, Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot sasl with postfix, smtp auth not available
Hi Badli, thanks for the information. A few hints: If possible, please avoid using HTML mails. And for outputs like 'postconf -n': please use an attached text file if your MUA (OL) isn't able to transfer them in a proper way. I would suggest the following changes: 1. postconf -n [...] smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot As Benny already wrote: delete them from your main.cf as port 25 should not be used for authentication. 2. postconf -M [...] smtps inet n - - - - smtpd [...] -o smtpd_client_restrictions= permit_sasl_authenticated, reject ---^ -o milter_macro_daemon_name= ORIGINATING --^ In master.cf: please take care that you don't specify whitespaces around the '=', at least if you're using the short form shown above. Some more examples, where you should check and change the master.cf regarding this: submission inet n - - - - smtpd [...] -o smtpd _sasl_security_options= noanonymous -o smtpd_client_restrictions= permit_sasl_authenticated, reject -o smtpd_sender_login_maps= hash:/etc/postfix/virtual -o smtpd_sender_restrictions= reject_sender_login_mismatch -o smtpd_recipient_restrictions= reject_non_fqdn_recipient ... Regarding the authentication part(s) itself: The configuration of the submission port seems correct to me and authentication should work. You can test it this way: openssl s_client -connect www.zystro.xyz:587 -starttls smtp For the smtps port you should add at least the following to the existing configuration of your master.cf: smtps inet n - - - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING -o smtpd_tls_security_level=encrypt -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_sasl_security_options=noanonymous You can test it this way: openssl s_client -connect www.zystro.xyz:465 After connecting successfully (to 465 & 587), in both cases using 'ehlo foo' you should see entries like these: [...] 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN [...] If not, we need the logs. ;-) HTH and regards, Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: dovecot sasl with postfix, smtp auth not available
Hi Badli, On 23.04.23 05:15, Badli Al Rashid wrote: Anybody got any ideas ? please post the output of: 1) postconf -n 2) postconf -M Regards, Markus ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Move sent emails to sent folder?
On 18.06.22 12:33, Gedalya wrote: On 6/17/22 22:18, Austin Witmer wrote: For some reason I am now getting five duplicate emails placed in my sent folder You want to apply this rule only once, perhaps on the way back in from amavisd. This can probably be accomplished by applying the sender_bcc_maps to a specific listener in master.cf, for the general idea see examples here: If it's a usual Amavis setup then there should be an additional smtpd process listening on port 10026 for example. And there Austin could use: -o receive_override_options=no_address_mappings to selectively turn off automatic BCC recipients as stated in: https://www.postfix.org/ADDRESS_REWRITING_README.html @Austin: you could send us the output of 'postconf -M' so we could have a look at your master.cf just to be sure. Kind regards, Markus
Re: Move sent emails to sent folder?
On 17.06.22 20:48, Austin Witmer wrote: Doing an ls /maildir/user/.Sent/cur folder shows the duplicate messages. It seems like postfix is bccing the outgoing message more than once somehow. That may happen - Postfix cannot check for duplicates. So ... Maybe I need to take this conversation over to the postfix mailing list? ... no. ;-) You can solve this problem with the duplicate extension of Pigeonhole Sieve: https://doc.dovecot.org/configuration_manual/sieve/extensions/duplicate/ https://doc.dovecot.org/settings/pigeonhole-ext/duplicate/ https://datatracker.ietf.org/doc/html/rfc7352#section-5.1 HTH and kind regards, Markus
Re: how to setup IMAPs with letsencrypt
On 24.04.22 02:45, Richard Hector wrote: On 22/04/22 11:57, Joseph Tam wrote: Keep in mind the subject name (CN or SAN AltNames) of your certificate must match your IMAP server name e.g. if your certificate is made for "www.mydomain.com", you'll have to configure your IMAP clients to also use "www.mydomain.com" as the IMAP server name. This typically means the web and IMAP server must reside on the same server, otherwise you'll have to use DNS challenge method to support multiple hostnames on the same certificate. _A_ web server has to be there. It doesn't have to serve anything else useful. My mail server has a web server that only serves the LE challenge. Well, actually it's a proxy server that serves several other domains too, but there's nothing else served on that domain (at the moment). if it wasn't already mentioned in this thread: acme.sh (https://github.com/acmesh-official/acme.sh) has a builtin standalone webserver which can be used in such cases, there's no need for an additional web server. And Certbot has this functionality too. acme.sh is a very simple and stable solution - it's just a shell script, no dependencies. I'm using it on a number of servers (together with Apache/Nginx or with the builtin standalone mode on mail gateways) without any problem. Regards, Markus
Re: Received invalid SSL certificate: unable to get certificate CRL
Hi Laura, On Wed, 26 Jan 2022 at 12:09:04AM +, Laura Smith wrote: ‐‐‐ Original Message ‐‐‐ I thought that ssl_ca = Does ssl_ca even apply to dsync/imapc ? as I wrote: I cannot test your scenario and the link to the documentation I sent was only a rough idea. 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 ? In my understanding this parameter is not only about client certificate authentication. If you want, then please have a look at this: https://doc.dovecot.org/settings/core/#core_setting-ssl_ca [...] These CAs are also used by some processes for validating outgoing SSL connections, i.e. performing the same function as ssl_client_ca_file. [...] And that's why I wrote: it's worth a try (it takes only two minutes to test it ...). IMHO of course. If you don't want to test it, OK. But I have no further ideas, sorry. Regards, Markus
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: 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
Re: Why would dovecot not be answering
Oh, as I read this just now: On 23.01.22 05:05, Ruben Safir wrote: I want it to authenticate on submition only ---^^ you should remove all smtpd_sasl_* from /etc/postfix/main.cf, including the smtpd_sasl_path = private/auth from my former mail. Instead you should put all that in /etc/postfix/master.cf and have something like this: submission inet n - y - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_sasl_security_options=noanonymous -o broken_sasl_auth_clients=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_relay_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING -o smtpd_helo_required=no -o smtpd_helo_restrictions= If it still doesn't work, then please provide the output of - postconf -n - postconf -M Regards, Markus
Re: Why would dovecot not be answering
Hi Ruben, On 23.01.22 05:05, Ruben Safir wrote: smtpd_sasl_type = dovecot in main.cf if not already there, please add the following to /etc/postfix/main.cf: smtpd_sasl_path = private/auth HTH and regards, Markus
Re: lda to lmtp
Hi Benny, On 11.06.21 14:14, Benny Pedersen wrote: but remember lda, ltmp is both signle recipient ^^^ are you sure? 'postconf -d' says: lmtp_destination_recipient_limit = $default_destination_recipient_limit default_destination_recipient_limit = 50 @Laura: The question is with lda we used postfix settings destination_recipient_limit=1, we have not added this with lmtp,is this needed? AFAIK: no, it isn't. Regards, Markus
Re: Sendmail and Doecot
Hi Stephane, On 20.05.21 08:44, Stephane Magnier wrote: I am using Dovecot v 2.2.32 and Sendmail 8.15.2 My "folder" config on Dovecot is :*mbox:/var/spool2/%u/mail:LAYOUT=fs:INBOX=/var/spool/mail/%u* But in fact, any email arriving into the mailbox, stays in Sendmail into the file location (by default) : /var/spool/mail/user1 and any folder created, can be reached via Dovecot and is located to /var/spool2/user1 I would recommend to change your Sendmail setup. IMHO you should configure it so that it uses Maildir instead of mbox. Please have a look at the Wiki: https://wiki2.dovecot.org/LDA/ https://wiki2.dovecot.org/LDA/Sendmail Or use LMTP instead (which I prefer): https://doc.dovecot.org/configuration_manual/protocols/lmtp_server/ And your Dovecot config could then be something like this: mail_location = maildir:/var/spool2/%u/Maildir All the mails and folders in _one_ place. HTH and regards, Markus
Re: Changing IMAP separator - does it break things?
On 14.10.20 15:02, Victor Sudakov wrote:
I was asking because the section "Hierarchy separators" in
https://doc.dovecot.org/configuration_manual/namespace/ somewhat implies
that
However, changing the separator doesn’t change the on-disk “layout separator”.
That's why I thought that the separator is in fact virtual.
You're right - please see my former mail and the link you repeated above.
There's a nice table which shows the possible combinations of hierarchy
separator (called 'NS sep' there) and 'Layout sep' (structure on disk) and
the respective results for 'Mailbox name' and the directory structure in
the filesystem.
At present, if my folder layout in the mail client is
Inbox
|
+---Friends
|
+Paul
|
+Jessica
the folder "Jessica" on-disk is something like
~/Maildir/.Friends.Jessica/{cur,new,tmp}/
-^^
Then you have configured a Layout sep '.' (mail_location = maildir:~/Maildir).
This says nothing about your hierarchy separator, which is controlled by
the parameter 'separator ='.
Do you mean to say that if I change the IMAP separator to "/", Dovecot
will not translate "/" into "." and the folder "Jessica" will become
inaccessible?
If you currently have 'separator = .' then of course the hierarchy
separator is '.'. If you change that to 'separator = /' normally the access
to "Jessica" is still possible.
But (as you can see in the table mentioned above) the name of the mailbox
(= folder) from the IMAP clients point of view is now 'Friends/Jessica'.
Before the change and with 'separator = .' the name of the mailbox was
'Friends.Jessica'.
If you telnet to Dovecot and (after authentication) type something like this:
a LIST "" "*"
The server may responds with:
* LIST (\HasChildren) "." INBOX
Here you can see, that this name space has a '.' as the hierarchy separator.
If the response is this:
* LIST (\HasChildren) "/" INBOX
then we know that '/' is the hierarchy separator.
So, if you have an IMAP client which ist standard-compliant he will check
what's the configured hierarchy separator and will use it for accessing the
folder structure. And again: this has nothing to do with the on disk
structure of the folders.
Regards,
Markus
Re: Changing IMAP separator - does it break things?
On 14.10.20 11:57, Victor Sudakov wrote: Besides that: changing the hierarchy separator is generally possible. But you schould try and check that with a test system to prevent problems with your productive environment and all the other users. I was hoping someone had already done that and I could skip this step :-) No, I didn't. ;-) I almost always use '/' as the separator so I didn't observed any problem with Mac Mail users. Regards, Markus
Re: Changing IMAP separator - does it break things?
Hi Victor, On 14.10.20 11:51, Victor Sudakov wrote: Did it change anything on Dovecot disk/storage or is the IMAP separator just "virtual" - ephemeral ? just for the for the sake of completeness: there is a difference between the hierarchy separator (for the mailbox name) and the layout separator, which is responsible for the folder names on the disk - they are completely independent. Here you can see the details, if you not already know this page: https://doc.dovecot.org/configuration_manual/namespace/ Regards, Markus
Re: Changing IMAP separator - does it break things?
Hi Victor, On 14.10.20 04:36, Victor Sudakov wrote: Do you think I can change the hierarchy separator in the "inbox" namespace without breaking other clients and the mail layout on disk, losing mail etc? I personally would try to avoid such a change (really IMHO), especially if it's "only": I don't want to break mail for 50 people just to please one Mac Mail user. _one_ user. Could Thunderbird or another IMAP client be an option for this single user? And perhaps Apple can tell some details when their Mail client will be standards-compliant? Besides that: changing the hierarchy separator is generally possible. But you schould try and check that with a test system to prevent problems with your productive environment and all the other users. Regards, Markus
Re: Migration issue
Hi Kishore,
On 04.08.20 17:48, Kishore Potnuru wrote:
passdb {
args = /etc/dovecot/master-users
driver = passwd-file
master = yes
#pass = yes
---^^^
IMHO not important for this case , but in your environment it could be
better to enable 'pass = yes'
passdb {
driver = passwd-file
args = username_format=%u /etc/dovecot/passwd
}
Now I am getting the below Authentication error from production2.
According to your password file, could you please try to change it this way:
passdb {
driver = passwd-file
args = scheme=PLAIN username_format=%u /etc/dovecot/passwd
}
AFAIK the default scheme is CRYPT, so I think it's necessary to change it
with this parameter.
I have copied the same content of the "passwd" file to "master-users" file.
Actually, it should be having same content? if different, what will be the data and which format?
imapc_password = vmail
imapc_master_user = vmail
To be honest: I'm not sure.
If you want to use a master user then the credentials for
imapc_master_user/imapc_password have to be in /etc/dovecot/master-users of
'production1'.
But AFAIK the migration should also work without using a master user (as
long as you have the credentials of all the users of the old server). I
hope I'm not wrong. It's been a while since I've done such a migration from
an old server and cannot remember the details.
HTH and regards,
Markus
Re: Migration issue
Hi Kishore,
On 04.08.20 09:50, Kishore Potnuru wrote:
So, both password files (master and regular user credentials) have the same
contents in this scenario, correct?
first of all: thanks for collecting the information.
As Joseph wrote: I too think that in your config of 'production1' a passdb
with the credentials of regular users is missing.
On one of my servers I'm using this:
passdb {
driver = passwd-file
master = yes
args = /etc/dovecot/master-users
#pass = yes
}
passdb {
driver = passwd-file
args = username_format=%u /etc/dovecot/users
}
Something similar should work in your case.
Regards,
Markus
Re: Migration issue
Hi Kishore, On 03.08.20 15:33, Kishore Potnuru wrote: Please let me know if you need any other details. please provide the following outputs/answers: 1) Are users able to login and access their mailboxes on production1 with an IMAP client? On your old server (production1): 2) ps aux | grep dovecot 3) netstat -lntp 4) ls -la /etc/dovecot On your new server (production2): 5) telnet production1.testorg.com 143 Thanks and regards Markus
Re: identify 143 vs 993 clients
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
Re: problem with a public folder
Hi Dave,
thanks for the information.
On 27.04.20 21:30, David Mehler wrote:
Thanks, yes the global-acls file is the one I'm refering to and I
created it before all this started.
Yes, the users can both login properly and can access there own inboxes.
I must admit I've run out of ideas.
Just as a test you could try the following:
(1)
In your Dovecot config change this:
plugin {
acl = vfile:/usr/local/etc/dovecot/global-acls:cache_secs=300
to:
plugin {
acl = vfile
(2)
In this folder:
/var/vmail/public
- create a file 'dovecot-acl' with content like this:
authenticated lrs
user=us...@domain.com lrwstipekxa
user=us...@domain2.com lrwstipekxa
- chown vmail:vmail dovecot-acl
- as 'TestFolder' and 'general' already exist (and therefore no
inheritance), copy 'dovecot-acl' to these two folders
- delete /var/vmail/public/dovecot-acl-list
(3)
restart Dovecot
Please check, if these modifications changed the behaviour.
Regards,
Markus
Re: problem with a public folder
Hi Dave, thanks for the information. On 26.04.20 18:37, David Mehler wrote: In answer to your questions I made a file global-acls containing: It's the '/usr/local/etc/dovecot/global-acls', right? # cat global-acls Public/general user=us...@domain.com lrwstipekxa Public/TestFolder user=us...@domain.com lrwstipekxa Public/general user=us...@domain2.com lrwstipekxa Public/TestFolder user=us...@domain2.com lrwstipekxa Just to be sure: when did you create this file and it's content: before you reported (i.e. yesterday) the results of 'doveadm acl get -A "Public/general"' and 'doveadm acl get -A "Public/TestFolder"' or only today before you wrote this mail? In the latter case: did this change the output of 'doveadm acl get -A ...' To me this file looks OK and so the ACLs should be reported and working correctly ... And an additional question: the users us...@domain.com and us...@domain2.com are generally able to login, use their own Inbox etc. without any problem? Regards, Markus
Re: Hierarchy separator recommendation?
Hi Ivo, On 26.04.20 13:34, Ivo wrote: I was trying to write wannabe-joke / philosophical / theoretical comment. It seems that I failed :-( I'm sorry - my irony detector seems to be broken. ;-) Have a nice Sunday and regards, Markus
Re: Hierarchy separator recommendation?
Hi Aki, On 26.04.20 12:30, Aki Tuomi wrote: Using dot breaks shared forlders if your usernames contain dot. yes, I know and as I already wrote two days ago: disadvantages could be: - shared folders with dots in user names - if you want to use dots in folder names ;-) Regards, Markus
Re: problem with a public folder
Hi David, On 25.04.20 21:23, David Mehler wrote: I've added a mailbox to the namespace definition for the public folders. I can do a doveadm acl get -A "Public/general" works but "Public/TestFolder" does not. did you already used something like this on your server?: # doveadm acl set -A "Public/..." or how did you set the ACLs? And: Here's my ls output: #ls -l /var/vmail/public total 16 drwx-- 5 vmail vmail 512 Apr 25 13:56 TestFolder/ -rw--- 1 vmail vmail0 Apr 25 13:43 dovecot-acl-list -rw--- 1 vmail vmail8 Apr 25 13:47 dovecot-uidvalidity -r--r--r-- 1 vmail vmail0 Apr 25 13:47 dovecot-uidvalidity.5ea477b0 -rw--- 1 vmail vmail 804 Apr 25 13:59 dovecot.list.index.log drwx-- 5 vmail vmail 512 Apr 25 13:47 general/ could you please also show the output of: # ls -la /var/vmail/public/TestFolder and # ls -la /var/vmail/public/general Thanks and regards, Markus
Re: Hierarchy separator recommendation?
Hi Ivo, On 26.04.20 12:02, Ivo wrote: disadvantages could be: - shared folders with dots in user names - if you want to use dots in folder names What disadvantages are when using '/' as namespace separator? IMHO: none. ;-) It depends, as always - YMMV. Why is '.' default (at least in .deb packages) if it is worse then '/' ? I assume: for historical reasons. Doesn't it, in the end, all come to translation from IMAP names (user,folder) to OS filesystem names within dovecot (at some benchmark tests expense) ? :-) No, as there's a difference between "namespace / hierarchy" (mailbox name) and "layout" separators (OS filesystem). Regards, Markus
Re: error service quota-status
Hello Becki,
On 24.04.20 20:28, Admin Beckspaced wrote:
trying to setup this quota-status thingy in dovecot
but whenever I try I get this error:
what am I missing here?
as I couldn't find any information regarding 'service dict' in your
doveconf -n:
Please have a look in your /etc/dovecot/conf.d/10-master.conf (or elswhere
in your Dovecot configs) and find a config option for service dict.
The default is mostly something like this:
service dict {
# If dict proxy is used, mail processes should have access to its socket.
# For example: mode=0660, group=vmail and global mail_access_groups=vmail
unix_listener dict {
#mode = 0600
#user =
#group =
}
}
Please change it to:
service dict {
# If dict proxy is used, mail processes should have access to its socket.
# For example: mode=0660, group=vmail and global mail_access_groups=vmail
unix_listener dict {
mode = 0660
user = vmail
group = vmail
}
}
restart Dovecot and test if it works.
HTH and kind regards,
Markus
Re: Hierarchy separator recommendation?
Hello Becki, On 24.04.20 17:56, Admin Beckspaced wrote: what sort of troubles did you run into with the dot '.' as namespace separator? disadvantages could be: - shared folders with dots in user names - if you want to use dots in folder names Whenever possible I use '/'. Kind regards, Markus
