virtual_alias_domains/maps and address classes

[b...@bitrate.net]

hi-

i recently started using lmtp to deliver to dovecot for filesystem delivery. previous to that change, i'd used virtual(8), and thus was using virtual_mailbox_domains/maps, and virtual_alias_maps as well. shortly after switching, it occurred to me that since postfix was no longer involved in delivery to the filesystem, the virtual mailbox domain class perhaps wasn't really needed, and that the relay domain class might be more appropriate. in the process of setting this up and testing it, and referring back to ADDRESS_CLASS_README, some questions arose.

using relay_domains and relay_recipient_maps did work as expected, but during the exercise, i realized that alias expansion would still be needed. using virtual_alias_maps worked for this, as it had when i was using the virtual mailbox domain class, but although i'm glad it did, it left me wondering why. given my understanding of address classes, it seemed that in order to use virtual_alias_maps, those related domains would need to be listed in virtual_alias_domains. yet the same domains would also need to be listed in relay_domains in order to use the relay domain class, and i know listing the same domain in multiple classes is an error. so there seemed to be a bit of a catch-22 in that regard, yet with my configuration of domains listed in relay_domains, and an empty virtual_alias_domains, virtual_alias_maps was being used, and messages were being handled as desired. in hindsight, i'm aware this isn't fundamentally different from when i was using the virtual mailbox domain class, but for whatever reason, it didn't strike me until now.

given that preamble, i'm a] curious if i've configured things sanely, and b] if so, would like to better understand the nuances with virtual_alias_maps that i think i'm missing. in an effort to better understand this, i've gone back and reread ADDRESS_REWRITING_README and VIRTUAL_README, but i'm not able to find clarity.

postconf -n and master.cf [extraneous comments removed] below for reference.

thanks
-ben

postconf -n:
alias_database =
alias_maps =
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
content_filter = lmtp-amavis:[localhost]:amavisd-maia
delay_warning_time = 4h
disable_vrfy_command = yes
inet_protocols = all
local_recipient_maps =
local_transport = error:local mail delivery is disabled
masquerade_domains = $mydomain
message_size_limit = 15728640
milter_default_action = accept
mydestination =
mydomain = example.net
myhostname = $smtpd_myhostname
mynetworks =
myorigin = $mydomain
recipient_delimiter = +
relay_domains = proxy:ldap:$table_directory/relay_domains.cf
relay_recipient_maps = proxy:ldap:$table_directory/relay_recipient_maps.cf
relay_transport = dovecot:[localhost]:lmtp-deliver
smtp_helo_name = $smtpd_myhostname
smtp_tls_CAfile = /etc/pki/trusted_roots/ca-certificates.crt
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_use_tls = yes
smtpd_authorized_xforward_hosts = 192.0.2.2
smtpd_banner = $smtpd_myhostname ESMTP mail_delivery_service
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_etrn_restrictions = reject
smtpd_helo_required = yes
smtpd_recipient_restrictions = base_recipient_restrictions,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
reject_unauth_destination,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
permit
smtpd_restriction_classes = base_recipient_restrictions,
smspd_recipient_restrictions
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/pki/trusted_roots/ca-certificates.crt
smtpd_tls_cert_file = $config_directory/pki/mda.example.net-cert.pem
smtpd_tls_dh1024_param_file = $config_directory/pki/dh_1024.pem
smtpd_tls_dh512_param_file = $config_directory/pki/dh_512.pem
smtpd_tls_key_file = $config_directory/pki/mda.example.net-key.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
strict_rfc821_envelopes = yes
transport_maps = proxy:ldap:$table_directory/transport_maps.cf
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 554
unknown_relay_recipient_reject_code = 554
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_domains =
virtual_alias_maps = proxy:ldap:$table_directory/virtual_alias_maps-address_literals.cf,
proxy:ldap:$table_directory/virtual_alias_maps-user_aliases.cf,
proxy:ldap:$table_directory/virtual_alias_maps-distribution_lists.cf

master.cf:
/etc/postfix >cat master.cf
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================

192.0.2.1:smtp inet n - n - - smtpd

smsp inet n - - - - smspd
-o myhostname=$smspd_myhostname
-o smtpd_banner=$smspd_banner
-o smtpd_tls_security_level=$smspd_tls_security_level
-o smtpd_tls_key_file=$smspd_tls_key_file
-o smtpd_tls_cert_file=$smspd_tls_cert_file
-o smtpd_sasl_auth_enable=$smspd_sasl_auth_enable
-o smtpd_recipient_restrictions=smspd_recipient_restrictions

