simple temporary redirection(s) of all mail?

[PGNet Dev]

 
A frontend postfix install I've in place is being subject to a literal tear-down+relocate of its various backends (relays to other postfix & imap instances).

The building's being torn down, and the occupant's relocating.  Not the best managed process, but oh well.

It's a one-time event; not something I want/need to replicate in the future.

The frontend itself will stay up, and in-service; it's on an offsite VM.

For that^ period, I'd like to 'simply' redirect any/all mail received by the frontend to a few mail addresses hosted at a mail provider.

Specifically,

        if TO: [hidden email], redirect-to: [hidden email]
        if TO: [hidden email], redirect-to: [hidden email]
        if TO: *@example*.com,     redirect-to: [hidden email]

, ideally 'touching' as little as possible of my existing config; the goal being to make minor change, then reverse it soon-enough.  I don't want the bother of spinning up a separate set of backends for this event.

I suspect a map is appropriate (transport?), likely added to master.cf ...

The operating goal is to make all received email accessible/retrievable for the 'down' period.

It doesn't have to be 'pretty', but I would like to avoid shooting myself in the foot.

Advice/recommendations as to how best to do this -- or what to avoid! -- would be appreciated.

[Wietse Venema]

PGNet Dev:

>  
> A frontend postfix install I've in place is being subject to a
> literal tear-down+relocate of its various backends (relays to other
> postfix & imap instances).
>
> The building's being torn down, and the occupant's relocating.
> Not the best managed process, but oh well.
>
> It's a one-time event; not something I want/need to replicate in the future.
>
> The frontend itself will stay up, and in-service; it's on an offsite VM.
>
> For that period, I'd like to 'simply' redirect any/all mail
> received by the frontend to a few mail addresses hosted at a mail
> provider.
>
> Specifically,
>
> if TO: [hidden email], redirect-to: [hidden email]
> if TO: [hidden email], redirect-to: [hidden email]
> if TO: *@example*.com,     redirect-to: [hidden email]

This would be good fit for virtual_alias_maps (and maybe adding
domains to virtual_alias_domains, see note below). virtual_alias_maps
replaces the envelope recipient without replacing header addresses,
and it works for single-recipient mail equally well as multi-recipient
mail.

You cam use a hash: map, a regular expression map, or some combination
of the two.

If you also add example.com to virtual_alias_domains, Postfix will
reject mail for [hidden email] if that address is not listed in
virtual_alias_maps.

        Wietse

> , ideally 'touching' as little as possible of my existing config; the goal being to make minor change, then reverse it soon-enough.  I don't want the bother of spinning up a separate set of backends for this event.
>
> I suspect a map is appropriate (transport?), likely added to master.cf ...
>
> The operating goal is to make all received email accessible/retrievable for the 'down' period.
>
> It doesn't have to be 'pretty', but I would like to avoid shooting myself in the foot.
>
> Advice/recommendations as to how best to do this -- or what to avoid! -- would be appreciated.
>
>

[PGNet Dev]

On 11/22/20 11:58 AM, Wietse Venema wrote:
> This would be good fit for virtual_alias_maps (and maybe adding
> domains to virtual_alias_domains, see note below).

Good then.  That'll work nicely.

All my postfix+imap backends have the virtual_alias_foo mappings; the frontend checks via address_verify.

So doing this^ on the front-end is nice-n-tidy and easily reversible.



> virtual_alias_maps

> replaces the envelope recipient without replacing header addresses,

> and it works for single-recipient mail equally well as multi-recipient

> mail.

Good reminder.  IIUCm then pulling those temporarily-hosted, redirected emails BACK into the production backend once everything's back in place should be fairly straightforward.

Thx!

[PGNet Dev]

On 11/22/20 11:58 AM, Wietse Venema wrote:

> This would be good fit for virtual_alias_maps (and maybe adding

> domains to virtual_alias_domains, see note below). virtual_alias_maps

> replaces the envelope recipient without replacing header addresses,

> and it works for single-recipient mail equally well as multi-recipient

> mail.



I'm trying this 'temporary redirect' approach for several configs.



For one working setup/config, mail to "[hidden email]" is normally accepted by my postfix frontend, & flows through to my backend(s).



Adding the intercepting virtual_alias_* redirect "early" in the frontend config



        master.cf



                [mx1.example.net]:25  inet  n  -  n  -  1  postscreen

                -o postscreen_tls_security_level=may

                -o smtpd_authorized_xforward_hosts=127.0.0.0/8,$var_MX1/32,$var_MX2/32

                -o smtpd_service_name=postscreen-internal



                postscreen-internal pass  -  -  n  -  -  smtpd

                -o syslog_name=postfix/postscreen-internal

        + -o virtual_alias_domains=lmdb:/etc/postfix/TEMP_virtual_alias_domains

        + -o virtual_alias_maps=lmdb:/etc/postfix/TEMP_virtual_alias_maps

                -o smtpd_tls_ask_ccert=no

                -o smtpd_tls_security_level=may

                -o smtpd_tls_loglevel=1

                -o smtpd_tls_received_header=yes

                -o address_verify_transport_maps=lmdb:/etc/postfix/adress_verify_transport_map

                -o smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination,permit

                -o smtpd_authorized_xforward_hosts=127.0.0.0/8,$var_MX1/32,$var_MX2/32

                -o smtpd_client_connection_count_limit=25

                -o smtpd_client_connection_rate_limit=0

                -o anvil_rate_time_unit=60s

                -o smtpd_proxy_timeout=300s

                -o smtpd_proxy_options=speed_adjust

                -o smtpd_proxy_filter=[127.0.0.1]:21030



                ...



