- dovecot - dovecot.org

Feature Request: login_trusted_networks to take FQDN
by Sean Gallagher 15 Feb '23

15 Feb '23

In a previous post to this list I described a problem I was having validating client certificates on inet_listener lmtp connections. Subject: "Please Help: Dovecot ssl_ca selection based on remote IP address filtering not working." The problem there was that Dovecot does not "inspect" the subject name on the client certificate on LMTP connections. As such Any valid certificate will pass. In this context "valid" means the same as OpenSSL SSL_set_verify( ,SSL_VERIFY_PEER, ). I.e. the certificate chain is well formed and can be traced back to a trusted root. It does not say anything about the peer's identity. I propose here, that the "login_trusted_networks" setting be allowed to take a domain name - possibly with wildcards. Then the name on the client certificate could be checked against login_trusted_networks in much the same way that web browsers work. If you tell your web browser that you want to connect to www.example.com, the browser will check that the server's certificate matches "www.example.com". In the present case, if you tell Dovecot (through the login_trusted_networks setting) to allow connections from "smtp.example.com", then Dovecot could check the name on the client's certificate matches "smtp.example.com". More generally, example.com could issue client certificates with names matching "*.mua.example.com". Then you could tell Dovecot to allow connections from "*.mua.example.com" through the login_trusted_networks setting. These usages could largely replace the IP host and CIDR subnet usages currently allowed in the login_trusted_networks setting but both could exist side by side. Of course, more elaborate schemes could be devised involving database lookups, but the outlined proposal would be relatively easy to implement and cover a good majority of use cases. The alternative is to force the use of application-specific certificate authorities, or just ignore it and hope that no one knows how to spoof network traffic. That's My two cents... Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com

1 0

IMAP folder subscription on Apple/Mac Mail
by Alex 13 Feb '23

13 Feb '23

Hi, We have a user with an iPhone who can't see their maildir mailboxes on dovecot-2.3.20 on fedora37. I've created a "subscriptions" file with all maildir mailboxes with the proper format (converted from mboxes using mb2md), but the user can only see their inbox. It appears this may be a known problem? https://wiki.dovecot.org/Clients Perhaps it's a problem with my "subscriptions" file, despite being able to see all mailboxes using K-9 on my android? Ideas for troubleshooting would be greatly appreciated.

1 1

Re: Pigeonhole Sieve Vacation Reply-To peculiarity with inbound AWS-SES
by Dr. Rolf Jansen 11 Feb '23

11 Feb '23

