Understanding multi-instance transport tables

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Understanding multi-instance transport tables

Alex Regan
Hi,

I'm still working on trying to get my multi-instance postfix
installation working with amavis.

I'd like to try and do this without using content_filter but I'm
having a problem.

Mail appears to be completely ignoring the amavisd proxy despite
configuring default_transport to use 10025.

# netstat -ntap|grep 1002
tcp        0      0 127.0.0.1:10025         0.0.0.0:* LISTEN
598039/amavisd (mas
tcp        0      0 127.0.0.1:10026         0.0.0.0:* LISTEN      597710/master

# postmulti -l
-               -               y         /etc/postfix
postfix-out     mta             y         /etc/postfix-out
postfix-114     mta             y         /etc/postfix-114
postfix-117     mta             y         /etc/postfix-117

postfix-114
default_transport = smtp:[127.0.0.1]:10025
relay_transport = $default_transport
virtual_transport = $default_transport

postfix-117
default_transport = smtp:[127.0.0.1]:10025
relay_transport = $default_transport
virtual_transport = $default_transport

In postfix-out:
# Replace default "smtp inet" entry with one listening on port 10026.
127.0.0.1:10026     inet  n       -       n       -       -       smtpd

I've experimented with transport_maps like this:
mycompany.org                      smtp-amavis:[127.0.0.1]:10025

smtp-amavis unix    -       -       n       -       -   smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes

but mail just sits in the queue:

# mailq -C /etc/postfix-117
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
D9DE7200B23F3    2516 Tue Nov  3 20:34:30  [hidden email]
(lost connection with 127.0.0.1[127.0.0.1] while receiving the initial
server greeting)
                                         [hidden email]

What am I missing? I don't know what more info I can provide to
troubleshoot this.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Wietse Venema
Alex:
> # mailq -C /etc/postfix-117
> -Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
> D9DE7200B23F3    2516 Tue Nov  3 20:34:30  [hidden email]
> (lost connection with 127.0.0.1[127.0.0.1] while receiving the initial
> server greeting)

In the SMTP client configuration, I suspect that you need
to set smtp_bind_address=127.0.0.1 or smtp_bind_address=
(i.e. explicitly empty).

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Viktor Dukhovni
In reply to this post by Alex Regan
On Wed, Nov 04, 2020 at 12:14:14PM -0500, Alex wrote:

> I'd like to try and do this without using content_filter but I'm
> having a problem.

When doing that, you need to make sure that all the address classes in
the pre-filter instance route into the filter.  In particular, if you
have a non-empty "mydestination", you need to override local_transport
to deliver mail via smtp into the filter, and a similar override for
virtual_transport if you have virtual_mailbox_domains...

>
> Mail appears to be completely ignoring the amavisd proxy despite
> configuring default_transport to use 10025.

The default_transport is a last-resort, it is preëmpted both by the
transport table, and the addres-class-specific transports.  It handles
"other people's domains".  Mail for your own domains (local, virtual
mailbox, relay, ...) uses local_transport, virtual_transport or
relay_transport.  And all those are secondary to any transport(5)
table you have configured.


> # postmulti -l
> -               -               y         /etc/postfix
> postfix-out     mta             y         /etc/postfix-out
> postfix-114     mta             y         /etc/postfix-114
> postfix-117     mta             y         /etc/postfix-117

Looks OK so far.

> postfix-114
> default_transport = smtp:[127.0.0.1]:10025
> relay_transport = $default_transport
> virtual_transport = $default_transport
>
> postfix-117
> default_transport = smtp:[127.0.0.1]:10025
> relay_transport = $default_transport
> virtual_transport = $default_transport

Is "local_transport" relevant?  Do you have a transport table?

> In postfix-out:
> # Replace default "smtp inet" entry with one listening on port 10026.
> 127.0.0.1:10026     inet  n       -       n       -       -       smtpd

OK.

> I've experimented with transport_maps like this:
> mycompany.org                      smtp-amavis:[127.0.0.1]:10025

That should override any other transport settings for the domain
in question.

> smtp-amavis unix    -       -       n       -       -   smtp
>     -o smtp_data_done_timeout=1200
>     -o smtp_send_xforward_command=yes
>
> but mail just sits in the queue:
>
> # mailq -C /etc/postfix-117
> -Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
> D9DE7200B23F3    2516 Tue Nov  3 20:34:30  [hidden email]
> (lost connection with 127.0.0.1[127.0.0.1] while receiving the initial
> server greeting)
>                                          [hidden email]

The downstream amavis or Postfix is not configured correctly and is
dropping connections.   The reason is in your logs.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Alex Regan
> > Mail appears to be completely ignoring the amavisd proxy despite
> > configuring default_transport to use 10025.
>
> The default_transport is a last-resort, it is preëmpted both by the
> transport table, and the address-class-specific transports.  It handles
> "other people's domains".  Mail for your own domains (local, virtual
> mailbox, relay, ...) uses local_transport, virtual_transport or
> relay_transport.  And all those are secondary to any transport(5)
> table you have configured.

I still don't understand the link between postfix and amavis. No mail
is delivered locally, except for system messages, so I don't need a
local_transport, right?

postfix-117:
mydestination =
local_recipient_maps =
local_transport = error:5.1.1 Mailbox unavailable
default_transport = smtp:[127.0.0.1]:10025
relay_transport = $default_transport
virtual_transport = $default_transport
transport_maps = ${indexed}transport
local_transport = error:5.1.1 Mailbox unavailable
transport_maps = ${indexed}transport
relay_domains = $mydestination, $transport_maps

/etc/postfix-117/transport:
mydomain.org                      smtp-amavis:[127.0.0.1]:10025

master.cf:
smtp-amavis unix    -       -       n       -       -   smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes

I'm really not sure what to do next. I've previously used
virtual_alias_maps with mydestination, but not virtual_transport. I'm
just unsure how all the pieces fit together. This is all based on
following the multi-instance doc as explicitly as possible, but I
think it leaves a lot to be desired in terms of how to produce a
functional system.

> > # mailq -C /etc/postfix-117
> > -Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
> > D9DE7200B23F3    2516 Tue Nov  3 20:34:30  [hidden email]
> > (lost connection with 127.0.0.1[127.0.0.1] while receiving the initial
> > server greeting)
> >                                          [hidden email]
>
> The downstream amavis or Postfix is not configured correctly and is
> dropping connections.   The reason is in your logs.

This also generates the following amavis error:
Nov  8 00:01:57 xavier amavis[812131]: (!)DENIED ACCESS from IP
209.216.11.117, policy bank ''

I've read that enabling smtp_bind_address=127.0.0.1 is necessary, but
that just creates a mail loop.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Viktor Dukhovni
On Sun, Nov 08, 2020 at 12:11:16PM -0500, Alex wrote:

> > The default_transport is a last-resort, it is preëmpted both by the
> > transport table, and the address-class-specific transports.  It handles
> > "other people's domains".  Mail for your own domains (local, virtual
> > mailbox, relay, ...) uses local_transport, virtual_transport or
> > relay_transport.  And all those are secondary to any transport(5)
> > table you have configured.
>
> I still don't understand the link between postfix and amavis.

Amavis is an SMTP server to which you can route mail for filtering.
That routing can happen via a content_filter (required in a single
instance configuration) or just making amavis the destination for all
mail in a multi-instance configuration.

            Unfiltered Mail --->  Amavis SMTP ---> Filtered Mail
    1-inst     smtpd A          content_filter       smtpd B
    2-inst     Postfix A      ditto or transport     Postfix B

> No mail
> is delivered locally, except for system messages, so I don't need a
> local_transport, right?
> postfix-117:
> mydestination =
> local_recipient_maps =
> local_transport = error:5.1.1 Mailbox unavailable

With "mydestination" empty, indeed you don't need to arrange
for local_transport to send mail via amavis, leaving it as
"error:" is fine.

> default_transport = smtp:[127.0.0.1]:10025
> relay_transport = $default_transport
> virtual_transport = $default_transport
> transport_maps = ${indexed}transport
> local_transport = error:5.1.1 Mailbox unavailable
> transport_maps = ${indexed}transport
> relay_domains = $mydestination, $transport_maps
>
> /etc/postfix-117/transport:
> mydomain.org                      smtp-amavis:[127.0.0.1]:10025

I don't recommend overloading the transport table as $relay_domains, but
with care to not forget that you're doing it, it can work.

> master.cf:
> smtp-amavis unix    -       -       n       -       -   smtp
>     -o smtp_data_done_timeout=1200
>     -o smtp_send_xforward_command=yes

OK, or you can just use "smtp" rather than "smtp-amavis", after all
all mail goes there, so there's no need for a custom transport with
master.cf overrides, just put the settings in main.cf and use "smtp".

> I'm really not sure what to do next. I've previously used
> virtual_alias_maps with mydestination, but not virtual_transport. I'm
> just unsure how all the pieces fit together. This is all based on
> following the multi-instance doc as explicitly as possible, but I
> think it leaves a lot to be desired in terms of how to produce a
> functional system.

I am perplexed by your struggles.  In a multi-instance system each
instance is an independent Postfix which takes mail in on some IP:port,
and delivers it to some IP:port (or at the end of the pipeline finally
to some storage location).  If there's any confusion, it is perhaps
that you're expecting more complexity than it is actually involved.

> > > -Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
> > > D9DE7200B23F3    2516 Tue Nov  3 20:34:30  [hidden email]
> > > (lost connection with 127.0.0.1[127.0.0.1] while receiving the initial
> > > server greeting)
> > >                                          [hidden email]

Well, that need that there's a problem connecting to that service,
connections are dropped without a 220 banner.  Either Amavis or
its downstream port are not up and running.  Fix that.

> > The downstream amavis or Postfix is not configured correctly and is
> > dropping connections.   The reason is in your logs.
>
> This also generates the following amavis error:
> Nov  8 00:01:57 xavier amavis[812131]: (!)DENIED ACCESS from IP
> 209.216.11.117, policy bank ''

Well, that's certainly an obstacle.

> I've read that enabling smtp_bind_address=127.0.0.1 is necessary, but
> that just creates a mail loop.

Setting smtp_bind_address cannot create a mail loop, but it can
make delivery possible, that exposes a looping configuration.
Don't configure loops in the forwarding pipeline.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Alex Regan
Hi,

> > I still don't understand the link between postfix and amavis.
>
> Amavis is an SMTP server to which you can route mail for filtering.
> That routing can happen via a content_filter (required in a single
> instance configuration) or just making amavis the destination for all
> mail in a multi-instance configuration.
>
>             Unfiltered Mail --->  Amavis SMTP ---> Filtered Mail
>     1-inst     smtpd A          content_filter       smtpd B
>     2-inst     Postfix A      ditto or transport     Postfix B

Okay, I've made some progress, but I'm still not understanding in
practical terms how to link postfix to amavisd. It works with
"content_filter = smtp-amavis:[127.0.0.1]:10024" but I'd like to try
and do it with transport maps, as we've discussed.

Despite the following, mail is just completely bypassed and delivered
directly to the final destination outlined in
/etc/postfix-117/transport. The multi-instance readme indicates
mydestination should be unset, but that results in a mail loop for
mail being reinjected, I believe.

I believe there's something (perhaps fundamental) I'm missing that I
need help to understand.

/etc/postfix-117/main.cf
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = xavier.mycompany.com
alias_maps =
alias_database =
local_recipient_maps =
local_transport = error:5.1.1 Mailbox unavailable
default_transport = smtp-amavis:[127.0.0.1]:10024
relay_transport = $default_transport
virtual_transport = $default_transport

transport_maps = ${indexed}transport
relay_domains = domain1.org, domain2.org

/etc/postfix-117/master.cf
smtp-amavis unix    -       -       n       -       -   smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes

127.0.0.1:10025 inet n    -       n       -      16     smtpd
    -o content_filter=
    -o smtpd_delay_reject=no
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o smtpd_restriction_classes=
    -o mynetworks=127.0.0.0/8,209.216.99.0/24
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
    -o local_header_rewrite_clients=

/etc/postfix-117/transport
domain1.org                      smtp:68.195.199.42
domain2.org                      smtp:68.195.199.42

Nov 10 14:32:44 xavier postfix-117/qmgr[1067650]: 2E78E200BD76D:
from=<[hidden email]>, size=2612, nrcpt=1 (queue active)
Nov 10 14:32:44 xavier postfix-117/smtpd[1067653]: disconnect from
mail-pg1-f169.google.com[209.85.215.169] ehlo=2 starttls=1 mail=1
rcpt=1 bdat=1 quit=1 commands=7
Nov 10 14:32:44 xavier postfix-117/smtp[1067662]: 2E78E200BD76D:
to=<[hidden email]>, relay=68.195.199.42[68.195.199.42]:2
5, delay=1.2, delays=0.51/0.01/0.48/0.15, dsn=2.0.0, status=sent (250
2.0.0 Ok: queued as D452A80A9FC6)
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Viktor Dukhovni
On Tue, Nov 10, 2020 at 03:04:24PM -0500, Alex wrote:

> > Amavis is an SMTP server to which you can route mail for filtering.
> > That routing can happen via a content_filter (required in a single
> > instance configuration) or just making amavis the destination for all
> > mail in a multi-instance configuration.
> >
> >             Unfiltered Mail --->  Amavis SMTP ---> Filtered Mail
> >     1-inst     smtpd A          content_filter       smtpd B
> >     2-inst     Postfix A      ditto or transport     Postfix B

One thing to keep in mind is that when forwarding mail from a machine to
itself, the destination port must not be port 25, or else loop detection
might kick in if either the IP address or the hostname in the nexthop
greeting or HELO response matches myhostname in the sender instance.  So
I'm assuming that you're not doing local SMTP forwarding to port 25.

> Okay, I've made some progress, but I'm still not understanding in
> practical terms how to link postfix to amavisd. It works with
> "content_filter = smtp-amavis:[127.0.0.1]:10024" but I'd like to try
> and do it with transport maps, as we've discussed.

This should work provided nothing causes the mail to take some other
route.  The routing logic is:

    1. Highest priority, any content_filter override.
    2. Next, the transport(5) table.
    3. Next, the address-class-specific transport, i.e.
       relay_tansport for relay_domains, local_transport for
       domains listed in mydestination, ...
    4. Next, default_transport possibly sender-dependent via
       sender_depedent_default_transport_maps.

In addition $relayhost is the default nexthop when the default
transport or relay_transport does not specify a nexthop.

> Despite the following, mail is just completely bypassed and delivered
> directly to the final destination outlined in
> /etc/postfix-117/transport.

See above, the transport table is the highest-precedence source
of truth after content_filter.

> The multi-instance readme indicates
> mydestination should be unset, but that results in a mail loop for
> mail being reinjected, I believe.

It should only be unset in instances that forward all mail, if the
last instance in the pipeline needs to do local(8) delivery, or
consult local aliases(5), then you need mydestination there.

> /etc/postfix-117/main.cf
> mydestination = $myhostname, localhost.$mydomain, localhost
> myhostname = xavier.mycompany.com
> alias_maps =
> alias_database =
> local_recipient_maps =
> local_transport = error:5.1.1 Mailbox unavailable

All mail to the domains listed in $mydestination will be rejected.
Is that what you want?

> default_transport = smtp-amavis:[127.0.0.1]:10024
> relay_transport = $default_transport
> virtual_transport = $default_transport
> relay_domains = domain1.org, domain2.org

The rest is punted to Amavis (after any virtual(5) rewriting, which
could perhaps result in some recipients matching $mydestionation, which
then bounce).

> transport_maps = ${indexed}transport

Why do you need a transport table?  Everything should go to
amavis...

> /etc/postfix-117/transport
> domain1.org                      smtp:68.195.199.42
> domain2.org                      smtp:68.195.199.42

These domains don't go to Amavis.

> Nov 10 14:32:44 xavier postfix-117/smtp[1067662]: 2E78E200BD76D:
> to=<[hidden email]>, relay=68.195.199.42[68.195.199.42]:2
> 5, delay=1.2, delays=0.51/0.01/0.48/0.15, dsn=2.0.0, status=sent (250
> 2.0.0 Ok: queued as D452A80A9FC6)

As expected.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Alex Regan
Hi,

I still have to read your email closely and experiment, but a few
clarification questions first.

> This should work provided nothing causes the mail to take some other
> route.  The routing logic is:
>
>     1. Highest priority, any content_filter override.
>     2. Next, the transport(5) table.
>     3. Next, the address-class-specific transport, i.e.
>        relay_tansport for relay_domains, local_transport for
>        domains listed in mydestination, ...
>     4. Next, default_transport possibly sender-dependent via
>        sender_depedent_default_transport_maps.

Where would virtual_maps or virtual_alias_domains be processed?

> In addition $relayhost is the default nexthop when the default
> transport or relay_transport does not specify a nexthop.
>
> > Despite the following, mail is just completely bypassed and delivered
> > directly to the final destination outlined in
> > /etc/postfix-117/transport.
>
> See above, the transport table is the highest-precedence source
> of truth after content_filter.

If I want to use the transport table to contain the list of domains
which should be processed through amavis, should I be able to disable
the content_filter and define the domains in the transport_map like:

domain1.org    smtp-amavis:[127.0.0.1]:10024

and expect it to work properly? Is that the proper way to do it,
assuming everything else (like mydestination, etc) is configured
properly?
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Alex Regan
Hi,

> > See above, the transport table is the highest-precedence source
> > of truth after content_filter.
>
> If I want to use the transport table to contain the list of domains
> which should be processed through amavis, should I be able to disable
> the content_filter and define the domains in the transport_map like:
>
> domain1.org    smtp-amavis:[127.0.0.1]:10024
>
> and expect it to work properly? Is that the proper way to do it,
> assuming everything else (like mydestination, etc) is configured
> properly?

Also, if the transport_map instructs postfix to send all mail for the
domain to port 10024, and amavisd then sends it back to 10025, how
does postfix then know to eventually forward it on to its final
destination after the email has been processed?
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Viktor Dukhovni
On Tue, Nov 10, 2020 at 06:05:02PM -0500, Alex wrote:

>
> > This should work provided nothing causes the mail to take some other
> > route.  The routing logic is:
> >
> >     1. Highest priority, any content_filter override.
> >     2. Next, the transport(5) table.
> >     3. Next, the address-class-specific transport, i.e.
> >        relay_tansport for relay_domains, local_transport for
> >        domains listed in mydestination, ...
> >     4. Next, default_transport possibly sender-dependent via
> >        sender_depedent_default_transport_maps.
>
> Where would virtual_maps or virtual_alias_domains be processed?

Recipient rewriting via virtual(5) happens early during message input in
cleanup(8).  By the time the message is being delivered any configured
and not disabled virtual(5) rewriting is complete.

The virtual_alias_domains parameter makes a domain "final", which allows
mail to these domains to not be rejected by "reject_unauth_destination".
If, for some reason, a recipient in one of these domains fails to be
rewritten to some real domain, that recipient will be routed to the
error(8) transport and will bounce.

The transport table does not override virtual_alias_domains, absent the
requisite rewrites they bounce regardless of any transport table
entries.

> > See above, the transport table is the highest-precedence source
> > of truth after content_filter.
>
> If I want to use the transport table to contain the list of domains
> which should be processed through amavis, should I be able to disable
> the content_filter and define the domains in the transport_map like:
>
> domain1.org    smtp-amavis:[127.0.0.1]:10024

I don't see why you'd want to do that, but you certainly can.
Typically, all recipients would be sent to the filter.

> and expect it to work properly? Is that the proper way to do it,
> assuming everything else (like mydestination, etc) is configured
> properly?

Typically, no transport table is used upstream of the filter,
and you just define default_transport, relay_transport and
virtual_transport.

On Tue, Nov 10, 2020 at 11:04:09PM -0500, Alex wrote:

> > and expect it to work properly? Is that the proper way to do it,
> > assuming everything else (like mydestination, etc) is configured
> > properly?
>
> Also, if the transport_map instructs postfix to send all mail for the
> domain to port 10024, and amavisd then sends it back to 10025, how
> does postfix then know to eventually forward it on to its final
> destination after the email has been processed?

You say "how does Postfix", as though there is just one Postfix, but you
have multiple Postfix instances, each configured to do its job.

Only the pre-filter Postfix instance sends mail into Amavis.  The
port 10025 smtpd(8) listen would be in the post-filter instance.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Alex Regan
Hi,

> > > This should work provided nothing causes the mail to take some other
> > > route.  The routing logic is:
> > >
> > >     1. Highest priority, any content_filter override.
> > >     2. Next, the transport(5) table.
> > >     3. Next, the address-class-specific transport, i.e.
> > >        relay_tansport for relay_domains, local_transport for
> > >        domains listed in mydestination, ...
> > >     4. Next, default_transport possibly sender-dependent via
> > >        sender_depedent_default_transport_maps.
> >
> > Where would virtual_maps or virtual_alias_domains be processed?
>
> Recipient rewriting via virtual(5) happens early during message input in
> cleanup(8).  By the time the message is being delivered any configured
> and not disabled virtual(5) rewriting is complete.
>
> The virtual_alias_domains parameter makes a domain "final", which allows
> mail to these domains to not be rejected by "reject_unauth_destination".
> If, for some reason, a recipient in one of these domains fails to be
> rewritten to some real domain, that recipient will be routed to the
> error(8) transport and will bounce.

I believe I finally got it working properly - thank you for your
tremendous help. I would really appreciate it if I can ask you to
review what I've done. Hopefully this will help someone else
configuring postfix multi-instance to build a mail relay - there is
definitely a shortage of modern documentation beyond the
multi-instance readme to follow.

I think much of my confusion was trying to figure out what processing
should be done in which instance using just the shell provided in the
multi-instance readme.

postfix-out:
- Why isn't $mynetworks needed when smtpd_recipient_restrictions
relies on it to determine which mail to accept?
- Under what conditions would I populate both relay_domains and transport_maps?

> The transport table does not override virtual_alias_domains, absent the
> requisite rewrites they bounce regardless of any transport table
> entries.

I think one of the biggest mistakes I made was thinking "transport
table" referred to the transport maps, not the transport in terms of
the method used to transport the data using a socket to another
process. I've now configured the $default_transport to be used for
everything and let amavis figure out whether it should be scanned.

> > Also, if the transport_map instructs postfix to send all mail for the
> > domain to port 10024, and amavisd then sends it back to 10025, how
> > does postfix then know to eventually forward it on to its final
> > destination after the email has been processed?
>
> You say "how does Postfix", as though there is just one Postfix, but you
> have multiple Postfix instances, each configured to do its job.

Yes, and my difficulty was determining which instance should be doing
which job. Another major hurdle for me was determining which settings
from the multi-instance readme needed to be edited from the default
based on how I was using it.

I'm hoping I can ask you to review the (edited) output from "postconf
-n" for my postfix-in (postfix-117) and postfix-out. I've put some of
my legacy stuff back in but will go through each check_client_access,
for example, and make sure it's needed.

/etc/postfix-117/main.cf
alias_database =
alias_maps =
always_bcc = bcc-user
authorized_submit_users = root
body_checks = regexp:$config_directory/body_checks.pcre
bounce_queue_lifetime = 2d
compatibility_level = 2
debug_peer_level = 2
default_database_type = cdb
default_process_limit = 100
default_transport = smtp:[127.0.0.1]:10024
delay_warning_time = 4d
header_checks = pcre:$config_directory/header_checks.pcre
pcre:$config_directory/header_checks-jimsun.pcre
indexed = ${default_database_type}:${config_directory}/
inet_protocols = ipv4
initial_destination_concurrency = 20
local_header_rewrite_clients =
local_recipient_maps =
local_transport = error:5.1.1 Mailbox unavailable
mail_owner = postfix
mailbox_size_limit = 2000000000
master_service_disable =
maximal_queue_lifetime = 3d
message_size_limit = 29312000
meta_directory = /etc/postfix
mime_header_checks = pcre:$config_directory/mime_header_checks
multi_instance_enable = yes
multi_instance_group = mta
multi_instance_name = postfix-117
queue_directory = /var/spool/postfix-117
inet_interfaces = 209.216.99.117
config_directory = /etc/postfix-117

mydestination =
mynetworks = 127.0.0.0/8, 209.216.99.0/24
policy-spf_time_limit = 3600s

postscreen_access_list = permit_mynetworks,
cidr:$config_directory/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map =
pcre:$config_directory/postscreen_dnsbl_reply_map.pcre

postscreen_dnsbl_sites =
        score.senderscore.com=127.0.4.[0..19]*5
        score.senderscore.com=127.0.4.[20..29]*4
        score.senderscore.com=127.0.4.[30..49]*3
        score.senderscore.com=127.0.4.[50..59]*2
        score.senderscore.com=127.0.4.[60..69]*1
        score.senderscore.com=127.0.4.[70..79]*-1
          ...

postscreen_dnsbl_threshold = 8
postscreen_greet_action = enforce
postscreen_whitelist_interfaces = static:all 209.216.94.0/24
relay_transport = $default_transport
transport_maps =
unknown_local_recipient_reject_code = 550
virtual_transport = $default_transport
relay_domains = mycompany.com,  $mydestination

smtp_data_done_timeout = 1200s
smtp_destination_recipient_limit = 1000
smtp_send_xforward_command = yes
smtp_tls_CAfile = /etc/letsencrypt/chain.pem
smtp_tls_security_level = may
smtp_use_tls = yes
smtpd_client_port_logging = no

smtpd_client_restrictions =
        permit_mynetworks,
        check_client_access ${indexed}client_checks,
        check_reverse_client_hostname_access
pcre:$config_directory/fqrdns-042715a.pcre,
        check_reverse_client_hostname_access
pcre:$config_directory/reverse_client_hostname_access.pcre,
        check_client_access cidr:$config_directory/client_access_blocklist

smtpd_helo_restrictions = permit_mynetworks check_helo_access
${indexed}helo_checks
check_helo_access pcre:$config_directory/helo_checks.pcre permit

smtpd_recipient_restrictions =
        reject_non_fqdn_recipient,
        reject_non_fqdn_sender,
        reject_unlisted_recipient,
        reject_unknown_recipient_domain,
        permit_mynetworks,
        reject_unauth_destination,
        reject_rhsbl_sender uri.mykey.invaluement.com,
        check_sender_access ${indexed}check_backscatterer,
        check_helo_access pcre:$config_directory/helo_checks.pcre,
        check_helo_access ${indexed}helo_checks,
        reject_non_fqdn_helo_hostname,
        reject_invalid_helo_hostname,
        check_policy_service unix:private/policy-spf,
        check_policy_service inet:127.0.0.1:2501,
        check_recipient_access pcre:$config_directory/relay_recips_access,
        permit

smtpd_sender_restrictions =
        permit_mynetworks,
        check_sender_access ${indexed}sender_checks,
        check_sender_access pcre:$config_directory/sender_checks.pcre,
        check_sender_access ${indexed}spamsources,
        check_sender_ns_access ${indexed}/blacklist_ns.cf,
        reject_unknown_sender_domain

smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/privkey.pem
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database =
btree:/var/lib/postfix/smtpd_tls_session_cache
tls_random_source = dev:/dev/urandom

/etc/postfix-out/main.cf:
alias_database =
alias_maps =
authorized_submit_users = root
command_directory = /usr/sbin
compatibility_level = 2
config_directory = /etc/postfix-out
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix-out
debug_peer_level = 2
default_database_type = cdb
indexed = ${default_database_type}:${config_directory}/

inet_interfaces = 127.0.0.1
inet_protocols = ipv4
local_header_rewrite_clients =
local_recipient_maps =
local_transport = error:5.1.1 Mailbox unavailable
transport_maps = ${indexed}transport
master_service_disable =
meta_directory = /etc/postfix
milter_default_action = accept
multi_instance_enable = yes
multi_instance_group = mta
multi_instance_name = postfix-out

mydestination =
mynetworks_style = host
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = $smtpd_milters
parent_domain_matches_subdomains =
queue_directory = /var/spool/postfix-out
recipient_delimiter = +

smtp_tls_CAfile = /etc/letsencrypt/chain.pem
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
smtpd_tls_security_level = may

smtpd_authorized_xforward_hosts = $mynetworks
smtpd_client_connection_count_limit = 0
smtpd_client_event_limit_exceptions = $mynetworks
smtpd_client_port_logging = no

smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893

smtpd_recipient_restrictions = permit_mynetworks, reject

smtpd_relay_restrictions =

smtpd_timeout = 1200s
unknown_local_recipient_reject_code = 550

/etc/postfix-out/transport:
mycompany.com    smtp:relayhost.com

/etc/postfix-out/master.cf:
127.0.0.1:10025 inet n    -       n       -       16     smtpd
    -o content_filter=
    -o smtpd_delay_reject=no
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o smtpd_restriction_classes=
    -o mynetworks=127.0.0.0/8,209.216.99.0/24
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
    -o local_header_rewrite_clients=
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Viktor Dukhovni
On Wed, Nov 11, 2020 at 10:57:12PM -0500, Alex wrote:

> /etc/postfix-117/main.cf

Input instance.

> default_process_limit = 100

I'd go higher, inbound connections are cheap.

> delay_warning_time = 4d

If this is inbound mail from outside, I generally don't enable delay
warnings back outside senders.

> maximal_queue_lifetime = 3d

Because all mail is destined for the filter, and should never fail to
get through, I actually set this higher (100 days is the maximum allowed
IIRC), and monitor that the limit is never reached.

> mynetworks = 127.0.0.0/8, 209.216.99.0/24

Is this handling inbound or outbound mail?  If inbound,
why is mynetworks not just 127.0.0.0/8?  If both, why
not separate instances for inbound/outbound?

> relay_transport = $default_transport
> relay_domains = mycompany.com,  $mydestination

Fine, but I don't see a "relay_recipient_maps" for recipient validation,
which is quite important to avoid backscatter.

> smtp_tls_CAfile = /etc/letsencrypt/chain.pem
> smtp_use_tls = yes
> smtp_tls_security_level = may

There's no need to enable TLS for an internal hop via Amavis, and
"smtp_use_tls" is obsolete.  Just 'smtp_tls_security_level = none'.

> smtpd_tls_auth_only = yes

Generally not needed for inbound mail.

> smtpd_tls_session_cache_database =
>   btree:/var/lib/postfix/smtpd_tls_session_cache

Session tickets make this mostly unnecessary.

> /etc/postfix-out/main.cf:
>
> recipient_delimiter = +

Once you're doing recipient validation, you'll generally also want this
on the input side.

> smtp_tls_CAfile = /etc/letsencrypt/chain.pem

You probably don't need this, I saw no hint that you're using "verify"
or "secure" for any onward SMTP deliveries.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Understanding multi-instance transport tables

Alex Regan
Hi,

> > relay_transport = $default_transport
> > relay_domains = mycompany.com,  $mydestination
>
> Fine, but I don't see a "relay_recipient_maps" for recipient validation,
> which is quite important to avoid backscatter.

I think I'm achieving this with check_recipient_access in
smtpd_recipient_restrictions?

smtpd_recipient_restrictions =
        reject_non_fqdn_recipient,
        reject_non_fqdn_sender,
        reject_unlisted_recipient,
        reject_unknown_recipient_domain,
        permit_mynetworks,
        reject_unauth_destination,
        reject_rhsbl_sender uri.mykey.invaluement.com,
        check_sender_access ${indexed}check_backscatterer,
        check_helo_access pcre:$config_directory/helo_checks.pcre,
        check_helo_access ${indexed}helo_checks,
        reject_non_fqdn_helo_hostname,
        reject_invalid_helo_hostname,
        check_policy_service unix:private/policy-spf,
        check_policy_service inet:127.0.0.1:2501,
        check_recipient_access pcre:$config_directory/relay_recips_access,
        check_recipient_access pcre:$config_directory/recipient_checks,
        permit

I also have the check_sender_access above:

/etc/postfix-117/check_backscatterer:
<> reject_rbl_client ips.backscatterer.org
postmaster reject_rbl_client ips.backscatterer.org

/etc/postfix-117/relay_recips_access:
/^alex@mycompany\.com$/    DUNNO
/^.*@mycompany\.com$/   REJECT