Problems with dovecot lmtp
Greetings, First I'd like to say thank you to all of the developers and contributors to Postfix. I've used it for many years with great success and happiness. :) I'm on Ubuntu Server 16.04 (up to date) and using the stock postfix package (3.10-3). I have a working installation with postfix and dovecot, and I want to add sieve to it, so I am trying to configure postfix to use lmtp for its delivery service. However it is ignoring that request, and for every message I get "status=sent (delivered to maildir)" and it shows up in my Inbox. On my mail host I have 1 normal user. I have postfix configured to accept mail for several different domains, and each domain has a lot of different mail usernames (I use this for mailing lists and such). I use the virtual_maps feature of postfix, and have a map file that looks like this: ab...@dougbarton.us normaluser hostmas...@dougbarton.us normaluser do...@dougbarton.us normaluser ... All of this works great, and mail for all the different usernames and domains gets delivered into my one real user's Maildir, and I can see the mail with my IMAP clients. I've configured sieve in dovecot, and I can see the socket for lmtp in /var/spool/postfix/private/. So according to all the tutorials I've read my assumption is that my next step is this in postfix' main.cf: virtual_transport = lmtp:unix:private/dovecot-lmtp which I did, and postfix restarts with no errors. But, it seems to avoid lmtp altogether, and it delivers straight to my Maildir Inbox every time. I have since learned that I probably don't want virtual_transport for this, but I probably do want local_transport. The problem is that if I put in local_transport = lmtp:unix:private/dovecot-lmtp I get a bounce every time: Mar 15 18:01:20 dougbarton postfix/lmtp[11793]: 8BCD38F: to=, relay=dougbarton.us[private/dovecot-lmtp], delay=0.03, delays=0.01/0/0/0.01, dsn=5.1.1, status=bounced (host dougbarton.us[private/dovecot-lmtp] said: 550 5.1.1 User doesn't exist: do...@dougbarton.us (in reply to RCPT TO command)) >From further reading it seems that I need to add some sort of additional >mapping, but it's not clear to me what. Adding my virtual_maps file to >local_recipient_maps didn't work. I also tried 'local_recipient_maps = ' to >see if I could rule out a chroot issue, but that didn't work either. I tried adding logging to the lmtp process, and the only thing I get in the log is this: Mar 15 17:57:57 lmtp(11397): Info: Connect from local Mar 15 17:57:57 lmtp(11397): Info: Disconnect from local: Successful quit That happens twice per delivery attempt. I've been working on this for two days, and I'm probably missing something really obvious, but I would appreciate your assistance. Testing has been difficult because the messages bounce hard and I get a lot of mail every day. Here is postconf -n with security-related and boring items removed. alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases compatibility_level = 2 home_mailbox = Maildir/ local_recipient_maps = proxy:unix:passwd.byname $alias_maps milter_default_action = accept mydestination = $mydomain, localhost.$mydomain, localhost mydomain = dougbarton.us myhostname = dougbarton.us smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated reject_non_fqdn_helo_hostname reject_invalid_helo_hostname permit smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_pipelining reject_unauth_destination reject_unverified_recipient reject_rbl_client zen.spamhaus.org check_policy_service inet:127.0.0.1:10023 check_policy_service unix:private/spf-policy smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated reject_non_fqdn_sender reject_unknown_sender_domain permit unverified_recipient_reject_code = 550 virtual_maps = hash:/etc/postfix/virtual_addresses virtual_transport = lmtp:unix:private/dovecot-lmtp I'm sorry that this message is so long, but apparently my situation is somewhat unusual (I wasn't able to find any similar configurations after a lot of searching) and I wasn't sure what to include. Any help will be greatly appreciated. Doug
Problems with lmtp
[ Trying this again as I think I sent to the wrong address the first time ] Greetings, First I'd like to say thank you to all of the developers and contributors to Postfix. I've used it for many years with great success and happiness. :) I'm on Ubuntu Server 16.04 (up to date) and using the stock postfix package (3.10-3). I have a working installation with postfix and dovecot, and I want to add sieve to it, so I am trying to configure postfix to use lmtp for its delivery service. However it is ignoring that request, and for every message I get "status=sent (delivered to maildir)" and it shows up in my Inbox. On my mail host I have 1 normal user. I have postfix configured to accept mail for several different domains, and each domain has a lot of different mail usernames (I use this for mailing lists and such). I use the virtual_maps feature of postfix, and have a map file that looks like this: ab...@dougbarton.us normaluser hostmas...@dougbarton.us normaluser do...@dougbarton.us normaluser ... All of this works great, and mail for all the different usernames and domains gets delivered into my one real user's Maildir, and I can see the mail with my IMAP clients. I've configured sieve in dovecot, and I can see the socket for lmtp in /var/spool/postfix/private/. So according to all the tutorials I've read my assumption is that my next step is this in postfix' main.cf: virtual_transport = lmtp:unix:private/dovecot-lmtp which I did, and postfix restarts with no errors. But, it seems to avoid lmtp altogether, and it delivers straight to my Maildir Inbox every time. I have since learned that I probably don't want virtual_transport for this, but I probably do want local_transport. The problem is that if I put in local_transport = lmtp:unix:private/dovecot-lmtp I get a bounce every time: Mar 15 18:01:20 dougbarton postfix/lmtp[11793]: 8BCD38F: to=, relay=dougbarton.us[private/dovecot-lmtp], delay=0.03, delays=0.01/0/0/0.01, dsn=5.1.1, status=bounced (host dougbarton.us[private/dovecot-lmtp] said: 550 5.1.1 User doesn't exist: do...@dougbarton.us (in reply to RCPT TO command)) >From further reading it seems that I need to add some sort of additional >mapping, but it's not clear to me what. Adding my virtual_maps file to >local_recipient_maps didn't work. I also tried 'local_recipient_maps = ' to >see if I could rule out a chroot issue, but that didn't work either. I tried adding logging to the lmtp process, and the only thing I get in the log is this: Mar 15 17:57:57 lmtp(11397): Info: Connect from local Mar 15 17:57:57 lmtp(11397): Info: Disconnect from local: Successful quit That happens twice per delivery attempt. I've been working on this for two days, and I'm probably missing something really obvious, but I would appreciate your assistance. Testing has been difficult because the messages bounce hard and I get a lot of mail every day. Here is postconf -n with security-related and boring items removed. alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases compatibility_level = 2 home_mailbox = Maildir/ local_recipient_maps = proxy:unix:passwd.byname $alias_maps milter_default_action = accept mydestination = $mydomain, localhost.$mydomain, localhost mydomain = dougbarton.us myhostname = dougbarton.us smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated reject_non_fqdn_helo_hostname reject_invalid_helo_hostname permit smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_pipelining reject_unauth_destination reject_unverified_recipient reject_rbl_client zen.spamhaus.org check_policy_service inet:127.0.0.1:10023 check_policy_service unix:private/spf-policy smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated reject_non_fqdn_sender reject_unknown_sender_domain permit unverified_recipient_reject_code = 550 virtual_maps = hash:/etc/postfix/virtual_addresses virtual_transport = lmtp:unix:private/dovecot-lmtp I'm sorry that this message is so long, but apparently my situation is somewhat unusual (I wasn't able to find any similar configurations after a lot of searching) and I wasn't sure what to include. Any help will be greatly appreciated. Doug
cloud9 rejecting my mail
When trying to sign up for the list from my regular e-mail address (served by my Postfix mail server, on a vhost at Arp Networks) I got the following: : host mail.cloud9.net[2604:8d00:0:1::4] said: 554 5.7.1 : Helo command rejected: Access denied (in reply to RCPT TO command) That's very odd, as for several years I've never had mail rejected before. I have rDNS for my IPv4 and IPv6 addresses, SPF, DKIM, DMARC, etc. (All working) I can send to big providers like Google and Yahoo! with no issues as well. Can anyone point me in the right direction as to why cloud9.net is shutting me down? If there is a problem I'm happy to fix it. :) Doug
Re: Problems with lmtp
On Thu, Mar 16, 2017 at 02:06:37AM +, Doug wrote: > [ Trying this again as I think I sent to the wrong address the first time ] FWIW, it got through both times. On Thu, Mar 16, 2017 at 02:01:07AM +, Doug wrote: > I'm on Ubuntu Server 16.04 (up to date) and using the stock postfix package > (3.10-3). There is no Postfix 3.10, did you mean 3.1.0-3? Instead of reporting a vendor version string, it is better to report the output of: $ postconf -d mail_version > So according to all the tutorials I've read my assumption is that my next > step is this in postfix' main.cf: > > virtual_transport = lmtp:unix:private/dovecot-lmtp > > which I did, and postfix restarts with no errors. But, it seems to avoid > lmtp altogether, and it delivers straight to my Maildir Inbox every time. > > I have since learned that I probably don't want virtual_transport for > this, but I probably do want local_transport. The problem is that if I > put in local_transport = lmtp:unix:private/dovecot-lmtp I get a bounce > every time: > > Mar 15 18:01:20 dougbarton postfix/lmtp[11793]: 8BCD38F: > to=, relay=dougbarton.us[private/dovecot-lmtp], > delay=0.03, delays=0.01/0/0/0.01, dsn=5.1.1, status=bounced (host > dougbarton.us[private/dovecot-lmtp] said: 550 5.1.1 > User doesn't exist: do...@dougbarton.us (in reply to RCPT TO command)) > > From further reading it seems that I need to add some sort of additional > mapping, but it's not clear to me what. Adding my virtual_maps file to > local_recipient_maps didn't work. I also tried 'local_recipient_maps = ' > to see if I could rule out a chroot issue, but that didn't work either. > > I've been working on this for two days, and I'm probably missing something > really obvious, but I would appreciate your assistance. Testing has been > difficult because the messages bounce hard and I get a lot of mail every > day. > > Here is postconf -n with security-related and boring items removed. > > alias_maps = hash:/etc/aliases > home_mailbox = Maildir/ > local_recipient_maps = proxy:unix:passwd.byname $alias_maps > milter_default_action = accept > mydestination = $mydomain, localhost.$mydomain, localhost > mydomain = dougbarton.us > virtual_maps = hash:/etc/postfix/virtual_addresses > virtual_transport = lmtp:unix:private/dovecot-lmtp > > I'm sorry that this message is so long, but apparently my situation is > somewhat unusual (I wasn't able to find any similar configurations after > a lot of searching) and I wasn't sure what to include. > > Any help will be greatly appreciated. I'll make you a deal, fix the TLSA records for your domains to comply with both RFC7672 and what Postfix supports (as of Postfix 3.2, per RFC7672 PKIX-EE(1) records are treated as "unusable"), and I'll help you with your LMTP transport problem! Instead of: _25._tcp.dougbarton.us. IN TLSA 1 0 2 af2e8ccb230fdac708245e9b63d43ed5f4704bb4d0d23d6be12bfce85bf503cfe114f4ada2196df67e37f2b0769f9647ec9030ef407fc16dea25c8a1aadda82c Publish a sensible subset of: _25._tcp.dougbarton.us. IN TLSA 3 1 1 a61dba3a98fdac5103a4995d9b2c2a06d5893de79ed222707345c00ab86a10e6 _25._tcp.dougbarton.us. IN TLSA 3 1 2 58ecab96a3b995ea6f01dcc5abf1eba4499741fc50028bc988602c8634392edf28ad4e10df2c893014f384548ea0dc1c152601ab363b5620dead76a6b8e89f3e _25._tcp.dougbarton.us. IN TLSA 2 1 1 15bb3ea3e23154d4c70698cd4187d7fd3067c4f0be3962d8c502c4b6a92b01f3 _25._tcp.dougbarton.us. IN TLSA 2 1 2 59110926ac75a748e7fcf68b6baf420f2c7c7fd60824135b436e4e71e13f1f3d489ba4780f59fca779f18e9c604f7bf304c0f4ed69b9c21be271f5ef4e2370ff I'd recommend the "3 1 1 + 2 1 1" combo, but perhaps "3 1 1" alone, or all the above better suit your style. See http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 https://www.ietf.org/mail-archive/web/uta/current/msg01498.html http://tools.ietf.org/html/rfc7671#section-8.1 http://tools.ietf.org/html/rfc7671#section-8.4 -- Viktor.
Re: Problems with lmtp
[ apologies to everyone for the formatting below, the Yahoo! webmail client is simply awful ] On Wed, 3/15/17, Viktor Dukhovni wrote: Subject: Re: Problems with lmtp To: postfix-users@postfix.org Date: Wednesday, March 15, 2017, 7:29 PM On Thu, Mar 16, 2017 at 02:06:37AM +, Doug wrote: > [ Trying this again as I think I sent to the wrong address the first time ] FWIW, it got through both times. I saw that, but thank you for confirming. On Thu, Mar 16, 2017 at 02:01:07AM +, Doug wrote: > I'm on Ubuntu Server 16.04 (up to date) and using the stock postfix package (3.10-3). There is no Postfix 3.10, did you mean 3.1.0-3? Instead of reporting a vendor version string, it is better to report the output of: $ postconf -d mail_version Yes, 3.1.0, thank you. I'll make you a deal, fix the TLSA records for your domains to comply with both RFC7672 and what Postfix supports (as of Postfix 3.2, per RFC7672 PKIX-EE(1) records are treated as "unusable"), and I'll help you with your LMTP transport problem! Given that you've been bullying me on this topic for years, you're well aware of my objections to your approach. But you win, the offending record is gone. I'm not going to turn my domain into a DDOS amplification vector, and given the staggeringly low rate of adoption for DANE I'm not missing anything at this point. See http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 I'm well aware of the problems at StartCom, and my intention has been for quite a while now that when my current set of certs expire this year that I'll shift to Let's Encrypt, as by that time I anticipate that its CA will have been sufficiently widely accepted, and enough folks will have upgraded their stuff, to make that a feasible option. But I'm glad that you posted this, as folks need to be aware of the issues there. Personally my risk is near-zero, as I generated my own CSRs and StartCom has never seen my private keys. But still better off moving away, and supporting a worthy project in the process. Meanwhile, I would welcome your help with my lmtp issue, or not, as you see fit. I do expect though that this is the last I hear from you on the TLSA topic, as your private bullying was quite tedious enough already. Doug
Re: Problems with lmtp
On Thu, Mar 16, 2017 at 04:02:58AM +, Doug wrote: > $ postconf -d mail_version > > Yes, 3.1.0, thank you. Cool. I would expect that this likely contains backports of later patches, but unfortunately the Linux distros tend to avoid backporting upstream version number updates, so it is difficult to tell whether you have all the fixes from 3.1.0 to 3.1.4, but it is quite possible that you do. > The offending record is gone. Thanks. > given the staggeringly low rate of adoption for DANE I'm not missing > anything at this point. Well, DANE is doing comparatively fine, (~111000 domains and growing, this takes time). > Meanwhile, I would welcome your help with my lmtp issue, or not, as you > see fit. I do expect though that this is the last I hear from you on the > TLSA topic, as your private bullying was quite tedious enough already. I am sorry you feel that way, I did not expect that ten or so emails over two weeks back in 2014 as part of a discussion with the draft coauthors would amount to bullying. Anyway, that's all water under the bridge. As promised, I'll help with the LDAP issue: > On my mail host I have 1 normal user. I have postfix configured to accept > mail for several different domains, and each domain has a lot of different > mail usernames (I use this for mailing lists and such). I use the > virtual_maps feature of postfix, and have a map file that looks like this: FWIW, the modern name for this feature is "virtual_alias_maps", this rewrites all envelope recipients (regardless of address class, see http://www.postfix.org/ADDRESS_CLASS_README.html) on input in the cleanup(8) service. By the time mail enters the queue recipients are already rewritten as specified in that table. > All of this works great, and mail for all the different usernames and > domains gets delivered into my one real user's Maildir, and I can see the > mail with my IMAP clients. The important thing to understand here is the difference between the "local", "virtual alias" and "virtual mailbox" address classes, as explained in ADDRESS_CLASS_README. - Domains listed in "mydestination" are "local" and designed for delivery of mail to mailbox that belong to local unix accounts. These are delivered via $local_transport, which is almost always "local" (the local(8) delivery agent (LDA) in master.cf) or "error" if local delivery is disabled. When local delivery is not disabled, the local(8) delivery agent does further rewriting as specified in $alias_maps, and then by default delivers to the user's mbox. However, local(8) is quite fancy, and can also deliver to commands via mailbox_command (often procmail), to mailboxes in a home directory (via $home_mailbox) or to an alternative transport (via mailbox_transport). There are more options see http://www.postfix.org/local.8.html for detail. - Domains listed in virtual_alias_domains are exclusively designated as holding only aliases to other real domains. Don't make the mistake of assuming that a domain must be listed here in order for virtual_alias_maps to happen. See above. - Domains listed in virtual_mailbox_domains are for hosting "virtual users", who do not necessarily have user login accounts. These are handled by $virtual_transport, which defaults to "virtual", the Postfix built-in VDA, but other VDAs can substituted as desired. As explained in ADDRESS_CLASS_README, each address class comes with its recipient validation table: - local: $local_recipient_maps - virtual alias: $virtual_alias_maps (implicitly used for all classes, in addition to the class-specific validation tables). - virtual mailbox: $virtual_mailbox_maps > So according to all the tutorials I've read my assumption is that my next > step is this in postfix' main.cf: > > virtual_transport = lmtp:unix:private/dovecot-lmtp The reason this failed for you, is that your domains are "local" (listed in mydestination) so their delivery is controlled via $local_transport not $virtual_transport. > I have since learned that I probably don't want virtual_transport for > this, but I probably do want local_transport. The problem is that if I > put in local_transport = lmtp:unix:private/dovecot-lmtp I get a bounce > every time: The reason this may fail is that mail is no longer subjected to $alias_maps when you do that. Of course another reason might be that dovecot is not fully configured to receive mail for the addresses in question. In the former case, you can still get aliases(5) to be processed by using: $mailbox_transport = lmtp:unix:private/dovecot-lmtp instead of replacing $local_transport. > Mar 15 18:01:20 dougbarton postfix/lmtp[11793]: 8BCD38F: > to=, relay=dougbarton.us[private/dovecot-lmtp], > delay=0.03, delays=0.01/0/0/0.01, dsn=5.1.1, status=bounced (host > dougbarton.us[private/dovecot-lmtp] said: 550 5.1.1 > U
