Re: [Dovecot] testing needed: log file concurrency
Hi Timo, > http://dovecot.org/tmp/concurrency.c [cut] > So far I've tested only with Linux 2.6.21 x86-64/SMP and a slow > Solaris/Sparc/UP. One writer and three readers ran for 30 minutes on Solaris 10 without printing anything. The box is an UltraSparc IIIi dual proc, and the FS on the partition is UFS. Greg
Re: [Dovecot] test program #2: mmaping
Hi, > It doesn't compile for Solaris 10: You can compile it with : gcc -o concurency -I/usr/ucbinclude -L/usr/ucblib -lucb concurency.c (on a default Solaris 10 install). Then, you must add /usr/ucblib to your library search path using crle. On a dual UltraSparc IIIi running Solaris 10, here is what is printed after 30 minutes : $ ./concurency writing, page size = 8192 4: reading, page size = 8192 3: reading, page size = 8192 2: reading, page size = 8192 0: reading, page size = 8192 1: reading, page size = 8192 Cheers, Greg
Re: [Dovecot] Maildir Skeleton
Le jeudi 09 août 2007 09:47, Sebastian Ganschow a écrit : > But if the user creates his own rules, he also needs to create the spam > rule. Otherwise his spam won't be delivered to the spam folder. I'm not > really sure, if this is the solution i'd like to have. Why not include a default sieve script in your maildir skeleton that will take care of moving spams into the right folder then ? If the user later deletes this rule it's out of your control sure, but if you send a welcome message tell them about this rule and why it's here to help them. Grégory
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
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: 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: 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 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: What imap ssl/auth settings work best with MS Outlook?
On Wednesday, 28 April 2021 13:49:03 CDT Steve Dondley wrote: > I repeatedly have a hell of a time getting clients' Outlook software > working well with Dovecot. It's hard for me to test myself since I don't > have Outlook and it would be impossible to keep up with all the > different versions anyway. > > [snip] > > It always seems to be hit or miss with outlook as to which encryption > setting to use, which port to try, etc. With a recent client, I couldn't > get them successfully logged in no matter what manual settings we tried. > If someone can give me some tips on how to get most versions of Outlook > cooperating well with Dovecot, I'd appreciate it. > Your best bet to make Outlook behave better as an IMAP client is to configure a mail "profile" via Control Pannel --> User Accounts --> Mail, and set all the particulars there. Recent versions of Outlook have a stripped down configuration interface that offers no flexibility. For example, from Outlook itself it's not possible to set an IMAP login name that's not an email address. -- Greg
Re: Updated my Dovecot certificate for the first time
On Wed, 23 Nov 2016, Steve Litt wrote:
[snip]
Alpine still gives me a bad cert warning, saying I should either fix it
or disable checking. I haven't yet found a way to get Alpine to
discriminate between a valid self-signed cert and a bad one.
Like a number of applications, alpine checks the system certificates
directory for a file containing the server certificate to be validated
that's named according to its x509 hash. If it finds it, it trusts it.
I don't know where Linux distros keep their certs, but on FreeBSD it's in
/etc/ssl/certs/. If you've no other way to find out, a brute force search
of the alpine binary should locate it, e.g.:
$ strings $(whence alpine) | grep '^/.*certs$'
/etc/ssl/certs
You can fetch the certificate from a remote IMAP server and install it in
your system certs directory like this:
# cd /path/to/certs &&
openssl s_client -connect remote.server:143 -starttls imap -showcerts &0 |
H=$(openssl x509 -hash -out imap.pem) &&
ln -sf imap.pem ${H}.0
# ls -l
total 5
lrwxr-xr-x 1 root wheel11 Nov 23 15:34 3a82ab1a.0 -> imap.pem
-rw-r--r-- 1 root wheel 1371 Nov 23 15:34 imap.pem
--
Greg Rivers
Re: offtopic: Solr compatible IMAP client
On Saturday, September 09, 2017 10:01:03 Larry Rosenman wrote: > Neomutt. > https://www.neomutt.org/ > Also alpine. https://www.washington.edu/alpine/ -- Greg Rivers
TLS renegotiation issue (CVE-2011-1473) in Dovecot
Hello,
At work I'm running a Dovecot 2.3.15 server on a RHEL 7.9 system with
OpenSSL 1.0.2k.
Our IT Security people are threatening to shut it down because of this:
We were notified of a possible TLS renegotiation vulnerability on
[FQHN].
[Parent organization] ticket NNN is open to track efforts.
We conducted a manual test on the site for TLS Renegotiation on IMAP
port 993.
We found that this was set to enabled.
In order to remediate we will need to either:
1. Disable Renegotiation (preferred)
2. Set a max aggregated renegotiation
Please remediate as soon as possible.
References:
https://support.f5.com/csp/article/K15278
https://nvd.nist.gov/vuln/detail/cve-2011-1473
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1473
I did some Googling and among the results, I found a few old posts from
this mailing list among them, which to summarize basically seemed to say
"Yeah, we could write some code ... " but that was about it.
The IT Security rep sent me a reference to an ancient Red Hat article
https://access.redhat.com/articles/23543
which is hysterical - ancient history, references NSS and Tomcat,
suggests changes to an add-on product (Red Hat Certificate Server) that
is EOL, etc.
Is there any way to mitigate this issue?
(The only thing I can think of is to upgrade the Dovecot server to RHEL
8 and restrict connections to only TLSv1.3, but that ain't gonna happen
overnight.)
Thanks,
- Greg
Re: TLS renegotiation issue (CVE-2011-1473) in Dovecot
On 13 May 2022, at 19:38, Elisamuel Resto wrote:
I believe this to be a configuration error, not a dovecot problem.
The
output of dovecot -n (as an attachment; look it over for any data you
do
not want publicized) would help to suggest changes to bring you back
into compliance.
Elisamuel,
I'm not really sure why you think it's a configuration error, but I'll
attach the "dovecot -n" output.
Thanks,
- Greg
# 2.3.15 (0503334ab1): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.15 (e6a84e31)
# OS: Linux 3.10.0-1160.53.1.el7.x86_64 x86_64 Red Hat Enterprise Linux
Workstation release 7.9 (Maipo) xfs
# Hostname: [ELIDED]
auth_mechanisms = plain login
auth_username_format = %Ln
auth_verbose = yes
auth_verbose_passwords = plain
disable_plaintext_auth = no
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep tb-lsub-flags
log_path = /var/log/dovecot
mail_location =
maildir:/var/maildirs/virtual/[ELIDED]/%u/Maildir:INDEX=/var/maildirs/virtual/indexes/%u
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 = failure_show_msg=yes
driver = pam
}
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
}
protocols = imap
ssl_cert =
dsync panic
As per <http://wiki2.dovecot.org/Migration/Dsync>, I'm running the
following command on a local dovecot server to replicate email for a
single user from a remote IMAP server:
doveadm -D \
-o imapc_host=remote.imap.server \
-o imapc_user=gcr \
-o imapc_password= \
-o imapc_list_prefix=IMAP \
-o imapc_features="rfc822.size fetch-headers" \
-o mail_prefetch_count=20 \
-o mail_fsync=never \
backup -R -u gcr imapc:
This runs fine for a while and successfully copies quite a lot of mail,
but always aborts before completion with the following error:
dsync(gcr): Panic: file mail-transaction-log.c: line 271
(mail_transaction_log_rotate): assertion failed: (file->locked)
The exit code is 262. Does anyone know why this might happen or how to
fix it?
--
Greg Rivers# 2.2.15: /usr/local/etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.6 (3e924b1b6c5c+)
# OS: FreeBSD 10.1-RELEASE-p6 amd64
auth_verbose = yes
imap_id_log = *
imap_id_send = name * version * os * os-version *
mail_location = mdbox:~/.mdbox
mail_plugins = " quota zlib"
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 ihave duplicate
editheader vnd.dovecot.debug imapflags notify vnd.dovecot.duplicate
vnd.dovecot.pipe vnd.dovecot.filter vnd.dovecot.execute
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 = %s
driver = pam
}
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
sieve_execute_bin_dir = /usr/local/etc/dovecot/sieve/execute
sieve_execute_socket_dir = sieve-execute
sieve_extensions = +notify +imapflags +editheader +vnd.dovecot.duplicate
+vnd.dovecot.pipe +vnd.dovecot.filter +vnd.dovecot.execute +vnd.dovecot.debug
sieve_filter_bin_dir = /usr/local/etc/dovecot/sieve/filter
sieve_filter_socket_dir = sieve-filter
sieve_global = /usr/local/etc/dovecot/sieve
sieve_max_actions = 0
sieve_max_redirects = 16
sieve_max_script_size = 0
sieve_pipe_bin_dir = /usr/local/etc/dovecot/sieve/pipe
sieve_pipe_socket_dir = sieve-pipe
sieve_plugins = sieve_extprograms
}
postmaster_address = postmaster@local.domain
protocols = imap lmtp sieve
quota_full_tempfail = yes
ssl_cert =
Re: FYI: dovecot (008632bdfd2c) compilation woes, and minor glitch regarding update-version.sh
On Saturday, May 09, 2015 22:25:48 Michael Grimm wrote: > > or just try if it works if you change it to /bin/sh and use whatever > > FreeBSD has that pointing to. > That fails because /bin/sh equals /bin/csh at FBSD. > I don't know if it fails or not, but if it does this is not the reason. /bin/sh most certainly is not /bin/csh; if it were, the system would not boot given that all the rc start-up scripts are written in Bourne shell. OTOH, /bin/csh and /bin/tcsh are identical: $ freebsd-version -uk 10.1-RELEASE-p9 10.1-RELEASE-p9 $ ls -li /bin/*sh 108 -r-xr-xr-x 2 root wheel 382368 Nov 11 15:03 /bin/csh* 118 -r-xr-xr-x 1 root wheel 142184 Nov 11 15:03 /bin/sh* 108 -r-xr-xr-x 2 root wheel 382368 Nov 11 15:03 /bin/tcsh* -- Greg Rivers
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
[Dovecot] Local delivery via deliver fails for 1 user in alias
Hi all, I'm a bit baffled. I have an OS X server 10.6.8 and everything was working fine. Now however I seem to be having some issues and I'm unable to find log entries to help point me to the error. I have an alias, sales at cirrusav.com, which forwards mail to myself and two others. This works fine most of the time, but on occasion messages are not delivered to one user. It is possible that one of the other users fails delivery occasionally as well, though this has not been rigorously tested. I always seem to get the messages. I have logging set to debug via the OS X server admin. Looking through /var/log/mailaccess.log I see all the same entries for each user even when messages fail to deliver. The only difference I notice is the order. I see some messages about corrupt index cache files. I can find the missing message in failing user's dovecot.index.cache. However I can not find the message in the cur sub directory or anywhere else (grep -i regency ...). I can find the file in my dovecot.index.cache and cur directory. Details below. I'm continuing to research the internet, but don't know what I'm looking for. I'm also concerned that we might be dropping more mail. Thoughts anyone? Thank you in advance for your help. I greatly appreciate it! -- Greg __ Greg Woods Cirrus Aviation Services 702-448-2366 702-343-7784 (mobile) ca1:cur root# /usr/sbin/dovecotd --version 1.1.20apple0.5 ca1:cur root# /usr/sbin/dovecotd -n # 1.1.20apple0.5: /private/etc/dovecot/dovecot.conf Warning: fd limit 256 is lower than what Dovecot can use under full load (more than 456). Either grow the limit or change login_max_processes_count and max_mail_processes settings # OS: Darwin 10.8.0 i386 hfs base_dir: /var/run/dovecot syslog_facility: local6 protocols: managesieve imaps listen(default): * listen(imap): * listen(managesieve): *:2000 ssl_ca_file: /etc/certificates/ca1.cirrusav.com.F0D27741B3FD526D70E5B77878084AF217E1E8B4.chain.pem ssl_cert_file: /etc/certificates/ca1.cirrusav.com.F0D27741B3FD526D70E5B77878084AF217E1E8B4.cert.pem ssl_key_file: /etc/certificates/ca1.cirrusav.com.F0D27741B3FD526D70E5B77878084AF217E1E8B4.key.pem ssl_cipher_list: ALL:!LOW:!SSLv2:!aNULL:!ADH:!eNULL login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(managesieve): /usr/libexec/dovecot/managesieve-login login_user: _dovecot login_process_per_connection: no max_mail_processes: 200 mail_max_userip_connections(default): 20 mail_max_userip_connections(imap): 20 mail_max_userip_connections(managesieve): 10 verbose_proctitle: yes first_valid_uid: 6 first_valid_gid: 6 mail_access_groups: mail mail_location: maildir:/var/spool/imap/dovecot/mail/%u mail_debug: yes mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(managesieve): /usr/libexec/dovecot/managesieve mail_process_sharing(default): full mail_process_sharing(imap): full mail_process_sharing(managesieve): none mail_max_connections(default): 5 mail_max_connections(imap): 5 mail_max_connections(managesieve): 20 mail_plugins(default): quota imap_quota mail_plugins(imap): quota imap_quota mail_plugins(managesieve): mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(managesieve): /usr/lib/dovecot/managesieve sieve_storage(default): sieve_storage(imap): sieve_storage(managesieve): /var/spool/imap/dovecot/sieve-scripts/%u sieve(default): sieve(imap): sieve(managesieve): /var/spool/imap/dovecot/sieve-scripts/%u/dovecot.sieve lda: postmaster_address: postmas...@example.com hostname: ca1.cirrusav.com mail_plugins: cmusieve quota quota_full_tempfail: yes sendmail_path: /usr/sbin/sendmail auth_socket_path: /var/run/dovecot/auth-master log_path: /var/log/mailaccess.log info_log_path: /var/log/mailaccess.log auth default: mechanisms: gssapi cram-md5 verbose: yes debug: yes debug_passwords: yes passdb: driver: od userdb: driver: od args: partition=/etc/dovecot/partition_map.conf enforce_quotas=no socket: type: listen master: path: /var/run/dovecot/auth-master mode: 384 user: _dovecot group: mail plugin: quota_warning: storage=100%% /usr/libexec/dovecot/quota-exceeded.sh quota_warning2: storage=90%% /usr/libexec/dovecot/quota-warning.sh quota: maildir:User quota sieve: /var/spool/imap/dovecot/sieve-scripts/%u/dovecot.sieve # # /var/log/mail.log for a FAILED delivery # # Aug 3 15:20:18 ca1 postfix/smtpd[2964]: connect from midas.utopiasystems.net[64.74.150.12] Aug 3 15:20:18 ca1 postfix/smtpd[2964]: C1B521510216: client=midas.utopiasystems.net[64.74.150.12] Aug 3 15:20:18 ca1 postfix/cleanup[2973]: C1B521510216: message-id=<
Re: [Dovecot] Enhanced Kerberos support
Timo Sirainen <[EMAIL PROTECTED]> writes: >> SSH recently added this enhancement to address this common need: >> >> GSSAPIStrictAcceptorCheck >> Determines whether to be strict about the identity of the >> GSSAPI acceptor a client authenticates >> against. If “yes” then the client must authenticate against >> the host service on the current hostname. >> If “no” then the client may authenticate against any service >> key stored in the machine’s default >> store. This facility is provided to assist with operation on >> multi homed machines. The default is >> “yes”. Note that this option applies only to protocol version >> 2 GSSAPI connections, and setting it >> to “no” may only work with recent Kerberos GSSAPI libraries. > > Somehow this doesn't sound a very good idea. This says "the host service on the current hostname", and I interpret this as the principal "host/[EMAIL PROTECTED]", where $hostname is the value returned by gethostname(3)/hostname(1). There is no DNS involved in this at all. The alternative is to accept authentication to any principal either of the form "host/[EMAIL PROTECTED]", as long as that key is stored in the machine's keytab. None of this involves DNS lookups. >> I've heard that other daemons support multi-names by instead of using >> gethostname(), obtain the hostname of the >> interface that the request came in on. > > I guess this would mean a PTR DNS lookup for the local IP? I've wanted > to avoid DNS lookups in Dovecot so far, but proxying would also want to > use them.. Yes, you could do this, allowing authentication to various names, depending on the interface. But I would think it's better to have an option to either a) just allow the name that's configured as hostname, or b) allow any host/ key that's in the keytab. I don't see that it's useful from a security viewpoint to refuse authentication that's done to host/foo when the request is received on an interface that has an IP address that doesn't map to foo. Actually, I'd say that it isn't meaningful, for TCP at least, to talk about the interface on which a request was received, and even for UDP packets can arrive on arbitrary interfaces due to routing changes, and generally these have no security consequences. > I guess blocking DNS lookups for local IPs should be pretty safe and > fast. Why? If the local DNS responder is hosed, it will be messy. But this is much less scary than lookups on random addresses. What problem are we trying to solve? The problem I can see is that if a server is known by two names, clients may attempt to authenticate to both of those names, and that should work (assuming both names have service keys present in the keytab). Are people trying to run some inside/outside split mailserver that's both inside and outside a firewall?
Re: [Dovecot] Dovecot-imap, tls, gnus
[dovecot closing connections to gnus, making gnus fail to exit group] I use gnus and I think that the closed connection happens to me once in a while. gnus just reopens it - I'm running the head of Gnus CVS. So this feels like a gnus bug.
[Dovecot] Can't get apop to work.
Hi Folks, I'm fairly new to linux so this message may reflect that. dovecot info (running on CentOS 5.0): protocols: pop3s listen: ssl_cert_file: /etc/pki/dovecot/certs/dovecot.pem ssl_key_file: /etc/pki/dovecot/private/dovecot.pem login_dir: /usr/local/var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/pop3-login mail_executable: /usr/local/libexec/dovecot/pop3 mail_plugin_dir: /usr/local/lib/dovecot/pop3 pop3_uidl_format: %v.%u auth default: debug: yes debug_passwords: yes passdb: driver: pam userdb: driver: passwd If I select apop as one of the allowed protocols (in order to avoid having to use ssl) I get this error message in the mail log : "APOP mechanism can't be supported with given passdbs" I tried fiddling with PAM by adding an /etc/pam.d/apop file with these contents : auth required pam_unix.so nullok account required pam_unix.so makes no difference, in anycase as much reading as I;ve done to understand PAM I still have not much clue: the docs are quite obscure. My /etc/pam.d/dovecot file looks like this : #%PAM-1.0 auth required pam_nologin.so auth include system-auth account include system-auth session include system-auth At this point I seem to be out of options. I've been through the docs, and trawled the internet. Anyone know what I'm doing wrong? Thanks, Greg - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: [Dovecot] Can't get apop to work.
> I tried fiddling with PAM by adding an /etc/pam.d/apop file with these > contents : It's impossible to support anything but plaintext authentication with PAM. See http://wiki.dovecot.org/Authentication/Mechanisms and http://wiki.dovecot.org/Authentication/PasswordSchemes I'm not overly worried about PAM; I just want to get APOP working. But the wiki doesn't give me even the faintest idea, keeping in mind that I am relatively new to linux. The same applies to all the other authentication schemes. It only tells me how to change the conf file, which doesn't appear to be enough. Obviously I am missing something here. But I don't know what. - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
[Dovecot] gnus/dovecot open transactions panic
I have been using dovecot with gnus for a long time. Recently, I started getting failures, and I think it's a dovecot problem triggered by gnus being more aggressive, but I'd like to hear opinions about whether I should pursue this as a gnus bug. The log shows: Oct 25 19:27:36 gdtserver dovecot: IMAP(gdt): Panic: Trying to close mailbox foo.bar with open transactions Oct 25 19:27:36 gdtserver dovecot: dovecot: child 26231 (imap) killed with signal 6 (core not dumped - set mail_drop_priv_before_exec=yes) and this seems to be triggered when dovecot is going GCC: to a local mailbox (not imap) when sending, but also semi-randomly. most of dovecot -n: (I'm sure that I'm not having auth problems and would rather not post that part): # 1.2.14: /usr/pkg/etc/dovecot.conf # OS: NetBSD 5.1_RC1 i386 protocols: imaps login_dir: /var/run/dovecot/login login_executable: /usr/pkg/libexec/dovecot/imap-login login_processes_count: 4 login_max_processes_count: 16 max_mail_processes: 32 first_valid_uid: 128 mail_location: maildir:~/IMAP I have 162 mailboxes polled by gnus on this dovecot instance. I get the panic on various mailboxes and I can't see a pattern. I do get Checking new news... nnimap-send-command: SIGPIPE raised on process *nnimap*; closed it From gnus. I then look at the listed one in the panic, and *imap-log* From gnus. This just may be an artifact of pipelining, but the panic-list mbox has 30 more after it that were sent, as in: 19:35:43 506 EXAMINE "mbox.named-in-panic" (QRESYNC (1208908407 1)) [30 more lines] I'm guessing that this is a dovecot problem. I realize I should update to 1.2.15 :-) but I didn't see anything in the 1.2.15 release notes that looks like a match. pgpSUfgaRqUhp.pgp Description: PGP signature
Re: [Dovecot] [OT] dovecot appliance
On 28/10/2010 12:22 μμ, Spyros Tsiolis wrote: --- On Thu, 28/10/10, Johan Hendriks wrote: Hello all. I am reading the mailinglist for a long time now, and there was a thread i believe called webgui or something. In this thread there was a company i believe german, that was working on a dovecot appliance with a web based gui to administrate a dovecot mail server. The problem is i did not save the URL of that company. Does anyone know which company make the appliance. Or does anyone knows a good webbased tool for dovecot. The reason is that in a windows environment, with only a few FreeBSD machine's , my collega's get frustrated if they can not use a mouse. They even want a mouse on there smartphone's :D I am doing the administration of the mail server, but when i am not there, it would be nice if they can do things them selves. thanks for your time. regards, Johan Hen Perhaps you could try Webmin (www.webmin.com). It has a Dovecot administration module as well.
Re: [Dovecot] gnus/dovecot open transactions panic
Timo Sirainen writes: > On Tue, 2010-11-02 at 16:57 +, Timo Sirainen wrote: >> On Mon, 2010-10-25 at 19:42 -0400, Greg Troxel wrote: >> > Oct 25 19:27:36 gdtserver dovecot: IMAP(gdt): Panic: Trying to >> > close mailbox foo.bar with open transactions >> .. >> > 19:35:43 506 EXAMINE "mbox.named-in-panic" (QRESYNC (1208908407 1)) >> >> Could you try if the attached patch fixes it? > > No, forget about that patch. This fixes it: > http://hg.dovecot.org/dovecot-1.2/rev/b30af25c622d Sorry for the long delay. I have upgraded to 1.2.16 (which I'm 99% sure has that patch) and re-enabled QRESYNC in gnus, and it seems to work fine. Thanks for the fix. pgpbP7Fo8M6j5.pgp Description: PGP signature
[Dovecot] Cannot create auth-master file
Hi all, I'm trying to get postfix and dovecot working nicely together to process and store mail for both local (system) on one domain and virtual users and a few different domains. I've got postfix up and running quite nicely, but am having a few problems with Dovecot. Every time postfix tried to delivery a message to a virtual user using dovecot I get an error like the following in /var/log/mail.log: Mar 8 21:53:58 rhy postfix/pipe[6616]: 89C94846E: to=, orig_to=, relay=dovecot, delay=8795, delays=8794/0.01/0/0.61, dsn=4.3.0, status=deferred (temporary failure) At the same instant, in my dovecot log I'll get this error: deliver(gr...@gregsfamily.com): 2010-03-08 21:53:58 Error: Can't connect to auth server at /var/run/dovecot/auth-master: Connection refused So, I'm guessing that this is a permissions issue (somewhere) and that the dovecot process is not able to create the file /var/run/dovecot/auth-master. The permissions on this folder are as follows: gr...@rhy:/etc/dovecot$ ls -al /var/run/dovecot/ total 0 drwxr-xr-x 3 root root100 2010-03-08 21:44 . drwxr-xr-x 15 root root660 2010-03-08 22:00 .. srw--- 1 vmail root 0 2010-03-08 21:43 auth-master srwxrwxrwx 1 root root 0 2010-03-08 21:43 dict-server drwxr-x--- 2 root dovecot 60 2010-03-08 21:44 login I've searched around for hours, found several threads describing similar issues, but no solutions that have worked for me. If anyone is able to give me any pointers or suggestions I would be most grateful. My dovecot configuration is: gr...@rhy:/etc/dovecot$ sudo dovecot -n # 1.1.11: /etc/dovecot/dovecot.conf # OS: Linux 2.6.28-18-generic x86_64 Ubuntu 9.04 ext3 log_timestamp: %Y-%m-%d %H:%M:%S protocols: imaps pop3s imap pop3 login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login mail_privileged_group: mail mail_location: maildir:/home/vmail/%d/%u mail_debug: yes mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 auth default: mechanisms: plain login user: vmail debug: yes debug_passwords: yes passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: static args: uid=5000 gid=5000 home=/home/vmail/%d/%n allow_all_users=yes socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail :wq G
Re: [Dovecot] Cannot create auth-master file
Hi Timo, Thanks very much for spotting this... 4 hours spent tweaking the wrong config... Doh! :-). All working now. :wq On 8 Mar 2010, at 22:35, Timo Sirainen wrote: > On Mon, 2010-03-08 at 22:06 +0000, Greg Frith wrote: >> gr...@rhy:/etc/dovecot$ sudo dovecot -n >> # 1.1.11: /etc/dovecot/dovecot.conf >> # OS: Linux 2.6.28-18-generic x86_64 Ubuntu 9.04 ext3 > > If you're using Ubuntu's dovecot-postfix package, it's actually > using /etc/dovecot/dovecot-postfix.conf, not dovecot.conf. >
Re: [Dovecot] Cannot create auth-master file
Hi all, Sorry, I thought a migration to /etc/dovecot/dovecot-postfix.conf would do the trick, but it would appear (after several hours of grappling with a new problem) that 'something' is still reading configuration information from /etc/dovecot/dovecot.conf. Essentially I've been having problems getting dovecot to deliver mail to the correct location using mail_location and the 'userdb static' arg parameter. I finally deduce that no matter what I change I cannot get the mail delivered to the correct location, and in fact, after inserting a load of bogus values, mail would still arrive without problem at /home/vmail/%d/%n/. It turns out that 'something', I'm guessing maybe /usr/lib/dovecot/deliver is reading configuration from /etc/dovecot/dovecot.conf, and not the -postfix.conf variant which I am now trying to maintain. I've checked the Ubuntu Server documentation for dovecot which makes all references to dovecot.conf and never to dovecot-postfix.conf. Maybe I should be looking at documentation for the combined postfix/dovecot package, but I haven't found this anywhere. Essentially, can anyone either explain to me how the two files are meant to work in harmony together, or confirm that I won't cause myself any problems further down the line by removing dovecot-postfix.conf? Sorry to bug the list with such amateurish questions :-). Cheers, Greg. On 8 Mar 2010, at 22:35, Timo Sirainen wrote: > On Mon, 2010-03-08 at 22:06 +, Greg Frith wrote: >> gr...@rhy:/etc/dovecot$ sudo dovecot -n >> # 1.1.11: /etc/dovecot/dovecot.conf >> # OS: Linux 2.6.28-18-generic x86_64 Ubuntu 9.04 ext3 > > If you're using Ubuntu's dovecot-postfix package, it's actually > using /etc/dovecot/dovecot-postfix.conf, not dovecot.conf. >
Re: [Dovecot] Cannot create auth-master file
Hi all,
Thanks to Pascal here for suggesting that I pass the configuration file to the
deliver process. In fact, what I have done is uninstalled the Ubuntu
dovecot-postfix package in favour of a 'clearer' postfix, dovecot etc stack of
my own. Having dug a big deeper in various ubuntu forums, it would appear that
others have had similar problems with the dovecot LDA reading its configuration
from the main rather than -postfix variant of the configuration.
I'll file a bug with Ubuntu.
Thanks for you help.
Advice for other reading this thread, stick with installing and configuring the
individual components yourself!
:wq.
On 9 Mar 2010, at 16:50, Pascal Volk wrote:
> On 03/09/2010 05:02 PM Greg Frith wrote:
>> Hi all,
>>
>> Sorry, I thought a migration to /etc/dovecot/dovecot-postfix.conf would do
>> the trick, but it would appear (after several hours of grappling with a new
>> problem) that 'something' is still reading configuration information from
>> /etc/dovecot/dovecot.conf.
>>
>> Essentially I've been having problems getting dovecot to deliver mail to the
>> correct location using mail_location and the 'userdb static' arg parameter.
>> I finally deduce that no matter what I change I cannot get the mail
>> delivered to the correct location, and in fact, after inserting a load of
>> bogus values, mail would still arrive without problem at /home/vmail/%d/%n/.
>> It turns out that 'something', I'm guessing maybe /usr/lib/dovecot/deliver
>> is reading configuration from /etc/dovecot/dovecot.conf, and not the
>> -postfix.conf variant which I am now trying to maintain.
>>
>> I've checked the Ubuntu Server documentation for dovecot which makes all
>> references to dovecot.conf and never to dovecot-postfix.conf. Maybe I
>> should be looking at documentation for the combined postfix/dovecot package,
>> but I haven't found this anywhere.
>>
>> Essentially, can anyone either explain to me how the two files are meant to
>> work in harmony together, or confirm that I won't cause myself any problems
>> further down the line by removing dovecot-postfix.conf?
>>
>> Sorry to bug the list with such amateurish questions :-).
>
> a) Please file a bug report in the Unbuntu bug tracking system.
> b) in master.cf change:
> … argv=/path/2/dovecot/deliver -f ${sender} …
> to:
> … argv=/path/2/dovecot/deliver -c /path/to/config -f ${sender} …
>
>
> Regards,
> Pascal
> --
> The trapper recommends today: fabaceae.1006...@localdomain.org
[Dovecot] Unresolved client rejection
Hi, would it be possible to prevent users who try to login from an unresolved IP from connecting to Dovecot IMAP? I have a suspicion that it should be done via the authentication module (ie PAM) but I am not sure (if this is the case could someone recommend a good resource or even a solution). For example sendmail has a relevant macro to achieve this, I was wondering if Dovecot can have similar behavior. Thanks
[Dovecot] Migration - Dovecot to Dovecot
Hi, I am using Dovecot with mbox format, and I am interested to move to Maildir. I have run the modified script (mb2md) but it seems UIDs are not preserved. I don't know how to verify this, but my client seems to be downloading all messages again. Can someone help?
[Dovecot] Configure unsuccessful login attempts
Hi, using PAM, how can I configure how many attempts a user can make to connect, and if exceeding a certain number, block him for a specified amount of time? Any idea what the defaults are?
Re: [Dovecot] Configure unsuccessful login attempts
You could use fail2ban, see also: http://wiki.dovecot.org/HowTo/Fail2Ban So I guess the result would be to the login process become unresponsive, right? I am not sure this would be what I want. The desired behaviour for me would be to reject the connection even if the password becomes correct after several failures. I realise this would not help under DoS scenarios (in which I think fail2ban is targetting). I will give it a try, of course, but I was wondering if another approach is possible. Generally speaking, it would be really nice if Dovecot itself had such options.
[Dovecot] Maildir + /var/mail
Hi, I have just switched to Maildir, and I have noticed something. Even though it works properly, I have noticed that a file named /var/mail/user with 0 bytes length is still created. Is this normal? I use sendmail+procmail+dovecot. I have also tried the combined procmail+deliver approach with the same results. I also use a global /etc/procmailrc. Thank you
Re: [Dovecot] Maildir + /var/mail
It stopped being a problem for me anyway because I changed some config in my MTA (Exim4) for another reason which happened to mean that Procmail was no longer invoked in most cases. But I think it may be fixable in the Procmail space. What is in your /etc/procmailrc ? Quite simple at the moment. LOGFILE="/var/log/procmail.log" DEFAULT="$HOME/Maildir/" MAILDIR="$HOME/Maildir/" I also notice some permission issues, no matter if I use a global procmailrc or one in user's homedir. It complains not being able to write Dovecot's log file. In practice, I had to force the following permissions: 666 /var/log/dovecot.log 666 /var/log/procmail.log
Re: [Dovecot] importing outlook express messages to dovecot imap server
I have a local Dovecot 1.1.4 running. I have a big number of outlook express messages that I like to put into Maildir so that I can use Dovecot's imap to access. I can convert them into mbox format. any available means for me to import outlook express/mbox messages into Maildir/Dovecot? command line will be preferred, Thanks, Angelo Perhaps you can first convert them to mbox and then to Maildir. See: http://wiki.dovecot.org/Migration/MailFormat
[Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve
"from" "*" { set "from" "${1}"; }
debug_log "EnvelopeTo=${to}, EnvelopeFrom=${from}";
debug_log "EnvelopeToUser=${user}, EnvelopeToDetail=${detail}";
$ telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 tharned.org ESMTP Sendmail 8.14.7/8.14.7; Sun, 5 Jan 2014 23:56:22 -0600 (CST)
mail from:
250 2.1.0 ... Sender ok
rcpt to:
250 2.1.5 ... Recipient ok
data
354 Enter mail, end with "." on a line by itself
.
250 2.0.0 s065uMYM069381 Message accepted for delivery
quit
221 2.0.0 tharned.org closing connection
Connection closed by foreign host.
$ tail -4 .dovecot.sieve.log
sieve: info: started log at Jan 05 23:57:21.
main script: line 5: info: DEBUG: EnvelopeTo=gcr, EnvelopeFrom=g...@tharned.org.
main script: line 9: info: DEBUG: EnvelopeToUser=gcr, EnvelopeToDetail=.
info: msgid=<201401060557.s065umym069...@tharned.org>: stored mail into mailbox
'INBOX'.
$ exit
Script done on Sun Jan 5 23:57:55 2014
--
Greg Rivers
Re: [Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve
On Mon, 6 Jan 2014, I wrote:
I found this[1] thread that describes the same problem with dovecot-LDA,
but the solution (add X-Original-To: header) has no effect with LMTP.
My sendmail LMTP configuration:
FEATURE(`local_lmtp',`[IPC]',`FILE /var/run/dovecot/lmtp')
Sendmail's address test indicates that sendmail is providing user+detail
to LMTP (see below). Except for this problem, dovecot, LMTP, and sieve
are all working perfectly. Is there something I'm missing, or is this a
bug?
[1] http://dovecot.org/pipermail/dovecot/2012-July/136987.htm
It seems I was mistaken. By tracing the LMTP session between dovecot and
sendmail I found that sendmail does _not_ include the +detail in RCPT TO:.
I also determined that dovecot LMTP will in fact extract the +detail from
a X-Original-To: header, but only if one defines
lda_original_recipient_header.
So for the archives, to get sieve's "envelope :detail ..." working with
sendmail and dovecot LMTP, do the following:
1) Add "lda_original_recipient_header = X-Original-To" to 15-lda.conf
2) Add the following rule to sendmail.mc to add a X-Original-To: header
to every message:
LOCAL_CONFIG
H?${u}?X-Original-To: $u
--
Greg Rivers
Re: [Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve
On Tue, 7 Jan 2014, Sean Kamath wrote: Glad to know my "for the archives" message(*) helped. :-) Indeed it did. Thanks! I was surprised to find that sendmail does not pass +detail during LMTP, even though the default EnvToL rewrite rule declared in the local LMTP mailer definition preserves it. This was my first dovecot setup, so I didn't realize at first that the lda_original_recipient_header in the LDA config file would also take effect for LMTP. Once I figured that out, it was a simple matter to use your LOCAL CONFIG rule to have sendmail add the requisite header. On Wed, 8 Jan 2014, Charles Marcus wrote: So... this is a hack to get x-original-to header support in LMTP... Hopefully Timo will see this and be able to fix this up so it supports it natively like the LDA does... Given that LMTP does in fact parse X-Original-To (or any other header of your choice) when lda_original_recipient_header is defined, I think one would say that dovecot LMTP does already support this natively. So it's not really a hack, it's just a matter of setting the dovecot config variable and ensuring that the MTA adds the corresponding header to each message. -- Greg Rivers
Re: [Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve
On Wed, 8 Jan 2014, Miquel van Smoorenburg wrote:
On 8-01-14 5:46 PM, Charles Marcus wrote:
On 2014-01-07 9:20 PM, Greg Rivers wrote:
So for the archives, to get sieve's "envelope :detail ..." working
with sendmail and dovecot LMTP, do the following:
1) Add "lda_original_recipient_header = X-Original-To" to 15-lda.conf
2) Add the following rule to sendmail.mc to add a X-Original-To:
header to every message:
LOCAL_CONFIG
H?${u}?X-Original-To: $u
This probably only works if there is exactly one RCPT TO in the LMTP
session. If there are multiple recipients, sendmail cannot add that
header. What should it contain?
So you have to limit sendmail to max. one recipient per LMTP session.
Hopefully you don't use SIS.
That's a really good point I hadn't considered. Even without this
complication, it would obviously be better to have sendmail provide
user+deatil via RCPT TO during LMTP. But I don't know to accomplish that.
Does anyone else know?
--
Greg
Re: [Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve
On Wed, 8 Jan 2014, Charles Marcus wrote: On 2014-01-08 2:27 PM, Greg Rivers wrote: Given that LMTP does in fact parse X-Original-To (or any other header of your choice) when lda_original_recipient_header is defined, I think one would say that dovecot LMTP does already support this natively. So it's not really a hack, it's just a matter of setting the dovecot config variable and ensuring that the MTA adds the corresponding header to each message. Ok, cool... so... if I am getting the header right now, using the dovecot LDA, then obviously the MTA is adding it. Last question on this then - can I add this, then take my time switching from the LDA to LMTP? Or would enabling it while stll using the LDA cause an issue somehow, and I should wait and only enable it after switching to LMTP? If I understand you correctly, you're saying that LDA parses X-Original-To even without having the lda_original_recipient_header variable set. If that's the case, I'd think that setting "lda_original_recipient_header = X-Original-To" would be a NOOP as far as LDA is concerned, and you could transition to LMTP at your leisure. -- Greg Rivers
Re: [Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve
On Thu, 9 Jan 2014, Steffen Kaiser wrote:
On Tue, 7 Jan 2014, Greg Rivers wrote:
[snip]
So for the archives, to get sieve's "envelope :detail ..." working with
sendmail and dovecot LMTP, do the following:
1) Add "lda_original_recipient_header = X-Original-To" to 15-lda.conf
2) Add the following rule to sendmail.mc to add a X-Original-To: header to
every message:
LOCAL_CONFIG
H?${u}?X-Original-To: $u
First: This won't work, if the message has two or more recipients, $u is
empty then.
Right. Miquel van Smoorenburg pointed that out too earlier in this thread.
Do you serialize messages per recipient?
Yes, to mitigate this issue, I plan to enforce one recipient per LMTP
session with: define(`LOCAL_MAILER_MAXMSGS', `1'). This will result in
adding "m=1" to the local mailer definition.
But I'd really rather have +detail passed via LMTP.
Second: My Debian sendmail v8.14.4 does pass +detail to LMTP.
Mlocal, P=[IPC], F=lsDFMAw5:/|@qPSXnz9, S=EnvFromSMTP/HdrFromL,
R=EnvToL/HdrToL,
T=DNS/RFC822/SMTP,
A=FILE /var/run/dovecot2.2/lmtp
looks like just:
FEATURE(`local_lmtp',`[IPC]',`FILE /var/run/dovecot2.2/lmtp')dnl
of my mc-file effects it.
Now this is a really useful data point! I have exactly the same
configuration on FreeBSD running sendmail v8.14.7:
FEATURE(`local_lmtp',`[IPC]',`FILE /var/run/dovecot/lmtp')
Mlocal, P=[IPC], F=lsDFMAw5:/|@qPSXmnz9, S=EnvFromSMTP/HdrFromL,
R=EnvToL/HdrToL,
T=DNS/RFC822/SMTP,
A=FILE /var/run/dovecot/lmtp
The use of forwarding, aliases or virtuser table might strip the detail, you
need to do explicitly preserve the +detail with those. Retry with a recipient
without any rewriting and from the local host.
echo TEST | sendmail -v recpient+det...@yourdomain.tld
Received: from ux-2s11.inf.fh-bonn-rhein-sieg.de
by ux-2s11.inf.fh-bonn-rhein-sieg.de (Dovecot) with LMTP id
aC4NEHRMzlK7dgAALie3fw
for ; Thu, 09 Jan 2014 08:15:00 +0100
I'm not using any aliases or virtuser table in my tests, yet my sendmail
DOES NOT pass +detail to LMTP:
$ echo TEST | sendmail -v gcr+det...@badger.tharned.org
gcr+det...@badger.tharned.org... Connecting to [127.0.0.1] via relay...
220 badger.tharned.org ESMTP Sendmail 8.14.7/8.14.7; Thu, 9 Jan 2014 16:19:46
-0600 (CST)
EHLO badger.tharned.org
250-badger.tharned.org Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
VERB
250 2.0.0 Verbose mode
MAIL From: SIZE=5
250 2.1.0 ... Sender ok
RCPT To:
DATA
250 2.1.5 ... Recipient ok
354 Enter mail, end with "." on a line by itself
.
050 ... Connecting to /var/run/dovecot/lmtp via
local...
050 220 badger.tharned.org Dovecot ready.
050 >>> LHLO badger.tharned.org
050 250-badger.tharned.org
050 250-8BITMIME
050 250-ENHANCEDSTATUSCODES
050 250 PIPELINING
050 >>> MAIL From:
050 250 2.1.0 OK
050 >>> RCPT To:
050 >>> DATA
050 250 2.1.5 OK
050 354 OK
050 >>> .
050 250 2.0.0 OD97EoIgz1L04QAAwQnkQQ Saved
050 ... Sent
250 2.0.0 s09MJkLK057843 Message accepted for delivery
gcr+det...@badger.tharned.org... Sent (s09MJkLK057843 Message accepted for
delivery)
Closing connection to [127.0.0.1]
QUIT
221 2.0.0 badger.tharned.org closing connection
Return-Path:
Delivered-To:
Received: from badger.tharned.org
by badger.tharned.org (Dovecot) with LMTP id OD97EoIgz1L04QAAwQnkQQ
for ; Thu, 09 Jan 2014 16:19:46 -0600
Return-Path:
Received: from badger.tharned.org (localhost [127.0.0.1])
by badger.tharned.org (8.14.7/8.14.7) with ESMTP id s09MJkLK057843
for ; Thu, 9 Jan 2014 16:19:46 -0600
(CST)
(envelope-from g...@badger.tharned.org)
Received: by badger.tharned.org (8.14.7/8.14.7/Submit) id s09MJjbI057842
for gcr+det...@badger.tharned.org; Thu, 9 Jan 2014 16:19:45 -0600 (CST)
(envelope-from gcr)
Date: Thu, 9 Jan 2014 16:19:45 -0600 (CST)
From: Greg Rivers
Message-Id: <201401092219.s09mjjbi057...@badger.tharned.org>
To: undisclosed-recipients:;
TEST
So I clearly have a sendmail problem. Maybe there's been a regression in
sendmail since 8.14.4, or there's some other platform specific issue.
This gives me something to go on; thanks a lot for your feedback!
--
Greg Rivers
Re: [Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve
On Fri, 10 Jan 2014, Steffen Kaiser wrote: try sendmail -bv -d60.5 -d27.2 -d21.12 gcr+det...@badger.tharned.org - -d60.5 - trace map lookups - -d27.2 - traces processing of aliases and forwards - -d21.12 - trace R line processing IMHO: If all map lookups return NOTFOUND, the detail is preserved, otherwise it is the duty of the map to preserve the detail. If I read the traces (attached) correctly, the +detail makes it unscathed through the maps, aliases, and rule sets. If that's the case, it would indicate that the problem is with sendmail's LMTP code. Do you concur? -- Greg Rivers bv.log.xz Description: sendmail -bv trace output
Re: [Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve
On Sat, 11 Jan 2014, Steffen wrote: I have: ... deliverable: mailer local, user uid+detail instead of "deliverable: mailer local, host detail, user gcr" Hmm, see http://etutorials.org/Server+Administration/Sendmail/Part+I+Build+and+Install/Chapter+4.+Configure+sendmail.cf+with+m4/FEATUREpreserve_local_plus_detail/ My mc-file has this setting commented out (prefixed by dnl). Ah, I see where the processing differs. I had added this: SLocal_localaddr R< $* > $1 Remove <> from address R$+ + $*$: $1 Remove detail from address R$+ $: <$(localuser $1 $: TEMPFAIL $)> $1 Query socket map server, if that's a local user R $*$# ok yes, this preserves detail R $*$# error $@ 5.7.1 $: 550 User unknown R $* $# error $@ TEMPFAIL $: $1 try again later Does it work See the R line. The map is to verify if the user is local or not. In my system sendmail cannot do so on its own. Maybe the FEATURE above works for the standard config. "FEATURE(`preserve_local_plus_detail')" is actually one of the first things I tried when I started working on this problem, but it doesn't quite work with the standard configuration: $ sendmail -bv -d21.12 gcr+xy...@badger.tharned.org ... rewrite: ruleset finalreturns: gcr + XYZZY rewrite: ruleset localaddr input: gcr + xyzzy -trying rule: $+ -rule matches: $: $1 $| $> "Local_localaddr" $1 -skip subr Local_localaddr (197) rewritten as: gcr + xyzzy $| gcr + xyzzy -trying rule: $+ $| $# ok - rule fails -trying rule: $+ $| $# $* - rule fails -trying rule: $+ $| $* -rule matches: $: $1 rewritten as: gcr + xyzzy -trying rule: $+ -rule matches: $: < > $1 rewritten as: < > gcr + xyzzy -trying rule: < > $+ -rule matches: $@ $1 rewritten as: gcr + xyzzy rewrite: ruleset localaddrreturns: gcr + xyzzy gcr+xy...@badger.tharned.org... User unknown It does preserve the +detail, but according to the trace, it has a problem with Local_localaddr, and apparently fails because it's including the +detail when it does the local account look-up. Here's what my Local_localaddr ruleset looks like with the preserve_local_plus_detail feature: ### ### Ruleset 5 -- special rewriting after aliases have been expanded ### ### SLocal_localaddr Slocaladdr=5 R$+ $: $1 $| $>"Local_localaddr" $1 R$+ $| $#ok $@ $1 no change R$+ $| $#$* $#$2 R$+ $| $* $: $1 # prepend an empty "forward host" on the front R$+ $: <> $1 R< > $+ $@ $1 R< local : $* > $*$: $>MailerToTriple < local : $1 > $2 no host extension R< error : $* > $*$: $>MailerToTriple < error : $1 > $2 no host extension R< $~[ : $+ > $+ $: $>MailerToTriple < $1 : $2 > $3 < @ $2 > R< $+ > $+$@ $>MailerToTriple < $1 > $2 < @ $1 > Perhaps I should file this as a bug at sendmail.org? -- Greg
Re: [Dovecot] Dovecot LMTP does not pass envelope recipient +detail to sieve
On Tue, 14 Jan 2014, Steffen Kaiser wrote: "FEATURE(`preserve_local_plus_detail')" is actually one of the first things I tried when I started working on this problem, but it doesn't quite work with the standard configuration: $ sendmail -bv -d21.12 gcr+xy...@badger.tharned.org -rule matches: $@ $1 rewritten as: gcr + xyzzy rewrite: ruleset localaddrreturns: gcr + xyzzy gcr+xy...@badger.tharned.org... User unknown OK, that rings a bell: the problem is the "w" flag. It checks that a valid system exists. If you remove the "w" flag, you loose the system user validaty check and the .forward feature. Yes, I had considered that. You have four ways, IMHO: a) switch to LDA That's what I plan to do in the interim. b) add Local_localaddr to validate the user yourself and accept that the .forward feature is not working I can't do without .forward. c) I've patched sendmail's mailbox database code with a Dovecot stub, that queries the UserDB socket for validity of the users. If you use system users, you could probably just patch libsm/mbdb.c: mbdb_pw_lookup(name, user) to cut the +detail, something like: [snip] d) try a PAM module in pam.d/sendmail, that strips the +detail before processing the request These would be a last resort. e) try to file a bug with sendmail. Actually I did that yesterday. Claus Assmann is looking at it with me, so I'm sure to get more good advise. Thanks for looking at it and for your really useful suggestions. (BTW, options a through e is five ways, not four. :-) I'll keep this thread updated with my findings. -- Greg
Re: [Dovecot] Sieve is not getting the propper RCPT from the LMTP daemon
On Tue, 11 Feb 2014, Stephan Bosch wrote: On 12/24/2013 2:15 PM, klondike wrote: The relevant lines for the test e-mail I sent are these: sieve: info: started log at Dec 24 13:37:23. main script: line 9: info: DEBUG: envelope to `klondike (at) gentoo.org'. main script: line 10: info: DEBUG: envelope from `klondike (at) gentoo.org'. info: msgid=<52b97ff7.6050...@gentoo.org>: stored mail into mailbox 'INBOX'. A similar issue was mentioned and solved a little later on the mailing list, so that is why I forgot about this one. That involved Sendmail though: http://www.dovecot.org/list/dovecot/2014-January/094385.html If you read further down that thread, you'll see that both Miquel van Smoorenburg and Steffen Kaiser pointed out that this solution only works in the case where there is one and only one recipient. So it's not a general solution. Because of that, I am using dovecot LDA instead of LMTP until I can write a custom sendmail ruleset to pass +detail to LMTP. Here's my sendmail LDA configuration ($h contains the detail part of the ID): FEATURE(`local_procmail', `/usr/local/libexec/dovecot/dovecot-lda', `dovecot-lda -a $u+$h -d $u') -- Greg
Is atomic MOVING of messages between IMAP folders possible?
I would like to use a shared IMAP account, with multiple users accessing it simultaneously. The users would take ownership of messages by first attempting to MOVE the messages from the Inbox, into their private IMAP folder, still within the same account. Now, since there will be multiple users competing for the same messages, I naturally want only ONE of the simultaneous moves to be successful at a time. So far, this isn't working. If I do the move from two clients, simultaneously, the messages can go to *both *destination folders - duplicates can result. Is it possible to configure Dovecot and/or an IMAP client to behave the way I want it to? If the answer to this is YES, then I'll offer my config details. If the answer is NO, the next question is - do any email systems at all behave the way I want? (I tried a hosted Exchange/OWA service - it has the same problem) Thanks & regards, Greg.
Re: Is atomic MOVING of messages between IMAP folders possible?
Yes, both client and server support IMAP MOVE, and both also support CONDSTORE. I have tried both with and without CONDSTORE enabled in the client, with the same result. I am very confident IMAP MOVE is actually being invoked, because intra-account moves occur extremely rapidly. (much faster than inter-account moves, which of course is a copy & delete) Thanks so far. Client is Postbox & Thunderbird on Windows. (I realise Postbox is based on Thunderbird) Greg. On 4 August 2014 22:03, Reindl Harald wrote: > > > Am 04.08.2014 um 14:00 schrieb Timo Sirainen: > > On 04 Aug 2014, at 10:44, Greg Sullivan > wrote: > > > >> I would like to use a shared IMAP account, with multiple users > accessing it > >> simultaneously. The users would take ownership of messages by first > >> attempting to MOVE the messages from the Inbox, into their private IMAP > >> folder, still within the same account. Now, since there will be multiple > >> users competing for the same messages, I naturally want only ONE of the > >> simultaneous moves to be successful at a time. > >> > >> So far, this isn't working. If I do the move from two clients, > >> simultaneously, the messages can go to *both *destination folders - > >> duplicates can result. > >> > >> Is it possible to configure Dovecot and/or an IMAP client to behave the > way > >> I want it to? If the answer to this is YES, then I'll offer my config > >> details. If the answer is NO, the next question is - do any email > systems > >> at all behave the way I want? (I tried a hosted Exchange/OWA service - > it > >> has the same problem) > > > > Dovecot doesn't even attempt to do atomic MOVEs. I don't think any > server will. If you can change the client code, you could use CONDSTORE > instead, which does give atomic STOREs. > > Internet Message Access Protocol (IMAP) - MOVE Extension > http://tools.ietf.org/html/rfc6851 > > well, both, client and server would need to support it > rely on that is unlikely for many years > >
Re: Is atomic MOVING of messages between IMAP folders possible?
Thanks Timo, and no, I can't (easily) change the code of the client. I must say I am extremely disappointed that intra-account moves are not atomic. As far as I can tell, IMAP was designed to allow shared access, so in my opinion this operation should be atomic. Heaven FORBID that I should ask for entire conversation moves to be atomic as well. (which is really what I want) Looks like a bloatware - sorry - helpdesk system - is what I will need to use. Greg. On 4 August 2014 22:44, Timo Sirainen wrote: > On 04 Aug 2014, at 14:12, Greg Sullivan > wrote: > > > Yes, both client and server support IMAP MOVE, and both also support > > CONDSTORE. > > > > I have tried both with and without CONDSTORE enabled in the client, with > > the same result. > > With CONDSTORE I was thinking you could do it something like: > > 1 FETCH 1 (FLAGS MODSEQ) > * 1 FLAGS () MODSEQ 12345 > 2 STORE (UNCHANGEDSINCE 12345) 1 +FLAGS $AtomicMove > 3 MOVE 1 elsewhere > > If another client attempts the same, either 1 will return $AtomicMove in > flags -> abort or 2 will fail with NO. But you should still handle failures > if the client/connection dies between 2 and 3 or 3 fails for some reason. > > But, of course if you can't change the client code to do this then it > doesn't help. > > > I am very confident IMAP MOVE is actually being invoked, because > > intra-account moves occur extremely rapidly. (much faster than > > inter-account moves, which of course is a copy & delete) > > Inter-account physically copies the data (FETCH + APPEND + EXPUNGE). > Alternative to MOVE is COPY + EXPUNGE, which is just as fast as MOVE. > Dovecot actually implements MOVE by internally doing a COPY + EXPUNGE. > >
Re: Is atomic MOVING of messages between IMAP folders possible?
That's promising that it should be doable. (yes, all I want is for the move to only occur once - duplicate messages is not a "move" at all) I'll forward your suggestions to the Thunderbird & Postbox teams. In the meantime I'll continue to evaluate helpdesk systems and "collaborative inbox" products. Greg. On 06/08/2014 2:11 am, "Timo Sirainen" wrote: > Note that MOVE isn't atomic even between moving within one user's folders. > The MOVE RFC itself also doesn't say anything about it ever having to be > atomic. Although if by atomicity you mean that you simply want to make sure > that the same source mail can't be MOVEd twice, that would be doable with > some work I think. Even for full conversations (without partial failures). > > On 05 Aug 2014, at 13:19, Greg Sullivan > wrote: > > > Thanks Timo, and no, I can't (easily) change the code of the client. > > > > I must say I am extremely disappointed that intra-account moves are not > > atomic. As far as I can tell, IMAP was designed to allow shared access, > so > > in my opinion this operation should be atomic. Heaven FORBID that I > should > > ask for entire conversation moves to be atomic as well. (which is really > > what I want) > > > > Looks like a bloatware - sorry - helpdesk system - is what I will need to > > use. > > > > Greg. > > > > > > On 4 August 2014 22:44, Timo Sirainen wrote: > > > >> On 04 Aug 2014, at 14:12, Greg Sullivan > >> wrote: > >> > >>> Yes, both client and server support IMAP MOVE, and both also support > >>> CONDSTORE. > >>> > >>> I have tried both with and without CONDSTORE enabled in the client, > with > >>> the same result. > >> > >> With CONDSTORE I was thinking you could do it something like: > >> > >> 1 FETCH 1 (FLAGS MODSEQ) > >> * 1 FLAGS () MODSEQ 12345 > >> 2 STORE (UNCHANGEDSINCE 12345) 1 +FLAGS $AtomicMove > >> 3 MOVE 1 elsewhere > >> > >> If another client attempts the same, either 1 will return $AtomicMove in > >> flags -> abort or 2 will fail with NO. But you should still handle > failures > >> if the client/connection dies between 2 and 3 or 3 fails for some > reason. > >> > >> But, of course if you can't change the client code to do this then it > >> doesn't help. > >> > >>> I am very confident IMAP MOVE is actually being invoked, because > >>> intra-account moves occur extremely rapidly. (much faster than > >>> inter-account moves, which of course is a copy & delete) > >> > >> Inter-account physically copies the data (FETCH + APPEND + EXPUNGE). > >> Alternative to MOVE is COPY + EXPUNGE, which is just as fast as MOVE. > >> Dovecot actually implements MOVE by internally doing a COPY + EXPUNGE. > >> > >> > >
Re: Re: Is atomic MOVING of messages between IMAP folders possible?
Jochen, I don't have any in-depth knowledge of the IMAP protocol. I'm just saying that given that IMAP is designed for concurrent access from multiple clients, I would have expected it to behave much better when more than one person attempts to move a message, that's all. I was gobsmacked when I discovered that duplicates could easily occur! Quote from the IMAP wikipedia page: Internet Message Access Protocol (IMAP) is a protocol for e-mail retrieval and storage developed by Mark Crispin in 1986 at Stanford University as an alternative to POP. IMAP unlike POP, specifically allows multiple clients simultaneously connected to the same mailbox, and through flags stored on the server, different clients accessing the same mailbox at the same or different times can detect state changes made by other clients. Regards, Greg. On 6 August 2014 04:00, Jochen Bern wrote: > On -10.01.-28163 20:59, Greg Sullivan wrote: > > I must say I am extremely disappointed that intra-account moves are not > > atomic. As far as I can tell, IMAP was designed to allow shared access, > so > > in my opinion this operation should be atomic. Heaven FORBID that I > should > > ask for entire conversation moves to be atomic as well. (which is really > > what I want) > > How would it be of any use to the passive client that the *operation* is > atomic when (as far as I can see, which admittedly mightn't be much) > there is no way defined in the IMAP protocol to atomically *notify* it > of said change? > > IMAP IDLE, for example, may inform it that one message disappeared from > mailbox X and one popped up in mailbox Y - not that these two are > actually the same message, still have the same set of flags set, etc.. > That's for the client to find out by specific requests - which already > breaks the atomicity and allows for a race condition between clients. > > Regards, > J. Bern > -- > *NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>: > Server--Storage--Virtualisierung--Management SW--Passion for Performance > Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/> > Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt > PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 > Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 > Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel >
[Dovecot] needing UNSELECT to notice new mail?
I am running
NetBSD/i386 3.1ish and 4.0ish
dovecot 1.0.0
procmail delivering into maildirs
gnus from CVS head
emacs 21.4
thunderbird 2
gnome mail-notification 4
configured to required SSL.
Basically everything works fine except that in gnus typing 'g' in the
*Group* buffer, which is supposed to check for new mail and list the
number of new messages, fails to notice new mail.
Notably, gnus does not do an UNSELECT or CLOSE when it is done with a
group.
So basically the following sequence of commands
SELECT "INBOX"
blah blah
EXPUNGE
STATUS "INBOX"
shows no unseen but really there is one
With
(setq nnimap-need-unselect-to-notice-new-mail t)
gnus will do UNSELECT before STATUS, and then things work fine.
Another gnus user reports what seems like the same problem with Courier
IMAP.
So, is dovecot complying with the IMAP spec here? Is there some notion
of a transaction bracketed by SELECT/{UNSELECT,CLOSE}, and is that using
something like READ COMMITTED isolation so that it doesn't see messages
added by other transactions?
Or should dovecot be not relying on cached state and revalidate the
mailbox on STATUS, even if it is already SELECTED?
Further, is it the group's opinion that a well-behaved client would
UNSELECT or CLOSE when the user takes an action that indicates being
finished with a mailbox? Or is it reasonable to leave a mailbox
SELECTed as an optimization. It seems that for Thunderbird, etc., the
user sits in INBOX with IDLE, but with gnus I tend to be in *Group* with
no mailboxes selected.
Re: [Dovecot] needing UNSELECT to notice new mail?
Timo Sirainen <[EMAIL PROTECTED]> writes: >Note: The STATUS command is intended to access the >status of mailboxes other than the currently selected >mailbox. Because the STATUS command can cause the >mailbox to be opened internally, and because this >information is available by other means on the selected >mailbox, the STATUS command SHOULD NOT be used on the >currently selected mailbox. > > Right. What I said. You don't need it. > >The STATUS command MUST NOT be used as a "check for new >messages in the selected mailbox" operation (refer to >sections 7, 7.3.1, and 7.3.2 for more information about >the proper method for new message checking). > > So gnus is breaking a "MUST NOT" from the RFC. Thanks. I've pointed the gnus list at your message and suggested that the unselect-before-checking variable be set to t by default.
Re: [Dovecot] Binary packagers: BSD license issues
Adding this SHA256 code made me read the BSD license once again. It
says:
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
Then there are a few files from Cyrus as well which contain:
* 4. Redistributions of any form whatsoever must retain the following
*acknowledgment:
*"This product includes software developed by Computing Services
* at Carnegie Mellon University (http://www.cmu.edu/computing/)."
And something similar in utc-mktime.c for Berkeley university as well. I
think I'd really like to get rid of those base64.c and utc-mktime.c
exceptions.. There's probably also an easier/faster way to implement
utc_mktime().
Currently these copyrights or acknowledgments aren't listed anywhere
else than in the source files. I don't know if binary packagers have
added those, but somehow I doubt it.
So I think I should add these to COPYING file somehow. Any suggestions?
I'm not the packager of dovecot for pkgsrc (NetBSD and others), but I do
package other things. From my viewpoint, 3-clause BSD license is really
no problem provided you have an installable and preferably installed
file.
4-clause BSD is a bit annoying but not that big a deal. But I don't
think it's compatible with LGPL. If you're still the only copyright
holder, you can of course make an exception that advertising clause is
ok.
What I would suggest is that you add a file doc/COPYRIGHT that has
whatever is necessary to satisfy all these things.
Then, have make install put it in
$(prefix)/share/doc/dovecot/COPYRIGHT
In pkgsrc right now, there are manual install rules:
post-install:
${INSTALL_DATA} ${WRKDIR}/dovecot-example.conf
${DESTDIR}${EGDIR}
${INSTALL_DATA} ${WRKSRC}/doc/dovecot-* ${DESTDIR}${EGDIR}
${INSTALL_SCRIPT} ${WRKDIR}/mkcert.sh ${DESTDIR}${EGDIR}
so adding a INSTALL_DATA for COPYRIGHT won't hurt at all.
I realize the doc dir is not necessarily the same; it would be nice to
have a --with-docdir to set it for the preference of various packaging
systems, but not a big deal.
Greg
Re: [Dovecot] test program #2: mmaping
I'm not sure what you expect to happen, but:
fnord gdt 18 ~ > ./concurrency
0: reading, page size = 4096
writing, page size = 4096
4: reading, page size = 4096
3: reading, page size = 4096
2: reading, page size = 4096
1: reading, page size = 4096
open(): No such file or directory
open(): No such file or directory
open(): No such file or directory
open(): No such file or directory
open(): No such file or directory
fnord gdt 19 ~ > ps uaxw|egrep con
gdt 19239 0.0 0.1 104 548 ttyp1 S 7:55AM 0:00.00 ./concurrency
[other false hits redacted]
fnord gdt 20 ~ > uname -a
NetBSD fnord.ir.bbn.com 4.0_BETA2 NetBSD 4.0_BETA2 (GENERIC) #11: Mon Apr 30
10:46:41 EDT 2007 [EMAIL
PROTECTED]:/n0/obj/gdt-4/i386/sys/arch/i386/compile/GENERIC i386
My system has 2 cpus.
Reading the code, I don't understand why this shouldn't happen - the
bottom branch in the children gets to the open before the top has done
rename, and there's no synchronization to prevent this.
With the following, it prints the 'reading' lines and then sits running:
fnord gdt 68 ~ > ./concurrency
writing, page size = 4096
0: reading, page size = 4096
4: reading, page size = 4096
3: reading, page size = 4096
2: reading, page size = 4096
1: reading, page size = 4096
...^C
--- concurrency.c.~1~ 2007-06-21 07:54:51.0 -0400
+++ concurrency.c 2007-06-21 08:05:33.0 -0400
@@ -43,16 +43,19 @@
perror("rename()");
usleep(rand() % 1000);
- pwrite(fd, buf, pagesize + 16, 0);
+ if (pwrite(fd, buf, pagesize + 16, 0) < 0)
+ perror("pwrite1()");
//usleep(rand() % 1000);
//fdatasync(fd);
- pwrite(fd, ones, 4, pagesize-4);
+ if (pwrite(fd, ones, 4, pagesize-4) < 0)
+ perror("pwrite1()");
if (flock(fd, LOCK_UN) < 0)
perror("flock()");
close(fd);
usleep(rand() % 1000);
}
} else {
+ sleep(1);
while (process_count-- > 1) {
if (fork() == 0)
break;
@@ -61,7 +64,7 @@
for (;; close(fd), usleep(rand() % 1000)) {
fd = open("foo", O_RDWR, 0600);
if (fd == -1) {
- perror("open()");
+ perror("open_lower()");
return 1;
}
@@ -93,6 +96,7 @@
} else if (((char *)mmap_base)[pagesize] != 'h')
printf("broken data\n");
}
+ putchar('.'); fflush(stdout);
}
}
return 0;
[Dovecot] sluggish updating of gnome mail-notification?
Sorry if this is a repeat query. I am running dovecot 1.0.2 under NetBSD/i386 (3.1 and 4.0ish). I use maildirs, and deliver into them with procmail. For clients I use Gnus (CVS head) mostly and thunderbird, and also the gnome mail-notification status applet (4.0). Gnus fixed a bug in the last few months where exiting a group didn't unselect the folder and thus didn't necessarily push read marks back. Mostly everything works perfectly. When new mail arrives, thunderbird shows it as new/unread, gnus will find it with 'g', and mail-notification shows it as well. After reading it in gnus, when I exit the group (which pushes read marks to the IMAP server), thunderbird usually shows the message as read immediately, but often mail-notification waits for a while (up to about a minute) before withdrawing the new-mail notification. I just tried this and thunderbird was also slow in showing the mail read. marking the message read in thunderbird caused mail-notification to show the message as read, but with a 30s lag. mail-notification is supposed to use IDLE if available. Sometimes it withdraws new-mail claims at the right time. I know that I need to turn on debugging and trace all this. So I'm really just asking if anyone else has seen this or similar behavior.
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: 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
pigeonhole sieve "standalone"
hi. i've been thinking (but, for years now!) of a replacement for procmail, and pigeonhold sieve seems like a good candidate. but, i run nmh, not dovecot. as i started install it (on arch linux), i started to worry that it may be foolish of me to try to run it outside of a dovecot system. any wisdom about that would be gratefully received. thanks in advance, and thanks for the software. Greg Minshall
