- dovecot - dovecot.org

dovecot + Procmail -> junk emails
by Stephane Magnier 03 Aug '21

03 Aug '21

Hi, Having moved from 'mbox' to 'Maildir', I'm trying to use a way to move a spam email to the Junk folder I declared the junk folder as; namespace inbox { type = private disabled = no ignore_on_failure = no list = yes subscriptions = yes #hidden = no #inbox = yes #prefix = INBOX/ mailbox "Drafts" { auto = subscribe special_use = \Drafts } mailbox "Junk" { auto = subscribe autoexpunge = 12 weeks special_use = \Junk } mailbox "Trash" { auto = no autoexpunge = 12 weeks special_use = \Trash } mailbox "Sent" { auto = subscribe special_use = \Sent } and spamassassin, very basic loadplugin Mail::SpamAssassin::Conf required_hits 5 required_score 5 rewrite_header subject [** SPAM ** ] add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_ spf_timeout 60 rewrite_header to [Email could be SPAM ] fold_headers 0 #defang_mime 0 report_safe 0 and Procmail.. basic and I used what I found on the webpage : https://wiki.dovecot.org/procmail <https://wiki.dovecot.org/procmail> DELIVER="/usr/lib/dovecot/deliver -d $LOGNAME" SHELL="/bin/bash" SENDMAIL="/usr/sbin/sendmail -oi -t" LOGFILE="/var/log/procmail.log" DEFAULT="/var/spool2/mail/%u :0fw | /bin/spamc -s any ####################################### #:0 #* ^X-Spam-Status: Yes #$DEFAULT ####################################### :0 w * ^X-Spam-Status: Yes | $DELIVER -m Junk # ## deliver to INBOX and stop # deliver to INBOX and stop :0 w | $DELIVER But with this config, a spam email, stay into the Inbox :-( /var/log/procmail.log... doesn't exist Thanks for you help

3 3

Multiple Quota Limit Configurations
by Joseph D Wagner 02 Aug '21

02 Aug '21

Is this a valid quota rule? *:storage=0,messages=0 Or do I need to make them two separate rules? Joseph D Wagner

1 0

Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?
by Mart Pirita 02 Aug '21

02 Aug '21

