Quantcast

Problems with dovecot lmtp

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problems with dovecot lmtp

Doug Barton
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:

[hidden email] normaluser
[hidden email] normaluser
[hidden email] 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=<[hidden email]>, 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 <[hidden email]> User doesn't exist: [hidden email] (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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with lmtp

Viktor Dukhovni
On Thu, Mar 16, 2017 at 02:06:37AM +0000, 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 +0000, 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=<[hidden email]>, 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 <[hidden email]>
> User doesn't exist: [hidden email] (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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with lmtp

Doug Barton
[ apologies to everyone for the formatting below, the Yahoo! webmail client is simply awful ]

--------------------------------------------
On Wed, 3/15/17, Viktor Dukhovni <[hidden email]> wrote:

 Subject: Re: Problems with lmtp
 To: [hidden email]
 Date: Wednesday, March 15, 2017, 7:29 PM
 
 On Thu, Mar 16, 2017 at
 02:06:37AM +0000, 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 +0000, 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
Loading...