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.