Hello. So far I have successfully built Dovecot until v2.3.14 on Centos 4-6 (yes I know, they are old, but as they are remote servers, distros can't upgraded), and sometimes I have also met compilation issues, but after highlighting them, Timo have fixed the code. Found from similar thread (Dovecot 2.3.15 compilation fails https://dovecot.org/list/dovecot/2021-June/122412.html ) that new GCC is needed. However I can't find such requirement in v2.3.15 change log. As seems that I'm not the only one with compilation issues, then @Timo - can You please fix the code so that also v2.3.15 can compiled on older distros? Compilation options: ./configure --prefix=/usr --with-ssl=openssl --with-ssldir=/etc/ssl --sysconfdir=/etc --with-pam --without-bsdauth --without-sql --without-nss --without-ldap --without-pgsql --without-mysql --without-sqlite --with-rundir=/var/run/dovecot --without-cassandra --without-lucene --without-solr --without-textcat --without-libcap --without-stemmer --disable-rpath --disable-dependency-tracking --disable-silent-rules --without-gssapi --without-cdb Compilation error: builtin-strftime -c -o test-smtp-params.o test-smtp-params.c test-smtp-params.c:29: error: unknown field `data' specified in initializer test-smtp-params.c:29: warning: missing braces around initializer test-smtp-params.c:29: warning: (near initialization for `test_params_buffer1.<anonymous>') test-smtp-params.c:30: warning: missing initializer test-smtp-params.c:30: warning: (near initialization for `test_params_buffer1.<anonymous>.<anonymous>.used') test-smtp-params.c:30: error: unknown field `used' specified in initializer test-smtp-params.c:31: warning: excess elements in struct initializer test-smtp-params.c:31: warning: (near initialization for `test_params_buffer1') test-smtp-params.c:33: error: unknown field `data' specified in initializer test-smtp-params.c:33: warning: missing braces around initializer test-smtp-params.c:33: warning: (near initialization for `test_params_buffer2.<anonymous>') test-smtp-params.c:34: warning: missing initializer test-smtp-params.c:34: warning: (near initialization for `test_params_buffer2.<anonymous>.<anonymous>.used') test-smtp-params.c:34: error: unknown field `used' specified in initializer test-smtp-params.c:35: warning: excess elements in struct initializer test-smtp-params.c:35: warning: (near initialization for `test_params_buffer2') make[3]: *** [test-smtp-params.o] Error 1 make[3]: Leaving directory `/usr/src/redhat/BUILD/dovecot-2.3.15/src/lib-smtp' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/dovecot-2.3.15/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/dovecot-2.3.15' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.7364 (%build) -- Mart

9 12

SQL Backend for IMAP METADATA Dictionary
by Joseph D Wagner 01 Aug '21

01 Aug '21

I've seen documentation on using a SQL backend for quota dictionary and passdb&userdb dictionary. However, I can't find any examples of a SQL backend for IMAP METADATA / mail_attributes_dict. Is this combination possible? If so, is there an example somewhere? I am unsure what data structures it's expected or how to create the map entries for it. Thanks in advance. Joseph D. Wagner

2 4

Disable authentication for submission service
by Dan Conway 01 Aug '21

01 Aug '21

Hello, Is it possible to disable the requirement for authentication on the submission service? I'm trying to require authentication for all, except for a handful of IP addresses. Thank you. ehlo test.com 250-aaa 250-AUTH PLAIN LOGIN 250-BURL imap 250-CHUNKING 250-DSN 250-ENHANCEDSTATUSCODES 250-SIZE 250 PIPELINING MAIL FROM:<test(a)test.com> 530 5.7.0 Authentication required.

8 11

Re: check_policy_service sends size=0
by dovecot＠ptld.com 01 Aug '21

01 Aug '21

> It sounds like a better approach would be to make Dovecot reject any > email no matter what the size is (even size=0) if a user is over > quota. I'll take further discussion to the dovecot mailing list then. If you are not aware, dovecot has by default a 10% over quota grace. So even being a couple of bytes over quota it would still accept a small message.

3 3

Re: Monitoring of director back end nodes
by Tom Sommer 31 Jul '21

31 Jul '21

On 2021-07-31 19:28, darkc0de wrote: > So dovemon for Dovecot pro, but nothing for community? https://github.com/brandond/poolmon --- Tom

1 0

Monitoring of director back end nodes
by Dan Conway 31 Jul '21

31 Jul '21

Hello, When working with director, the state of the backend nodes are not checked by Dovecot. The state always remains as "up". I understand that there are external applications documented that monitor backend nodes, and changes the state of them to "down" if they become unresponsive. The question I have is are there plans to implement something built into Dovecot that would monitor and change states based on backend "health"? Or will it always be dependent on an external service? Thanks.

3 2

quota-status fails when size=0 from Postfix
by Christoph Haas 30 Jul '21

30 Jul '21

Dear list, I've been pulling my hair out today and kindly ask you for help. I'm on Debian Bullseye with Dovecot 2.3.13 and Postfix 3.5.6. Users are stored in SQL and I want to use quotas. Basically I followed https://doc.dovecot.org/configuration_manual/quota_plugin/#quota-service With mail_debug enabled I see that the information from SQL is fetched correctly: dovecot: quota-status(test(a)bullseye.example.org)<45148><>: Debug: auth-master: userdb lookup(test(a)bullseye.example.org): auth USER input: test(a)bullseye.example.org quota_rule=*:bytes=1000 home=/var/vmail/bullseye.example.org/test uid=5000 gid=5000 So the quota rule "*:bytes=1000" is loaded as intended for testing. Before handing the email over to Dovecot through LMTP Postfix should call the quota-service (policy daemon) to determine if the user is over quota: smtpd_recipient_restrictions = \ reject_unauth_destination \ check_policy_service inet:localhost:12340 This is still by the book. What I found: - sending a test mail with Thunderbird properly returns a 5xx status (over quota) - sending a test mail with SWAKS returns DUNNO (swaks is an SMTP test tool) I have used tcpdump to look into the communication on port 12340 and the difference appears to be the "size=0" line that Postfix sends if I use SWAKS. Output from SWAKS: -> RCPT TO:<test(a)bullseye.example.org> <- 250 2.1.5 Ok However if Thunderbird sends an email it uses something like -> RCPT TO:<test(a)bullseye.example.org> SIZE=12345 If I understand the situation correctly then Postfix extracts the SIZE=… value and uses that to send it to the quota-status policy daemon. The user however is definitely over quota: $> doveadm quota get -u test(a)bullseye.example.org Quota name Type Value Limit % User quota STORAGE 1 1 100 User quota MESSAGE 1 - 0 So whatever the size of the incoming email is, it should be rejected. As quota-status returns DUNNO, Postfix will send the email to Dovecot through LMTP. And LMTP in turn does another quota check and correctly rejects the email: postfix/lmtp[45153]: 573419D6A3: to=<test(a)bullseye.example.org>, relay=iredmail-test[private/dovecot-lmtp], delay=0.08, delays=0.05/0.01/0.01/0.01, dsn=5.2.2, status=bounced (host iredmail-test[private/dovecot-lmtp] said: 552 5.2.2 <test(a)bullseye.example.org> Quota exceeded (mailbox for user is full) (in reply to end of DATA command)) Problem here is that a bounce is created and Postfix is sending backscatter. Had "quota-service" indicated that the mailbox is over quota then Postfix had instantly rejected the email without any bounce. I can also reproduce this effect by talking to the quota-status daemon: printf "recipient=test(a)bullseye.example.org\nsize=0\n\n" | nc localhost 12340 action=DUNNO printf "recipient=test(a)bullseye.example.org\nsize=10000\n\n" | nc localhost 12340 action=554 5.2.2 Quota exceeded (mailbox for user is full) Is this a feature? A bug? An evil coincidence? Thanks for reading this far. I know that this matter seems a bit complicated. But it feels like Dovecot's behavior leads to backscatter and of course I'd like to avoid that. Kindly… Christoph

4 14

[bug 2.3.15] seeing user-shared mailboxes across different storage types requires manual change to subscriptions
by Michal Soltys 29 Jul '21

29 Jul '21

Hi, While I was checking old bug I once reported (that one seems to be fixed, https://www.dovecot.org/list/dovecot/2017-January/106593.html) I discovered another issue happening under current version when user sharing his mailbox (with Maildir storage) is not visible under user using mdbox (or sdbox, also tested) - unless subscriptions file is manually adjusted (after subscribing). Consider following config: # 2.3.15 (0503334ab1): /etc/dovecot/dovecot.conf # OS: Linux 5.12.14-arch1-1 x86_64 Arch Linux btrfs # Hostname: hakai auth_debug = yes auth_mechanisms = plain login disable_plaintext_auth = no first_valid_uid = 1 listen = * mail_debug = yes mail_gid = dovecot mail_location = maildir:/var/mail1/%n/Maildir mail_plugins = acl mail_uid = dovecot namespace { inbox = yes location = prefix = separator = / type = private } namespace shared1 { inbox = no list = yes location = maildir:%%h/Maildir/ prefix = shared1/%%n/ separator = / subscriptions = no type = shared } namespace shared2 { inbox = no list = yes location = mdbox:%%h/mdbox/ prefix = shared2/%%n/ separator = / subscriptions = no type = shared } passdb { args = /etc/dovecot/local-maildir driver = passwd-file } passdb { args = /etc/dovecot/local-mdbox driver = passwd-file } plugin { acl = vfile acl_shared_dict = file:/var/mail-data/shared-database/shared-mailboxes.db } protocols = imap service auth { unix_listener auth-userdb { group = mail mode = 0660 user = dovecot } user = dovecot } service imap-login { inet_listener imap { address = * port = 143 } inet_listener imaps { address = * port = 993 } user = dovecot } service imap { executable = /usr/lib/dovecot/imap } userdb { driver = prefetch } userdb { args = /etc/dovecot/local-maildir driver = passwd-file } userdb { args = /etc/dovecot/local-mdbox driver = passwd-file } protocol imap { mail_max_userip_connections = 100 mail_plugins = acl imap_acl } /etc/dovecot/local-maildir: user1:{PLAIN}test:::user1:/var/mail1/user1::userdb_mail=maildir:/var/mail1/user1/Maildir userdb_home=/var/mail1/user1 user2:{PLAIN}test:::user2:/var/mail1/user2::userdb_mail=maildir:/var/mail1/user2/Maildir userdb_home=/var/mail1/user2 /etc/dovecot/local-mdbox: user3:{PLAIN}test:::user3:/var/mail2/user3::userdb_mail=mdbox:/var/mail2/user3/mdbox userdb_home=/var/mail2/user3 There are two shared namespaces - shared1 for Maildir mailboxes and shared2 for mdbox ones. 'user1' is sharing his 'qwer' folder to user3. doveadm mailbox create -u user1 -s qwer doveadm acl add -u user1 qwer user=user3 read lookup doveadm mailbox subscribe -u user3 shared1/user1/qwer This produces subscriptions file such as: 14:44 # cat /var/mail2/user3/mdbox/subscriptions V 2 Trash shared1 user1 qwer With all that in place, 'qwer' won't be visible to user3. But if we change the 'shared1 user1 qwer' to shared1/user1/qwer - then everything will be working fine. Sharing mdbox folder to maildir user (user3 -> user1) as well as maildir to maildir (user1 -> user2) works without issues.

1 1