pickup fifo n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
-o smtp_fallback_relay=
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 1 scache

# for dovecot via lmtp
dovecot unix - - n - - lmtp

# for passing to amavis
lmtp-amavis unix - - n - 5 lmtp
-o lmtp_data_done_timeout=1200
-o lmtp_send_xforward_command=yes
-o disable_dns_lookups=yes

# for reinjection from amavis
localhost:smtp-reinject inet n - - - - reinject
-o smtpd_banner=$smtpd_reinjection_banner
-o mynetworks=127.0.0.1/32
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o strict_rfc821_envelopes=yes
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000

[Viktor Dukhovni]

On Mon, Apr 09, 2012 at 10:21:05PM -0400, b...@bitrate.net wrote:

> Given my understanding of address classes, it seemed that in order to use

> virtual_alias_maps, those related domains would need to be listed in
> virtual_alias_domains.

This assumption is incorrect. All recipients, regardless of address
class are subject to virtual(5) rewriting.

--
Viktor.

[btb]

so the relationship between virtual_alias_maps/virtual_alias_domains is
not quite the same as the relationship between
virtual_mailbox_maps/virtual_mailbox_domains or
relay_recipients/relay_domains?

meaning- iiuc, in order for virtual_milbox_maps to be used for a given
domain, the domain needs to be listed in virtual_mailbox_domains, and
the same concept for the relay domain class. is this right?

whereas with virtual_alias_maps, this is always used, regardless of if a
given domain is listed in virtual_alias_domains - and, putting the given
domain in virtual_alias_domains serves not to allow virtual_alias_maps
to work, but rather to preclude the given domain from being in some
other address class [i.e. to isolate the domain as *only* a virtual
alias domain]?

-ben

[Wietse Venema]

btb:
[ Charset ISO-8859-1 unsupported, converting... ]

> On 2012.04.09 23.32, Viktor Dukhovni wrote:
> > On Mon, Apr 09, 2012 at 10:21:05PM -0400, b...@bitrate.net wrote:
> >
> >> Given my understanding of address classes, it seemed that in order to use
> >> virtual_alias_maps, those related domains would need to be listed in
> >> virtual_alias_domains.
> >
> > This assumption is incorrect. All recipients, regardless of address
> > class are subject to virtual(5) rewriting.
>
> so the relationship between virtual_alias_maps/virtual_alias_domains is
> not quite the same as the relationship between
> virtual_mailbox_maps/virtual_mailbox_domains or
> relay_recipients/relay_domains?

This is documented in virtual(5).

Wietse

[/dev/rob0]

On Tue, Apr 10, 2012 at 08:10:52AM -0400, btb wrote:
> On 2012.04.09 23.32, Viktor Dukhovni wrote:
> >On Mon, Apr 09, 2012 at 10:21:05PM -0400, b...@bitrate.net wrote:
> >
> >>Given my understanding of address classes, it seemed that in
> >>order to use virtual_alias_maps, those related domains would need
> >>to be listed in virtual_alias_domains.
> >
> >This assumption is incorrect. All recipients, regardless of
> >address class are subject to virtual(5) rewriting.
>
> so the relationship between virtual_alias_maps/
> virtual_alias_domains is not quite the same as the relationship
> between virtual_mailbox_maps/virtual_mailbox_domains or
> relay_recipients/relay_domains?
>

> meaning- iiuc, in order for virtual_milbox_maps to be used for a
> given domain, the domain needs to be listed in
> virtual_mailbox_domains, and the same concept for the relay domain
> class. is this right?
>
> whereas with virtual_alias_maps, this is always used, regardless
> of if a given domain is listed in virtual_alias_domains -

Yes.

> and, putting the given domain in virtual_alias_domains serves
> not to allow virtual_alias_maps to work, but rather to preclude
> the given domain from being in some other address class [i.e. to
> isolate the domain as *only* a virtual alias domain]?

That's one effect. Another effect is that the virtual_alias_maps
expansion is constrained such that the final result must be an
address which is *not* in virtual_alias_domains.

myorigin = example.com
virtual_alias_domains = example.com[, ...]

virtual_alias_maps include:

b...@example.com btb

Now, mail to b...@example.com is rejected with "User unknown in
virtual alias table."
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

[btb]

On 2012.04.10 08.32, Wietse Venema wrote:
>> so the relationship between virtual_alias_maps/virtual_alias_domains is