where



        cat /etc/postfix/TEMP_virtual_alias_domains

                example.com    REDIRECT



        cat /etc/postfix/TEMP_virtual_alias_maps

                [hidden email]    [hidden email]





With that^, I intended for mail to



        [hidden email]



to be immediately intercepted+redirected to [hidden email].



It does not.

Instead, it flows through as usual to my backend.



I _think_ my virtual_alias_* syntax/usage is correct.

Is the fail-to-redirect an order of execution problem?



My notes on usual exec order are:



        postscreen, smtpd_mumble_restrictions, milter SMTP command inspection,

        smtpd_proxy_filter, header/body_checks, milter header/body inspection, content_filter



Is the virtual_alias_* considered a "header/body_checks", lower in priority than the existing/used "smtpd_proxy_filter",

and hence is ignored?



Or is my fail to redirect due to another cause?

[Wietse Venema]

PGNet Dev:

> On 11/22/20 11:58 AM, Wietse Venema wrote:
>
> > This would be good fit for virtual_alias_maps (and maybe adding
> > domains to virtual_alias_domains, see note below). virtual_alias_maps
> > replaces the envelope recipient without replacing header addresses,
> > and it works for single-recipient mail equally well as multi-recipient
> > mail.
>
> I'm trying this 'temporary redirect' approach for several configs.
>
> For one working setup/config, mail to "[hidden email]" is
> normally accepted by my postfix frontend, & flows through to my
> backend(s).
>
> Adding the intercepting virtual_alias_* redirect "early" in the
> frontend config
>
> master.cf
>
> [mx1.example.net]:25  inet  n  -  n  -  1  postscreen
> -o postscreen_tls_security_level=may
> -o smtpd_authorized_xforward_hosts=127.0.0.0/8,$var_MX1/32,$var_MX2/32
> -o smtpd_service_name=postscreen-internal
> postscreen-internal pass  -  -  n  -  -  smtpd
> -o syslog_name=postfix/postscreen-internal
> + -o virtual_alias_domains=lmdb:/etc/postfix/TEMP_virtual_alias_domains
> + -o virtual_alias_maps=lmdb:/etc/postfix/TEMP_virtual_alias_maps
> -o smtpd_tls_ask_ccert=no
> -o smtpd_tls_security_level=may
> -o smtpd_tls_loglevel=1
> -o smtpd_tls_received_header=yes
> -o address_verify_transport_maps=lmdb:/etc/postfix/adress_verify_transport_map
> -o smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination,permit
> -o smtpd_authorized_xforward_hosts=127.0.0.0/8,$var_MX1/32,$var_MX2/32
> -o smtpd_client_connection_count_limit=25
> -o smtpd_client_connection_rate_limit=0
> -o anvil_rate_time_unit=60s
> -o smtpd_proxy_timeout=300s
> -o smtpd_proxy_options=speed_adjust
> -o smtpd_proxy_filter=[127.0.0.1]:21030

Note that smtpd does not implement the virtual alias mapping. It
merely determines if the recipient address should be accepted or
rejected.

The virtual alias mapping happens on the other end of the
smtpd_proxy_filter (presumably, another smtpd process that feeds
into a cleanup process that does the virtual alias expansion).

        Wietse

[PGNet Dev]

On 11/23/20 6:48 AM, Wietse Venema wrote:
> Note that smtpd does not implement the virtual alias mapping. It
> merely determines if the recipient address should be accepted or
> rejected.
>
> The virtual alias mapping happens on the other end of the
> smtpd_proxy_filter (presumably, another smtpd process that feeds
> into a cleanup process that does the virtual alias expansion).

Ah, Ok.  I can move the virtual_alias_* later.

Then I _think_ I need to conditionally avoid the

   -o address_verify_transport_maps=lmdb:/etc/postfix/adress_verify_transport_map

check in the 'postscreen-internal' smtpd stage.  Since I run this as an only-address_verify setup, when the backends are offline, that'll fail ...

[Wietse Venema]

PGNet Dev:

> On 11/23/20 6:48 AM, Wietse Venema wrote:
> > Note that smtpd does not implement the virtual alias mapping. It
> > merely determines if the recipient address should be accepted or
> > rejected.
> >
> > The virtual alias mapping happens on the other end of the
> > smtpd_proxy_filter (presumably, another smtpd process that feeds
> > into a cleanup process that does the virtual alias expansion).
>
> Ah, Ok.  I can move the virtual_alias_* later.
>
> Then I _think_ I need to conditionally avoid the
>
>    -o address_verify_transport_maps=lmdb:/etc/postfix/adress_verify_transport_map

The address_verify_transport_maps setting is implemented by the
trivial-rewrite service. It has no effect on postscreen or smtpd.

        Wietse