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. |
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. > > |
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! |
In reply to this post by Wietse Venema
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? |
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 |
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 ... |
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 |
Free forum by Nabble | Edit this page |