Good news is that I solved the short term problem (delivery via lmtp now works). More below. Lots of snipping to strip out what turned out to be the irrelevant bits.
-------------------------------------------- On Wed, 3/15/17, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote: Subject: Re: Problems with lmtp To: postfix-users@postfix.org Date: Wednesday, March 15, 2017, 10:15 PM On Thu, Mar 16, 2017 at 04:02:58AM +0000, 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. [] Yeah, there are a lot of things I like about the way debian and its derivatives handle packaging, but this not one of them. :-/ > 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: > 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. [] Yeah, I think it's coming clear. I read through that tonight, need to read some more to digest better. I see (or think I see) how the virtual_alias_domains and virtual_alias_maps would work to do the same thing I'm doing now. - 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. [] Ok, I'll bite .... what makes virtual_alias_maps happen? > 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. [] Yes, I've grasped that now, thank you for confirming. > 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=<do...@dougbarton.us>,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...@dougbarton.us> > User doesn't exist: u...@dougbarton.us (in reply to RCPT TO command)) So Dovecot has no idea how to deliver <u...@dougbarton.us>, if that's the correct mailbox address, then your problem is with Dovecot [] After a lot more testing tonight that was the problem. Short version is (as I understand it) that lmtp expects a full address (u...@domain.tld), which is what postfix is feeding it. The problem is then getting dovecot to understand what to do with that fully qualified user once it gets it. For my case, since the 'user' that postfix is mapping to is the same as the local Unix user I want it delivered to, the answer is to put this in dovecot.conf: auth_username_format=%n That tells dovecot to only deal with the username portion, not the whole string. > Here is postconf -n with security-related and boring items removed. > > alias_maps = hash:/etc/aliases Check this for any relevant mappings. [] Nothing exciting, just the default postmaster:root > home_mailbox = Maildir/ This makes Postfix deliver mail to "local" user accounts to $HOME/Maildir unless preempted by other settings. [] Yeah, been thinking that was going to be redundant when I get things working. > virtual_maps = hash:/etc/postfix/virtual_addresses This is best expressed as: virtual_alias_maps = hash:/etc/postfix/virtual_addresses and either: virtual_alias_domains = or perhaps if you need to accept additional domains and rewrite to dougbarton.us via virtual_alias_maps: virtual_alias_domains = dougbarton.net, dougb.net, supersetsolutions.com, dougbarton.email in any case I strongly recommand separating virtual_alias_domains from virtual_alias_maps. [] Ok, I think I'm getting it now. Once I solve the lmtp problem I will tackle making this stuff more rational. It sounds like my plan is to do the following: 1. Keep all the domains in mydestination since I want them all locally delivered. 2. s/virtual_maps/virtual_alias_maps/ 3. virtual_alias_domains= Does that sound about right? I'm not brave enough to do that now since I need sleep, but I will give it a try tomorrow when I can watch the logs in the background. I hope this helps to put any ill will behind. [] Indeed, thank you. Doug
