Re: Why Last-login?
On Thu, 2021-03-04 at 10:54 +0100, Yassine Chaouche wrote: > This is pretty wild. Is that perl sorcery ? Used to be but as I migrated to a new server I thought I would use python this time around. -- Greg signature.asc Description: This is a digitally signed message part
Re: Why Last-login?
Sorry, the output didn't format properly. The takeaway fields are as follows: Last Modified : 2020-08-18 19:46:12 Last IMAP : 2021-03-04 10:52:03 Last POP3 : None Last Delivery : 2021-03-04 10:26:49 -- Greg signature.asc Description: This is a digitally signed message part
Re: Why Last-login?
On Wed, 2021-03-03 at 04:57 -0700, @lbutlr wrote:
> I've noticed several threads over the last year or so about last-
> login, and I was curious WHY people care about tracking this in the
> database. I can see wanting to know if a user has logged in recently,
> but this seems quite easy to tell by simply looking at the time stamp
> and/or contents of the mail spool for the user.
> Am I missing some reason I would need/want to keep track of that
> specific login time separately?
I keep the last login details in a database for support/reporting
tools. Support staff can get at this information without system access.
I track the last login timestamp for imap, pop3, lmtp and sieve
seperately. Again for support and reporting reasons. I also have local
tools that interrogate the DB when I am doing my admin thing on the
server.
Current dovecot last_login config ('X' used to replace private data)
---
connect = host=X dbname=X user=XX password=XX
# Remote connections
map {
pattern = shared/last-login/$service/$user/$rip
table = mail_stats
value_field = last_login
value_type = uint
fields {
mailbox = $user
remote_ip = $rip
protocol = $service
}
}
# Local conections, no remote IP
map {
pattern = shared/last-login/$service/$user/
table = mail_stats
value_field = last_login
value_type = uint
fields {
mailbox = $user
protocol = $service
}
}
---
E.g. inspecting a mailbox config ('X' used to replace private data)
Mailbox : xx...@xxx.co.za
Created : 2020-08-18 17:45:34
Description : X
Quota : 8G, used 6.3 GiB (78%)
SMTP Limit : 100 per hour
Addresses : x, xxx, xx
Can receive mail : YES
Can send mail : YES
Can download mail : YES
Can filter mail : YES
Has IM account : NO
Catchall : NO
Last Modified : 2020-08-18 19:46:12
Last IMAP : 2021-03-04 10:52:03
Last POP3 : None
Last Delivery : 2021-03-04 10:26:49
Home : /srv/hosting/x/x/xx.co.za/mail/xx003
Sieve rules : roundcube ACTIVE
Default
--
Greg
signature.asc
Description: This is a digitally signed message part
Re: Multiple certificate option
On Tue, 2019-09-10 at 08:41 +0200, Maciej Milaszewski IQ PL via dovecot wrote: > Hi > This is for all dovecot version ? Not sure. Any version of dovecot that builds it's config from the conf.d folder will work. Not sure on the specific SSL certificate syntax but I have been using the aformentioned config for the last couple of years. -- Greg signature.asc Description: This is a digitally signed message part
Re: Multiple certificate option
On Fri, 2019-09-06 at 17:25 -0700, remo--- via dovecot wrote:
> What is the best way to adopt multiple certs?
I have a setup that creates letsencrypt certs for each customer domain.
To automate this I have the following at the end of conf.d/10-ssl.conf
!include ssl.d/*.conf
This includes any .conf file under conf.d/ssl.d
Now it is a simple matter to add and remove certificates for each
domain as the letsencrypt job runs. Each config file looks like this
$cat ssl.d/somedomain_co_za.conf
local_name imap.somedomain.co.za {
ssl_cert =
signature.asc
Description: This is a digitally signed message part
Re: Problem with different certificates
What problem are you seeing? It uses the correct SSL certs when I connect. prompt> gnutls-cli --port 993 mail.nimmini.de Processed 149 CA certificate(s). Resolving 'mail.nimmini.de:993'... Connecting to '46.38.231.143:993'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `CN=nimmini.de', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x049c7758b8b9555ffdfe5b701b28c1e0a3c6, RSA key 2048 bits, signed using RSA-SHA256, activated `2018-12-26 21:37:59 UTC', expires `2019-03-26 21:37:59 UTC', pin-sha256="0G1iyw4AAayWktCk3M9gauB01s4guqgidOQotb1u49I=" Public Key ID: sha1:e03d4c14e735791a4a0924057676bee73b5e199f sha256:d06d62cb0e0001ac9692d0a4dccf606ae074d6ce20baa82274e428b5bd6ee3d2 Public Key PIN: pin-sha256:0G1iyw4AAayWktCk3M9gauB01s4guqgidOQotb1u49I= - Certificate[1] info: - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x0a014142015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=" - Status: The certificate is trusted. - Description: (TLS1.2)-(ECDHE-SECP384R1)-(RSA-SHA256)-(AES-256-GCM) - Session ID: 0B:1D:9F:A2:73:92:FA:E7:02:08:98:49:14:A6:69:1B:2D:D4:30:F0:62:A9:AF:B2:4C:B7:79:94:CF:3E:41:A2 - Options: safe renegotiation, - Handshake was completed - Simple Client Mode: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=CRAM-MD5] Dovecot ready. . logout - Peer has closed the GnuTLS connection prompt> gnutls-cli --port 993 mail.bitcorner.de Processed 149 CA certificate(s). Resolving 'mail.bitcorner.de:993'... Connecting to '37.120.166.21:993'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `CN=bitcorner.de', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x046f144c168497bce339d1dc4abab194139f, RSA key 2048 bits, signed using RSA-SHA256, activated `2018-12-26 20:46:48 UTC', expires `2019-03-26 20:46:48 UTC', pin-sha256="wZrqFPu/9op8PgqIkm0oK5VoNDPfOzWkX45rNf9IIHk=" Public Key ID: sha1:5d5172ccea888d3340a158eff2c2cb3cb4ccac23 sha256:c19aea14fbbff68a7c3e0a88926d282b95683433df3b35a45f8e6b35ff482079 Public Key PIN: pin-sha256:wZrqFPu/9op8PgqIkm0oK5VoNDPfOzWkX45rNf9IIHk= - Certificate[1] info: - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x0a014142015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=" - Status: The certificate is trusted. - Description: (TLS1.2)-(ECDHE-SECP384R1)-(RSA-SHA256)-(AES-256-GCM) - Session ID: B4:69:62:88:14:52:1A:54:A5:E9:42:F1:7A:4D:3D:EB:4E:90:D0:07:28:1B:2F:16:A1:BE:45:2C:B6:68:AE:1E - Options: safe renegotiation, - Handshake was completed - Simple Client Mode: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=CRAM-MD5] Dovecot ready. . logout - Peer has closed the GnuTLS connection -- Greg signature.asc Description: This is a digitally signed message part
Re: "no shared cypher", no matter what I try
On Sat, 2018-12-08 at 11:03 +0100, Marco Fioretti wrote: > Greetings, > I have had to reinstall my email server on another Linux (centos 7.6) > VPS, with a newer version of dovecot, other software and a brand new > letsencrypt certificate just for email withpostfix and dovecot (that > certificate works fine with postfix). Output of dovecot --version and > dovecot -n on the new server is below. Here is my 10-ssl.conf on my CentOS box. I am using the TLS config from https://weakdh.org/sysadmin.html --- ssl = yes ssl_cipher_list=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA ssl_prefer_server_ciphers = yes #regenerates every week ssl_dh_parameters_length = 2048 ssl_cert = signature.asc Description: This is a digitally signed message part
v2.2.19 release candidate released
Hello,
I am trying out 2.2.19.rc1 on a lightly loaded server with no problems
so far. The reason I wanted to try 2.2.19.rc1 was to get access to the
%{listener} variable in the auth phase so I can modify the SQL
password_query according to which unix_listener is being queried.
According to the docs, "These variables work only in Dovecot-auth and
login_log_format_elements setting". I can confirm that %{listener}
works in login_log_format_elements but it does not work if I use it in
my SQL auth query.
My logic is as follows:
I create multiple listeners for different SASL authentications in 10
-master.conf
service auth {
unix_listener auth-userdb {
mode = 0660
user = dovecot
group = vmail
}
unix_listener exim-client {
mode = 0660
user = dovecot
group = exim
}
unix_listener xmpp-client {
mode = 0660
user = dovecot
group = mail
}
user = $default_internal_user
}
Now I want to use %{listener} in my SQL password_query in a case
statement to auth according to which listener is being used. E.g.
CASE '%{listener} ' \
WHEN 'exim-client' THEN ma.SMTPAUTH_allowed = 'YES' \
WHEN 'xmpp-client' THEN ma.XMPP_allowed = 'YES' \
ELSE ma.IMAP_allowed = 'YES' \
END
Should the %{listener} variable work in this case ?
--
Greg
signature.asc
Description: This is a digitally signed message part
