On Thu, Mar 16, 2017 at 08:56:20AM +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. :-/
Turns out (per Scott Kitterman that Ubuntu may not in general backport fixes from Postfix patch releases. That's a shame. Relevant post-release updates include: 20160310 Bugfix (introduced: Postfix 2.6): the Milter SMFIR_CHGFROM (replace sender) request lost the sender_bcc_maps address. Fixed by moving some record keeping to the sender output function. Files: cleanup/cleanup_envelope.c, cleanup/cleanup_addr.c, cleanup/cleanup_milter.c, cleanup/cleanup.h, regression tests. 20160410 Bugfix (introduced: Postfix 2.6): the "bad filetype" header_checks pattern falsely rejected Content-Mumble headers with ``name="example"; x-apple-part-url="example.com"''. Fixed by respecting the ";" separator between content attribute values. Reported by Cedric Knight. File: proto/header_checks. 20160619 Bugfix (introduced: 20091121): with the introduction of sender_dependent_default_transport_maps, the SMTP daemon was not updated. This resulted in false rejects with sender-dependent "error" transports. Based on a fix by Russell Yanofsky. Files: global/resolve_clnt.c, global/resolve_clnt.h, smtpd/smtpd_check.c, smtpd/smtpd_check.h, smtpd/smtpd_milter.c, smtpd/smtpd_resolve.c, smtpd/smtpd_resolve.h. 20160717 Bugfix (introduced: Postfix 1.1): the virtual(8) delivery agent discarded the error result from vstream_fseek(). File: virtual/mailbox.c. 20160730 Bugfix (introduced: 20090614): with concurrent connections from the same client IP address, and after-220 tests enabled, postscreen could overwrite the cached "all tests completed" result of one connection that completed the after-220 tests, with the "some tests not completed" result of a concurrent connection where the client hung up later, without completing the after-220 tests. 20160821 Bugfix (introduced: Postfix 3.0): the tls_session_ticket_cipher documentation says aes-256-cbc, but the implementation was using aes-128-cbc (note that Postfix session ticket keys are rotated after 1/2 hour, to limit the impact of attacks on session ticket keys). 20160911 Bugfix (introduced: Postfix 3.0): the SMTP daemon did not reset a previous session's command counts before rejecting a client that exceeds request or concurrency rates. File: smtpd/smtpd.c. 20160917 Bugfix (introduced: Postfix 3.0): the unionmap did not propagate table lookup errors. Based on patch by Roel van Meer. Files: util/dict_union.c, util/dict_union_test.*. 20160925 Workaround (problem introduced: Postfix 2.11): to avoid false "not found" errors with MySQL map queries that contain UTF8-encoded text, specify "option_group = client" in Postfix MySQL configuration files. This will be the default setting with Postfix 3.2 and later. 20161105 Bugfix (introduced: Postfix 1.1): the postsuper command did not count a successful rename operation after error recovery. Problem reported by Markus Schönhaber. File: postsuper/postsuper.c. 20161204 Bugfix (introduced: Postfix 3.1): cut-and-paste error in the "postfix tls deploy-server-cert" command, causing the wrong certfile and keyfile to be used. Viktor Dukhovni. File: conf/postfix-tls-script. Robustness: create a new keyfile when "postfix tls new-server-cert" is invoked and main.cf specifies a non-existent keyfile. Viktor Dukhovni. File: conf/postfix-tls-script. 20161206 Bugfix (introduced: Postfix 3.0): when receiving a MAIL FROM...SMTPUTF8 command while smtpd_delay_reject=no, enable SMTPUTF8 support before processing smtpd_sender_restrictions. Problem reported by Viktor Dukhovni. File: smtpd/smtpd.c. 20161220 Bugfix (introduced: Postfix 2.1.0): the Postfix SMTP daemon did not query sender_canonical_maps when rejecting unknown senders with "smtpd_reject_unlisted_recipient = yes" or with reject_unlisted_sender. Stephen R. van den Berg (Mr. procmail). Files: smtpd/smtpd.c, smtpd/smtpd_check.c. > > 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. Indeed, all my domains are virtual alias domains, whose valid recipients are rewritten to the synthetic virtual mailbox domain "virtual.invalid", which is delivered to Dovecot. I don't use local(8) for delivery, but it would be useful if I had to support mailing lists, vacation, ... That can always be added by rewriting addresses to a "local.invalid" domain, and delivering only that domain locally. main.cf: indexed = ${default_database_type}:${config_directory}/ transport_maps = ${indexed}transport # All real domains are virtual alias domains # virtual_alias_domains = ${indexed}vdomains virtual_alias_maps = ${indexed}valiases # No real virtual mailbox domains, but virtual mailbox # delivery still happens via rewrites into "virtual.invalid" # and the aid of a transport table entry. # virtual_mailbox_domains = # Mailbox storage configuration for virtual(8), not needed when # delivery is to Dovecot via LMTP. See also message_size_limit # virtual_mailbox_limit = 209715200 virtual_mailbox_maps = ${indexed}vmbox virtual_mailbox_base = /var/spool/virtual # When using the built-in virtual(8) delivery agent, these need # to match the uid/gid used by Dovecot to manage maildirs virtual_uid_maps = static:500 virtual_gid_maps = static:500 # No real local domains, but local(8) delivery still happens via # rewrites into "local.invalid" and the aid of a transport table # entry mydestination = local_transport = error:5.1.2 Mailbox unavailable local_recipient_maps = alias_database = ${indexed}aliases alias_maps = $alias_database transport: # Postfix built-in virtual(8) delivery virtual.invalid virtual local.invalid local vdomains: example.org virtual alias domain example.net virtual alias domain ... valiases: us...@example.org user1@virtual.invalid us...@example.net user2@virtual.invalid somel...@example.org somelist@local.invalid # virtual alias mapping is recursive twous...@example.org us...@example.org, us...@example.net postmas...@example.org us...@example.org postmas...@example.net us...@example.net vmbox: user1@virtual.invalid user1/ user2@virtual.invalid user2/ aliases: owner-somelist: us...@example.org somelist: :include:/some/user/listfile > - 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? The use of virtual alias maps happens for all recipients, as part of mail entering the queue via cleanup(8). Not dependent on the address class. It is possible to disable this (with care) via receive_overrride_options, either before or after a content_filter. See FILTER_README for details. > > 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. Yes. > 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 Or similar, yes. I have: userdb { args = uid=500 gid=500 home=/var/spool/virtual mail=maildir:/var/spool/virtual/%n driver = static } > 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. Not required, see above. Postfix has a notion of "final" domains, which subsumes "virtual alias", "virtual mailbox" and "local" domains. You can use any combination of these for "locally delivered" mail. I tend to keep mydestination empty. See also the null-client walk-throgh in MULTI_INSTANCE_README. > 2. s/virtual_maps/virtual_alias_maps/ > 3. virtual_alias_domains= Yes, or, if you prefer, make *all* the "real" domains virtual alias, and use synthetic domains for delivery. See above. One disadvantage (or advantage if you like that) of mydestination, is that the namespace of users (presumed local unix accounts) is the same in all domains listed in mydestination. So if you have example.com and example.net both in mydestination, and user "bob" has a "b...@example.com" email address, then necessarily "b...@example.net" is also bob's address. With virtual alias or virtual mailbox domains each domain's namespace is independent. > 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. Sounds reasonable to me. -- Viktor.