> Am 08.02.2023 um 20:03 schrieb Michael Peddemors <michael(a)linuxmagic.com>: > > Dovecot vacation message issues.. > Tough for any system to do correctly. > >> The problem here is that inbound mails from third parties utilizing AWS-SES come in with an unpersonalized envelope address and SES takes returns to this as bounce messages and changes the body's From: to „MAILER-DAEMON(a)xx-zzzz-1.amazonses.xn--com-5o0a, which is not even our MAILER-DAEMON but the one of the receiver of our reply. So the receiver gets no chance to know from the headers the identity of whom replied - he may assume it from the context the actual message, though. > > We addressed this by NOT returning vacation messages to systems that don't use 'proper' values in the MAIL FROM.. Eg Mailing Lists, Sender Rewrite schemes, and a slurry of other rules. Who is we? Your organization or the Pigeonhole developers? Actually, the question is, whether this is addressed somewhere in Pigeonhole’s code already? > But the problem is that if you are using the header From, or Reply-To etc, it's too easy to be sending to forged email addresses. > > Vacation bombing attacks for instance.. You got a point here, and of course I want to prevent this. > Now, there are legitimate cases of the MAIL FROM and header from not aligning, so it is best to send to the MAIL FROM addresses.. IF you don't send it to certain MAIL FROM formats, usually by not responding to anything with mailing list identifiers, auto-suppress headers, and a few others, you only end up with clean MAIL FROM to respond to. From the point of the view of our industrial customers, who are operating processes with our chemicals, this consideration is irrelevant. If they inform a production issue by mail to the responsible service technician, they expect an immediate response, since a production stop is unacceptable. OoO notices play a role here, because we would inform alternative addresses and fone numbers for attending the support case. That said, with Pigeonhole, we are almost there. > But if you have an example that is particularly bothering you, and represents your problem, we can walk through that as an example. I send an email from an account of a mail server (Postfix/Dovecot - outbound relay SES) running on an AWS-EC2 instance in São Paulo (Brazil) to another mail address of mine of a mail server (Postfix/Dovecot direct MX) on an AWS-EC2 instance in Frankfurt Germany, and here the Pigeonhole’s vacation reply is activated. In the following I changed my real mail address in Brazil to rolf(a)example.br and the real one in Germany to rolf(a)example.de: The Point of view of the both involved Postfixes of said transactions are: Sender (Brazil): postfix/submission/smtpd[29165]: 97006638E8: client=201-68-62-42.dsl.telesp.net.br[201.68.62.42], sasl_method=CRAM-MD5, sasl_username=rolf(a)example.br postfix/cleanup[29182]: 97006638E8: message-id=<707A1777-8F09-4335-99BA-70C0367C129A(a)example.br> postfix/qmgr[2058]: 97006638E8: from=<rolf(a)example.br>, size=39626, nrcpt=1 (queue active) postfix/smtp[29183]: 97006638E8: to=<rolf(a)example.de>, relay=email-smtp.sa-east-1.amazonaws.com[52.67.192.29]:587, delay=0.37, delays=0.05/0.01/0.13/0.18, dsn=2.0.0, status=sent (250 Ok 010301863b0211fe-9416f5b2-7e18-4c03-a5e5-2204dd7946f8-000000) Receiver (Germany): postfix/smtpd[86956]: connect from d215-2.smtp-out.sa-east-1.amazonses.com[23.249.215.2] postfix/smtpd[86956]: A44AB676E3: client=d215-2.smtp-out.sa-east-1.amazonses.com[23.249.215.2] postfix/cleanup[86957]: A44AB676E3: message-id=<010301863b0211fe-9416f5b2-7e18-4c03-a5e5-2204dd7946f8-000000(a)sa-east-1.amazonses.com> postfix/qmgr[915]: A44AB676E3: from=<010301863b0211fe-9416f5b2-7e18-4c03-a5e5-2204dd7946f8-000000(a)sa-east-1.amazonses.com>, size=40862, nrcpt=1 (queue active) postfix/local[86958]: A44AB676E3: passing <rolf(a)example.de> to transport=lmtp postfix/lmtp[86959]: A44AB676E3: to=<rolf(a)example.de>, relay=mail.example.de[private/dovecot-lmtp], delay=0.94, delays=0.83/0.01/0.04/0.07, dsn=2.0.0, status=sent (250 2.0.0 <rolf(a)example.de> +/goFGgl5mOwUwEAEYr/fg Saved) Sender of the OoO (Germany): postfix/qmgr[915]: 60242676F0: from=<rolf(a)example.de>, size=1177, nrcpt=1 (queue active) postfix/cleanup[86957]: 60242676F0: message-id=<dovecot-sieve-1676027240-343352-0(a)example.de> postfix/pickup[62932]: 60242676F0: uid=xxxx from=<rolf(a)example.de> postfix/smtp[86963]: 60242676F0: to=<010301863b0211fe-9416f5b2-7e18-4c03-a5e5-2204dd7946f8-000000(a)sa-east-1.amazonses.com>, relay=email-smtp.eu-central-1.amazonaws.com[3.74.180.161]:587, delay=0.31, delays=0.01/0.02/0.13/0.15, dsn=2.0.0, status=sent (250 Ok 010701863b022070-bb3e4541-8306-4438-b649-8879ec8ff666-000000) Receiver of the OoO notice (Brazil): postfix/smtpd[29184]: connect from d215-244.smtp-out.sa-east-1.amazonses.com[23.249.215.244] postfix/smtpd[29184]: 5F1346394E: client=d215-244.smtp-out.sa-east-1.amazonses.com[23.249.215.244] postfix/cleanup[29182]: 5F1346394E: message-id=<010301863b022c93-9842f45a-85ec-419f-8199-00e027888394-000000(a)sa-east-1.amazonses.com> postfix/qmgr[2058]: 5F1346394E: from=<>, size=3150, nrcpt=1 (queue active) postfix/local[29185]: 5F1346394E: passing <rolf(a)example.br> to transport=lmtp postfix/lmtp[29186]: 5F1346394E: to=<rolf(a)example.br>, relay=mail.example.br[private/dovecot-lmtp], delay=0.05, delays=0.01/0.01/0.02/0.01, dsn=2.0.0, status=sent (250 2.0.0 <rolf(a)example.br> RRZHGWwl5mMDcgAAjZNhtw Saved) The headers of the received OoO message (I removed the DKIM stuff for clarity) are: Return-Path: <> Delivered-To: rolf(a)example.br Received: from mail.example.br by example.br with LMTP id RRZHGWwl5mMDcgAAjZNhtw (envelope-from <>) for <rolf(a)example.br>; Fri, 10 Feb 2023 08:07:24 -0300 Received: from d215-244.smtp-out.sa-east-1.amazonses.com (d215-244.smtp-out.sa-east-1.amazonses.com [23.249.215.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.example.br (Postfix) with ESMTPS id 5F1346394E for <rolf(a)example.br>; Fri, 10 Feb 2023 08:07:24 -0300 (-03) DKIM-Signature: ... X-Sieve: Pigeonhole Sieve 0.5.20 (149edcf2) Message-ID: <010301863b022c93-9842f45a-85ec-419f-8199-00e027888394-000000(a)sa-east-1.amazonses.com> Date: Fri, 10 Feb 2023 11:07:23 +0000 From: MAILER-DAEMON(a)sa-east-1.amazonses.com To: rolf(a)example.br Subject: Out of Office - automatic notice In-Reply-To: <010301863b0211fe-9416f5b2-7e18-4c03-a5e5-2204dd7946f8-000000(a)sa-east-1.amazonses.com> References: <010301863b0211fe-9416f5b2-7e18-4c03-a5e5-2204dd7946f8-000000(a)sa-east-1.amazonses.com> Auto-Submitted: auto-replied (vacation) Precedence: bulk X-Auto-Response-Suppress: All MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Feedback-ID: 1.sa-east-1.E7DnIghDRHBvwjrx2QL73gyWAj+NYISxiq7bqOVD27E=:AmazonSES X-SES-Outgoing: 2023.02.10-23.249.215.244 Note how there is not a single reference of the real origin of the OoO message, rolf(a)example.de. Instead we see From: MAILER-DAEMON(a)sa-east-1.amazonses.com. The receiver of this message need to guess the real address from the outside context. The actual problem is that Pigeonhole responds to to=<010301863b0211fe-9416f5b2-7e18-4c03-a5e5-2204dd7946f8-000000(a)sa-east-1.amazonses.com> instead of to=<rolf(a)example.de>. Amazon SES of the original sender (not our relay) takes this as a bounce and changes the relevant headers. This is not under our control. Perhaps this could be mitigated by adding a Reply-To: header which informs the original sender. Then the receiver of the OoO noice would at least have a reference to what and whom this is about. Best regards Rolf > On 2023-02-08 13:21, Dr. Rolf Jansen wrote: >> Am 08.02.2023 um 12:57 schrieb Michael Peddemors <michael(a)linuxmagic.com>: >>> On 2023-02-08 07:47, Dr. Rolf Jansen wrote: >>>> Am 08.02.2023 um 12:23 schrieb Michael Peddemors <michael(a)linuxmagic.com>: >>>>> On 2023-02-07 14:57, Dr. Rolf Jansen wrote: >>>>>> Am 07.02.2023 um 19:49 schrieb Michael Peddemors <michael(a)linuxmagic.com>: >>>>>>> On 2023-02-07 13:33, jeremy ardley wrote: >>>>>>>> On 8/2/23 05:08, Dr. Rolf Jansen wrote: >>>>>>>>> Am 07.02.2023 um 17:54 schrieb jeremy ardley<jeremy(a)ardley.org>: >>>>>>>>>> On 7/2/23 22:01, Dr. Rolf Jansen wrote: >>>>>>>>>> To begin with, usage of Amazons Simple Email Service (SES) is mandatory for outgoing mails from AWS-EC2 instances. >>>>>>>>>> I run AWS-EC2 instances using postfix to send a receive mail. They can send direct assuming I set up suitable SPF, but they typically forward mail to another host under my control that is not on AWS to use as the outgoing server. >>>>>>>>> OK, that’s another use case. Many do use a full fledged Postfix/Dovecot installation. However the outgoing port 25 into the internet is blocked by AWS, and therefore we may either use a third party relay for our outgoing emails or may use SES, which is not that bad - except some unusual peculiarities. >>>>>>>>> >>>>>>>> This is off topic, but to be precise: >>>>>>>> - AWS throttles but does not block traffic to a *destination* port 25. >>>>>>>> - The *origin* port on the EC2 instance is an unprivilged port, not port 25 >>>>>>>> - If you use a relayhost you typically send from an unprivilged EC2 port to port 587 on the relay host >>>>>>>> Jeremy >>>>>>> >>>>>>> And if you DO intend to send out to port 25, remember to update the PTR on your EC2 instance. >>>>>> I respond off-list. Generally a good hint but it’s like trying to bath salts (https://en.wikipedia.org/wiki/Bath_salts) when you are taking a shower. >>>>>> https://aws.amazon.com/premiumsupport/knowledge-center/ec2-port-25-throttle/ >>>>>> Although the link text (ec2-port-25-throttle) suggests throttling, it is actually blocking - read the text. This cannot be removed from standard EC2 instances. >>>>>> This also corresponds to my experience. On the console of an AWS-EC2 instance, I entered just now: >>>>>> telnet cyclaero.com 25 >>>>>> This hangs until timeout. At the same time cyclaero.com received emails from the internet on port 25. >>>>>> Trying 3.126.110.101... >>>>>> telnet: connect to address 3.126.110.101: Operation timed out >>>>>> telnet: Unable to connect to remote host >>>>> >>>>> There are a lot of malicous or compromised EC2 instances..It is good they block port by default, and the one day delay before unblocking (you can request it) helps stop those short term spam instances. >>>>> >>>>> Now, wish they blocked port 587 by default ;) >>>>> >>>>> Or at least tracked the attacks. >>>>> >>>>> Strange though, that people still try to set up email on EC2, doesn't make sense, and it isn't the cheapest alternative.

5 8

Please Help: Dovecot ssl_ca selection based on remote IP address filtering not working.
by Sean Gallagher 11 Feb '23

11 Feb '23

Hi All, I hope this is the correct place to post this. If not, apologies. I am in the process of updating my company's email servers and am trying to put Dovecot into an Alpine Linux container, hosted on ProxMox. In my setup, local mail deliveries via LMTP can come from the MSA (for intra-company mail) and an MTA (for inbound mail). The LMTP data is sent over IPv4 and is protected by TLS. Client certificates are used to authenticate sources. I wanted to prevent Dovecot from accepting LMTP from any other source and the method I came up with to do this was to use filtering on the "remote" address. I would create a "Fake" CA that had never signed a certificate and use that to evaluate the certificate presented by incoming connections from addresses other than the two legitimate sources. This would cause all connections from "bad" addresses to be rejected. This seemed simple enough on paper but Dovecot just isn't playing along. It seems that no matter what I do, I cannot get "remote" filtering to switch the "ssl_ca" parameter. I have put together a test bed to demonstrate. I then use openssl s_client to attempt to connect to the test bed container. I've attached the instructions to build the test bed from scratch. In all cases s_client reports "Acceptable client certificate CA names" "CN = Fake CA" I.e. it want's a certificate from the CA that has never signed a certificate and never will. Why not do the obvious thing? I use LDAP to authenticate individual users and the user name will be reported over LMTP. So to use the normal authentication mechanisms to authenticate the connection source, I would need to do two LDAP lookups, one for the connecting machine and one for the mail recipient. It is not clear if this is possible from the documentation.. *Questions:* Is config file filtering broken or am I doing it wrong? Is it possible to provide a different "ssl_ca" based on the remote IP address? Is there an easier way to restrict LMTP connections to specific remote IP addresses? p.s. Filtering just doesn't work like it's supposed to. Someone should look at that (especially multi-level) .. See this: https://dovecot.org/pipermail/dovecot/2016-June/104770.html Any help would be greatly appreciated. I am at my wits' end with this. -- This email has been checked for viruses by AVG antivirus software. www.avg.com

1 1

Why does creating a mailbox create it in all namespaces?
by e 10 Feb '23

10 Feb '23

When I create a mailbox using CREATE, it creates it in all namespaces? Is that supposed to happen? Look: ``` a namespace * NAMESPACE (("" "/")("Other/" "/")) NIL NIL a OK Namespace completed (0.001 + 0.000 secs). a list "" * * LIST (\HasNoChildren) "/" Other * LIST (\HasNoChildren) "/" INBOX a OK List completed (0.001 + 0.000 secs). a create Other/Drafts a OK Create completed (0.003 + 0.000 + 0.002 secs). a list "" * * LIST (\HasNoChildren) "/" Drafts * LIST (\HasChildren) "/" Other * LIST (\HasNoChildren) "/" Other/Drafts * LIST (\HasNoChildren) "/" INBOX a OK List completed (0.001 + 0.000 secs). ``` This is my namespace configuration ``` namespace { prefix = inbox = yes separator = / } namespace { prefix = Other/ separator = / } ``` And dovecot version is 2.3.7.2

2 1

doveadm: Error: Mailbox INBOX: Deleting corrupted cache: Cache file too large
by Ralf Hildebrandt 09 Feb '23

09 Feb '23

Hi! Upon issuing a % doveadm import -u restore(a)backup.invalid mdbox:/home/storage/mdbox I'm getting a: doveadm(restore(a)backup.invalid): Error: Mailbox INBOX: Deleting corrupted cache: Cache file too largea doveadm(restore(a)backup.invalid): Error: Corrupted dbox file /home/restore/mdbox/storage/m.7 (around offset=41602004): msg header has bad magic value doveadm(restore(a)backup.invalid): Error: Corrupted dbox file /home/restore/mdbox/storage/m.8 (around offset=17193748): msg header has bad magic value message -- but the process keeps running! Should I worry? dovecot packages: 2.3.20-3+ubuntu20.04 -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt(a)charite.de | https://www.charite.de

1 0

Pigeonhole Sieve Vacation Reply-To peculiarity with inbound AWS-SES
by Dr. Rolf Jansen 08 Feb '23

08 Feb '23

To begin with, usage of Amazons Simple Email Service (SES) is mandatory for outgoing mails from AWS-EC2 instances. The Pro is, it does work and we may utilize email relays with high reputation for our outgoing mails at no additional costs. The Con's are that (A) SES does not relay mails with empty <> MAIL FROM addresses and (B) it fiddles with the envelope addresses of the relayed mails. Anyway this is out of our control, and while I could avoid (A) by switching the e-mail service provider, I still have no control over (B) because this affects replying to emails from others using AWS-SES. Problem A) The empty-MAIL-FROM may be effectively addressed by setting Pigeonhole’s sieve_vacation_send_from_recipient to ‚yes‘. Problem B) Pigeonhole Vacation utilizes the senders envelope address of the inbound message as the reply-address. The problem here is that inbound mails from third parties utilizing AWS-SES come in with an unpersonalized envelope address and SES takes returns to this as bounce messages and changes the body's From: to „MAILER-DAEMON(a)xx-zzzz-1.amazonses.xn--com-5o0a, which is not even our MAILER-DAEMON but the one of the receiver of our reply. So the receiver gets no chance to know from the headers the identity of whom replied - he may assume it from the context the actual message, though. I found the setting sieve_vacation_to_header_ignore_envelope, which was introduced in 2017 (https://dovecot.org/list/dovecot-cvs/2017-August/028917.html) My finding is, that this resolves the problem only half way. For a local workaround, I changed Line 1119 of cmd-vacation.c https://github.com/dovecot/pigeonhole/blob/34431d7a67474c00d5b0554f5d45b867… to: struct smtp_address real_to; if (smtp_address_init_from_msg(&real_to, &reply_to) >= 0) sctx = sieve_smtp_start_single(senv, &real_to, smtp_from, &output); else sctx = sieve_smtp_start_single(senv, smtp_to, smtp_from, &output); That in place and setting sieve_vacation_to_header_ignore_envelope to ‚yes‘, effectively resolves problem B as well. Best regards Rolf Jansen

6 10

Ubuntu packages for 22.04 LTS?
by Ralf Hildebrandt 06 Feb '23

06 Feb '23

Hi! I recently updated from 20.04 -> 22.04 and wondered if packages specifically for 22.04 were available. https://doc.dovecot.org/installation_guide/dovecot_community_repositories/u… doesn't seem list any... Neiter does https://repo.dovecot.org -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt(a)charite.de | https://www.charite.de

2 2

problem converting mailbox to maildir with doveadm
by Kenneth Irving 05 Feb '23

05 Feb '23

Hello. I have an email server for testing purposes, using postfix 3.5.17 and dovecot 2.3.13. Initially, I configured postfix to use mailboxes, but now I've changed it to maildir. Emails arrive fine, and dovecot manages them well by pop3 or imap. No problems there. But I still have a lot of emails in different mailboxes which I'd like to convert to maildir. I found mb2md, which seems to do a pretty good job. Once the mailbox is converted, dovecot manages the emails without a problem. But I also wanted to learn how to use doveadm to convert mailboxes to maildir format. I read all the documentation I could find and tried to learn how this command works. I tried different combinations, but couldn't convert mailboxes to maildir. I always get error messages. I've been unable to understand why. I tried to sync, backup, and import, to no avail. I also tried dsync, which seems to have a different syntax, with the same result. Sorry for bothering you, but if you could explain to me how this command works, I'd be very grateful. Example: I have a user, let's say joe, who has a mailbox in /var/mail/joe and I'd like to transfer those emails to /home/joe/Maildir How do I use doveadm in this situation? Best regards Kenneth

3 4

IMAP tuning for Outlook 365
by Artur Pydo 02 Feb '23

02 Feb '23

Hello, I'm looking for advices on IMAP config tuning for best user experience with Outlook 365. I'm currently using dovecot 2.3.4.1 (f79e8e7e4) provided with Debian 10. One of my users has Outlook 365 and an IMAP mailbox of large size with several folders (more than 3GB). From time to time as his main inbox folder is growing he can see some problems with its Outlook application. Sometimes it freezes during mailbox synchronisation, sometimes he can't see new incoming emails. I wonder if there is some specific workarounds for an up-to-date Outlook in Dovecot or if you can suggests some config setup adjustments (timeouts, idleing ...) to avoid problems in his Outlook. Most of the config are defaults. But I can provide relevant parts of the config if needed. I have this workaround activated for a long time: imap_client_workarounds = delay-newmail By the way, I also have a big IMAP mailbox. Can't see any server specific problem while connecting with Thunderbird to this Dovecot server. -- Best regards, Artur

4 3