>> not quite the same as the relationship between
>> virtual_mailbox_maps/virtual_mailbox_domains or
>> relay_recipients/relay_domains?
>

> This is documented in virtual(5).

thanks for the clarification, i think i understand now. would an
adjustment to ADDRESS_CLASS_README be helpful in highlighting this?

e.g.:

>cat ADDRESS_CLASS_README.patch
--- ADDRESS_CLASS_README 2007-03-25 10:53:46.000000000 -0400
+++ ADDRESS_CLASS_README.mod 2012-04-10 09:20:45.000000000 -0400
@@ -83,6 +83,10 @@
* There is no mail delivery transport parameter. Every address must be
aliased to some other address.

+ * Note: virtual_alias_maps will be used with other address classes unless
+ a given domain is listed in virtual_alias_domains. see the section on
+ VIRTUAL ALIAS DOMAINS in virtual(5) for details.
+
The virtual mailbox domain class.

* Purpose: final delivery for hosted domains where each recipient
address can

-ben

[/dev/rob0]

On Tue, Apr 10, 2012 at 09:36:42AM -0400, btb wrote:
> On 2012.04.10 08.32, Wietse Venema wrote:
> >>so the relationship between virtual_alias_maps/
> >>virtual_alias_domains is not quite the same as the relationship
> >>between virtual_mailbox_maps/virtual_mailbox_domains or
> >>relay_recipients/relay_domains?
> >
> >This is documented in virtual(5).
>
> thanks for the clarification, i think i understand now. would an
> adjustment to ADDRESS_CLASS_README be helpful in highlighting this?
>
> e.g.:
>
> >cat ADDRESS_CLASS_README.patch
> --- ADDRESS_CLASS_README 2007-03-25 10:53:46.000000000 -0400
> +++ ADDRESS_CLASS_README.mod 2012-04-10 09:20:45.000000000 -0400
> @@ -83,6 +83,10 @@
> * There is no mail delivery transport parameter. Every address must be
> aliased to some other address.
>
> + * Note: virtual_alias_maps will be used with other address classes unless
> + a given domain is listed in virtual_alias_domains. see the section on

To me, this confuses things more. virtual_alias_maps will be
consulted (and its results applied) regardless of class, and
regardless of existence of any virtual_alias_domains.

> + VIRTUAL ALIAS DOMAINS in virtual(5) for details.
> +
> The virtual mailbox domain class.
>
> * Purpose: final delivery for hosted domains where each recipient
> address can

[b...@bitrate.net]

On Apr 10, 2012, at 10.44, /dev/rob0 wrote:
>> + * Note: virtual_alias_maps will be used with other address classes unless
>> + a given domain is listed in virtual_alias_domains. see the section on
>
> To me, this confuses things more. virtual_alias_maps will be
> consulted (and its results applied) regardless of class, and
> regardless of existence of any virtual_alias_domains.

i see your point. would this be less confusing?

--- ADDRESS_CLASS_README 2007-03-25 10:53:46.000000000 -0400

+++ ADDRESS_CLASS_README.mod 2012-04-10 22:04:19.000000000 -0400

@@ -83,6 +83,10 @@
* There is no mail delivery transport parameter. Every address must be
aliased to some other address.

+ * Note: virtual_alias_maps will be consulted (and its results applied) by
+ all address classes unless a given domain is listed in virtual_alias_domains.
+ See the section on VIRTUAL ALIAS DOMAINS in virtual(5) for details.

+
The virtual mailbox domain class.

* Purpose: final delivery for hosted domains where each recipient address can

my goal is to just briefly highlight the way in which it doesn't follow quite the same convention as the other address classes, and to guide the reader a bit more directly to the documentation which provides details.

-ben

[Wietse Venema]

b...@bitrate.net:

> i see your point. would this be less confusing?
>
> --- ADDRESS_CLASS_README 2007-03-25 10:53:46.000000000 -0400
> +++ ADDRESS_CLASS_README.mod 2012-04-10 22:04:19.000000000 -0400
> @@ -83,6 +83,10 @@
> * There is no mail delivery transport parameter. Every address must be
> aliased to some other address.
>
> + * Note: virtual_alias_maps will be consulted (and its results applied) by
> + all address classes unless a given domain is listed in virtual_alias_domains.
> + See the section on VIRTUAL ALIAS DOMAINS in virtual(5) for details.
> +

No. virtual_alias_maps is ALWAYS consulted, without any "unless"
conditions.

Wietser