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. > 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=<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 <do...@dougbarton.us> > User doesn't exist: do...@dougbarton.us (in reply to RCPT TO command)) So Dovecot has no idea how to deliver <do...@dougbarton.us>, if that's the correct mailbox address, then your problem is with Dovecot, but if upstream aliases(5) rewriting failed to happen in Postfix, see above. > From further reading it seems that I need to add some sort of additional > mapping, but it's not clear to me what. Either more virtual_alias_maps entries (I authoritatively recommend avoiding aliases(5) for simple user->user mappings, that's best done in virtual(5)), or once again override mailbox_transport instead of local_transport. > Adding my virtual_maps file to local_recipient_maps didn't work. And is completely unnecessary, since always implicit, and the problem was not recipient validation, see above. > I also tried 'local_recipient_maps = ' > to see if I could rule out a chroot issue, but that didn't work either. The local_recipient_maps parameter is used to reject non-existent users (and thus avoid backscatter) during the SMTP dialogue in the Postfix SMTP server, not in Dovecot. > Here is postconf -n with security-related and boring items removed. > > alias_maps = hash:/etc/aliases Check this for any relevant mappings. > home_mailbox = Maildir/ This makes Postfix deliver mail to "local" user accounts to $HOME/Maildir unless preempted by other settings. > local_recipient_maps = proxy:unix:passwd.byname $alias_maps This is not pertinent to the problem. > mydomain = dougbarton.us > mydestination = $mydomain, localhost.$mydomain, localhost This is why local_transport, etc. are what you need to focus on. > 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. > virtual_transport = lmtp:unix:private/dovecot-lmtp As before this does nothing in the absence of virtual_mailbox_domains and virtual_mailbox_maps (at least for recipient validation and with virtual(8) also for mailbox locations). > Any help will be greatly appreciated. I hope this helps to put any ill will behind. -- Viktor.
