inet_interfaces and domain names

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

inet_interfaces and domain names

Alex Regan
Hi,

I'm using postfix-3.5.7 on fedora32 on a server with four IP addresses
(mail1, mail2, etc) on one interface. The problem is that all mail
goes out the IP associated with the actual interface, not the virtual
ones, which I believe is causing SPF to fail.

Is this a Linux problem?

Would I have to have multiple instances of postfix running to be able
to control which IP is used for which domain?
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces and domain names

Wietse Venema
Alex:
> Hi,
>
> I'm using postfix-3.5.7 on fedora32 on a server with four IP addresses
> (mail1, mail2, etc) on one interface. The problem is that all mail
> goes out the IP associated with the actual interface, not the virtual
> ones, which I believe is causing SPF to fail.
>
> Is this a Linux problem?

No, this is a configuration problem.

> Would I have to have multiple instances of postfix running to be able
> to control which IP is used for which domain?

Give each instance its owninet_inteerfaces setting.

This is covered in
http://www.postfix.org/BASIC_CONFIGURATION_READNE.html

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces and domain names

Alex Regan
Hi,

> > Would I have to have multiple instances of postfix running to be able
> > to control which IP is used for which domain?
>
> Give each instance its owninet_inteerfaces setting.
>
> This is covered in
> http://www.postfix.org/BASIC_CONFIGURATION_READNE.html

Is there a document that provides a bit more explanation as to how
this would work? Should I also be reading MULTI_INSTANCE?

Or does it involve modifying master.cf and the SMTP server definitions?

domain1  unix -       -       n       -       -       smtp
          -o syslog_name=postfix-domain1
          -o smtp_helo_name=domainone.com
          -o smtp_bind_address=192.168.1.1

I see in the BASIC_CONFIG doc I can define inet_interfaces like:

inet_interfaces = virtual.host.tld

but I don't understand how to do it for multiple interfaces or how to
do it for multiple interfaces, each with their own hostname.
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces and domain names

Viktor Dukhovni
On Wed, Oct 28, 2020 at 08:45:30PM -0400, Alex wrote:

> > > Would I have to have multiple instances of postfix running to be able
> > > to control which IP is used for which domain?
> >
> > Give each instance its owninet_inteerfaces setting.
> >
> > This is covered in
> > http://www.postfix.org/BASIC_CONFIGURATION_READNE.html
>
> Is there a document that provides a bit more explanation as to how
> this would work? Should I also be reading MULTI_INSTANCE?

If you want to logically partition your MTA into separate personalities
by domain, rather than operate a single MTA multiple domains (why?),
then multi-instance is the more robust approach when you have a separate
dedicated IP address for each domain for both inbound and outbound mail.

Within a single instance, Partitioning inbound email is of course
comparatively simple, but partitioning outbound email, including bounces
is not.

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

Re: inet_interfaces and domain names

Alex Regan
Hi,

> > > > Would I have to have multiple instances of postfix running to be able
> > > > to control which IP is used for which domain?
> > >
> > > Give each instance its owninet_inteerfaces setting.
> > >
> > > This is covered in
> > > http://www.postfix.org/BASIC_CONFIGURATION_READNE.html
> >
> > Is there a document that provides a bit more explanation as to how
> > this would work? Should I also be reading MULTI_INSTANCE?
>
> If you want to logically partition your MTA into separate personalities
> by domain, rather than operate a single MTA multiple domains (why?),
> then multi-instance is the more robust approach when you have a separate
> dedicated IP address for each domain for both inbound and outbound mail.

I definitely do not want to have to implement multiple instances. I
did it more than 15 years ago and it's certainly an involved process.

> Within a single instance, Partitioning inbound email is of course
> comparatively simple, but partitioning outbound email, including bounces
> is not.

Would you explain how I can bind a hostname to an IP and send mail for
a specific domain using that IP?
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces and domain names

Wietse Venema
In reply to this post by Alex Regan
Alex:

> Hi,
>
> > > Would I have to have multiple instances of postfix running to be able
> > > to control which IP is used for which domain?
> >
> > Give each instance its owninet_inteerfaces setting.
> >
> > This is covered in
> > http://www.postfix.org/BASIC_CONFIGURATION_READNE.html
>
> Is there a document that provides a bit more explanation as to how
> this would work? Should I also be reading MULTI_INSTANCE?

Yes. If you weant to separate outbound mail streams, use multiple
instances with:

http://www.postfix.org/BASIC_CONFIGURATION_README.html#myhostname
http://www.postfix.org/BASIC_CONFIGURATION_README.html#mydomain
http://www.postfix.org/BASIC_CONFIGURATION_README.html#inet_interfaces

Or use a partial and more complex solution like below.

        Wietse

/etc/postfix/main.cf
    # Do "postmap hash:/etc/postfix/sender_transport" after editing the file.
    sender_dependent_default_transport_maps =
        hash:/etc/postfix/sender_transport

/etc/postfix/sender_transport
    @one.example        smtp_one_example:
    @two.example        smtp_two_example:
    # How shall bounces be delivered?
    <>                  ???
    ...

- Each delivery transport needs its own smtp_bind_address and smtp_helo_name.

- Each smtp_helo_name value needs a DNS A (or AAAA) record that
  resolves to the corresponding smtp_bind_address value.

- Each IP address needs a PTR record that resolves to the smtp_helo_name
  value.

/etc/postfix/master.cf
    smtp_one_example .. .. .. .. .. .. smtp
        # Add smtp_bind_address6 as needed
        -o smtp_bind_address=address-for-one
        -o smtp_helo_name=helo-for-one
    smtp_two_example .. .. .. .. .. .. smtp
        -o smtp_bind_address=address-for-two
        -o smtp_helo_name=helo-for-two  
    ...

Additionally, you may need to reduce process limits in master.cf,
or have smtp_one_example_destination_concurrency_limit etc. settings
in main.cf.
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces and domain names

Wietse Venema
In reply to this post by Alex Regan
Alex:

> Hi,
>
> > > > > Would I have to have multiple instances of postfix running to be able
> > > > > to control which IP is used for which domain?
> > > >
> > > > Give each instance its owninet_inteerfaces setting.
> > > >
> > > > This is covered in
> > > > http://www.postfix.org/BASIC_CONFIGURATION_READNE.html
> > >
> > > Is there a document that provides a bit more explanation as to how
> > > this would work? Should I also be reading MULTI_INSTANCE?
> >
> > If you want to logically partition your MTA into separate personalities
> > by domain, rather than operate a single MTA multiple domains (why?),
> > then multi-instance is the more robust approach when you have a separate
> > dedicated IP address for each domain for both inbound and outbound mail.
>
> I definitely do not want to have to implement multiple instances. I
> did it more than 15 years ago and it's certainly an involved process.

Postfix has improved over time. Multiple instances are much easier now.
You can start/stop all or some, and they share executables.

> > Within a single instance, Partitioning inbound email is of course
> > comparatively simple, but partitioning outbound email, including bounces
> > is not.
>
> Would you explain how I can bind a hostname to an IP and send mail for
> a specific domain using that IP?

See my other response. It is more complicated than multi-instance.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces and domain names

Alex Regan
In reply to this post by Wietse Venema
Hi,

> > > > Would I have to have multiple instances of postfix running to be able
> > > > to control which IP is used for which domain?
> > >
> > > Give each instance its owninet_inteerfaces setting.
> > >
> > > This is covered in
> > > http://www.postfix.org/BASIC_CONFIGURATION_READNE.html
> >
> > Is there a document that provides a bit more explanation as to how
> > this would work? Should I also be reading MULTI_INSTANCE?
>
> Yes. If you weant to separate outbound mail streams, use multiple
> instances with:
>
> http://www.postfix.org/BASIC_CONFIGURATION_README.html#myhostname
> http://www.postfix.org/BASIC_CONFIGURATION_README.html#mydomain
> http://www.postfix.org/BASIC_CONFIGURATION_README.html#inet_interfaces

Okay, after some reading and hair pulling, I decided to give it a
shot, and made some progress. A few questions, please.

After going through the MULTI_INSTANCE_README and restarting postfix,
it's still only listening on loopback (ipv4 only). I've also
configured "smtp_bind_address = 0.0.0.0" in postfix-out. I also
configured "inet_interfaces = all" in postfix-in and it still is only
listening on loopback.

# netstat -ntap|grep LISTEN|grep master
tcp        0      0 127.0.0.1:25            0.0.0.0:*
LISTEN      401001/master

Is there a diagram that shows the flow of data from the internet
through to the first instance, content filter, then out?

I have an existing system that uses amavisd, clamav and spamassassin
using "content_filter = smtp-amavis:[127.0.0.1]:10024". Just to be
sure, this (along with my postscreen and smtpd_recipient_restrictions)
goes in postfix-in, correct? Is that the reference to the proxy
filters around the middle of the page? Or is this talking about
creating another instance?

I don't understand what this from the MULTI_INSTANCE doc is for. Under
what circumstances do I need this? Should this instead be the
smtp-amavis service from my master.cf? Should I be able to drop in my
existing master.cf to use in postfix-in? While my content filter on
10024 appears to be active, 10025 is also seemingly being ignored.
/etc/postfix-out/master.cf:
    # Replace default "smtp inet" entry with one listening on port 10026.
    127.0.0.1:10026     inet  n       -       n       -       -       smtpd

My master.cf:
smtp-amavis unix    -       -       n       -       2   smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes
    -o max_use=20

127.0.0.1:10025 inet n    -       n       -       2     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
    -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,no_milters
    -o local_header_rewrite_clients=

# netstat -ntap|grep LISTEN|grep 127.0.0.1
tcp        0      0 127.0.0.1:2501          0.0.0.0:*
LISTEN      180694/perl
tcp        0      0 127.0.0.1:10024         0.0.0.0:*
LISTEN      384178/amavisd (mas
tcp        0      0 127.0.0.1:4330          0.0.0.0:*
LISTEN      1579/pmlogger
tcp        0      0 127.0.0.1:3310          0.0.0.0:*
LISTEN      45282/clamd
tcp        0      0 127.0.0.1:53            0.0.0.0:*
LISTEN      317759/named
tcp        0      0 127.0.0.1:25            0.0.0.0:*
LISTEN      402097/master
tcp        0      0 127.0.0.1:953           0.0.0.0:*
LISTEN      317759/named
tcp        0      0 127.0.0.1:8891          0.0.0.0:*
LISTEN      44525/opendkim
tcp        0      0 127.0.0.1:8893          0.0.0.0:*
LISTEN      44544/opendmarc
tcp        0      0 127.0.0.1:44321         0.0.0.0:*
LISTEN      973/pmcd
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces and domain names

Viktor Dukhovni
On Thu, Oct 29, 2020 at 10:31:12PM -0400, Alex wrote:

> > Yes. If you weant to separate outbound mail streams, use multiple
> > instances with:
> >
> > http://www.postfix.org/BASIC_CONFIGURATION_README.html#myhostname
> > http://www.postfix.org/BASIC_CONFIGURATION_README.html#mydomain
> > http://www.postfix.org/BASIC_CONFIGURATION_README.html#inet_interfaces
>
> Okay, after some reading and hair pulling, I decided to give it a
> shot, and made some progress. A few questions, please.

It would be useful to post the outpuf of "postmulti -l" so we know what
you're talking about.  And then the output of:

    # for i in $(postmulti -l | awk '$3 == "y" {print $1}')
      do
        postmulti -i $i -x postconf multi_instance_name inet_interfaces master_service_disable
      done

which will show the inet_interfaces and disabled services for each
enabled instance.

> # netstat -ntap|grep LISTEN|grep master
> tcp        0      0 127.0.0.1:25            0.0.0.0:* LISTEN      401001/master

That'd be either inet_interfaces, or an explicit master.cf entry.

> Is there a diagram that shows the flow of data from the internet
> through to the first instance, content filter, then out?

You've just described it.  Can you ask a more specific question?
Each Postfix instance behaves like a full-blown independent MTA,
they just happen to run on the same machine.  You can forward
traffic between them via SMTP.

For any given IP address and TCP port, at most one Postfix instance can
listen on that IP and port, and if the port is used with a wildcard
listener, then that generally precludes using it with specific IPs.

> I have an existing system that uses amavisd, clamav and spamassassin
> using "content_filter = smtp-amavis:[127.0.0.1]:10024". Just to be
> sure, this (along with my postscreen and smtpd_recipient_restrictions)
> goes in postfix-in, correct?

With multiple instances one you don't actually need a "content_filter",
you can instead arrange for the transport table and/or local_transport,
virtual_transport, relay_transport, default_transport (whichever are
applicable) to hand mail off to the filter port.  But you can continue
to use content_filter if you like.

You still need smtpd_relay_restrictions on the "out" instance, typically
just allowing 127.0.0.1 and nothing else.  All the other restrictions
can be empty.

> I don't understand what this from the MULTI_INSTANCE doc is for. Under
> what circumstances do I need this? Should this instead be the
> smtp-amavis service from my master.cf? Should I be able to drop in my
> existing master.cf to use in postfix-in?

Pretend you have 3 separate machines, one running "postfix-in", a
second running amavis, and a third running "postfix-out".  Just
arrange to pass mail through all three in the right sequence.

The only thing different with multiple instances is that all three
are on the same OS instance, and some of the input and output IPs
are loopback addresses.

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

Post-amavis mail would typically be received by postfix-out.

> My master.cf:
> smtp-amavis unix    -       -       n       -       2   smtp
>     -o smtp_data_done_timeout=1200
>     -o smtp_send_xforward_command=yes
>     -o disable_dns_lookups=yes
>     -o max_use=20

The "disable_dns_lookups" thing is long obsolete, and "max_use=20" is
unnecessary.  With multiple instances, this can just be the "smtp"
transport of the "postfix-in" instance.  It punts *everything* to
amavis.

> 127.0.0.1:10025 inet n    -       n       -       2     smtpd
>     -o content_filter=
>     ...
>     -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
>     -o local_header_rewrite_clients=

This goes in "postfix-out" and instead of all the overrides, just apply
the settings in main.cf instead.  And you don't need "no_milters", just
don't define any milters you don't need.  Again think three separate
machines, each configured for the task at hand.  Your current
configuration is mostly distraction, start clean.

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

Re: inet_interfaces and domain names

Alex Regan
> > Okay, after some reading and hair pulling, I decided to give it a
> > shot, and made some progress. A few questions, please.
>
> It would be useful to post the outpuf of "postmulti -l" so we know what
> you're talking about.  And then the output of:
>
>     # for i in $(postmulti -l | awk '$3 == "y" {print $1}')
>       do
>         postmulti -i $i -x postconf multi_instance_name inet_interfaces master_service_disable
>       done
>
> which will show the inet_interfaces and disabled services for each
> enabled instance.

I do believe I have made some progress after reading your comments and
working on it further. It's now listening on an external interface
because I believe I adjusted the $default_transport.

# postmulti -l
-               -               y         /etc/postfix
postfix-out     mta             y         /etc/postfix-out
postfix-in      mta             y         /etc/postfix-in

# for i in $(postmulti -l | awk '$3 == "y" {print $1}') ; do postmulti
-i $i -x postconf multi_instance_name inet_interfaces
master_service_disable; done
multi_instance_name =
inet_interfaces = localhost
master_service_disable = inet
multi_instance_name = postfix-out
inet_interfaces = localhost
master_service_disable =
multi_instance_name = postfix-in
inet_interfaces = 209.216.11.114
master_service_disable =

> > Is there a diagram that shows the flow of data from the internet
> > through to the first instance, content filter, then out?
>
> You've just described it.  Can you ask a more specific question?
> Each Postfix instance behaves like a full-blown independent MTA,
> they just happen to run on the same machine.  You can forward
> traffic between them via SMTP.

I should have added to just ask if that assumption was correct.

I may be unclear on the purpose of each. I would have assumed mail
would come in on postfix-in, filtered there, then sent out
postfix-out, but I'm a bit confused after reading some of your
comments below.

I think I'm still unclear about the "Setting up the content-filter
proxy" section - I'm assuming that means amavis in my case. Is this
configured in postfix-in or postfix-out? I interpreted the doc to mean
my amavis/clam/SA processing is done in postfix-out, but your comments
seem to indicate it should be done in postfix-in.

There's also no reference to any changes being necessary to be made in
master.cf for the postfix-in instance. Is that where I should be
incorporating the master.cf changes from my existing one-instance
postfix?

> For any given IP address and TCP port, at most one Postfix instance can
> listen on that IP and port, and if the port is used with a wildcard
> listener, then that generally precludes using it with specific IPs.

Okay, I think I understand. Certainly I understand that only one
process can listen on one port at a time.

> > I have an existing system that uses amavisd, clamav and spamassassin
> > using "content_filter = smtp-amavis:[127.0.0.1]:10024". Just to be
> > sure, this (along with my postscreen and smtpd_recipient_restrictions)
> > goes in postfix-in, correct?
>
> With multiple instances one you don't actually need a "content_filter",
> you can instead arrange for the transport table and/or local_transport,
> virtual_transport, relay_transport, default_transport (whichever are
> applicable) to hand mail off to the filter port.  But you can continue
> to use content_filter if you like.

I currently have a transport map set up in the form:

domain.com     smtp:1.2.3.4
.domain.com    smtp:1.2.3.4

(as a side-note, should it be "smtp:[1.2.3.4]" or is that just to
prevent DNS lookups, I think?)

This would be defined as:
transport_maps = hash:/etc/postfix/transport

There is no local delivery in this case, so I would think no
local_transport - any local delivery is handled by the null instance,
right?

I also have a virtual map set up as:
virtual_alias_maps = hash:/etc/postfix/virtual,
hash:/etc/postfix/virtual-segtravel

Would you also confirm where I should be putting my postscreen,
smtpd_helo_restrictions and smtpd_recipient_restrictions? Also in
postfix-out?

> > I don't understand what this from the MULTI_INSTANCE doc is for. Under
> > what circumstances do I need this? Should this instead be the
> > smtp-amavis service from my master.cf? Should I be able to drop in my
> > existing master.cf to use in postfix-in?
>
> Pretend you have 3 separate machines, one running "postfix-in", a
> second running amavis, and a third running "postfix-out".  Just
> arrange to pass mail through all three in the right sequence.

I thought the third instance included the null instance documented at
the top of the doc. I'm confused :-(

> >     # Replace default "smtp inet" entry with one listening on port 10026.
> >     127.0.0.1:10026     inet  n       -       n       -       -       smtpd
>
> Post-amavis mail would typically be received by postfix-out.

That makes sense and is currently set up in that way.
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces and domain names

Alex Regan
In reply to this post by Viktor Dukhovni
Hi,

I'm continuing to make progress on configuring multiple instances, but
have a few questions.

> > I have an existing system that uses amavisd, clamav and spamassassin
> > using "content_filter = smtp-amavis:[127.0.0.1]:10024". Just to be
> > sure, this (along with my postscreen and smtpd_recipient_restrictions)
> > goes in postfix-in, correct?
>
> With multiple instances one you don't actually need a "content_filter",
> you can instead arrange for the transport table and/or local_transport,
> virtual_transport, relay_transport, default_transport (whichever are
> applicable) to hand mail off to the filter port.  But you can continue
> to use content_filter if you like.

I have done this with transport maps:

mycompany.com       smtp:68.195.191.42
.mycompany.com      smtp:68.195.191.42

> You still need smtpd_relay_restrictions on the "out" instance, typically
> just allowing 127.0.0.1 and nothing else.  All the other restrictions
> can be empty.

I've done this, but have a weird reject that I don't understand.

Nov  3 12:17:16 xavier postfix-114/qmgr[577320]: B22FE200A4D83:
from=<>, size=4098, nrcpt=1 (queue active)
Nov  3 12:17:16 xavier postfix-out/smtpd[578804]: connect from
xavier.mycompany.com[209.216.11.114]
Nov  3 12:17:16 xavier postfix-out/smtpd[578804]: NOQUEUE: reject:
CONNECT from xavier.mycompany.com[209.216.11.114]: 554 5.7.1
<xavier.mycompany.com[209.216.11.114]>: Client host rejected: Access
denied; proto=SMTP
Nov  3 12:17:16 xavier postfix-114/smtp[578803]: B22FE200A4D83:
to=<[hidden email]>, relay=127.0.0.1[127.0.0.1]:10025, delay=946,
delays=946/0.02/0.01/0, dsn=4.7.1, status=deferred (host
127.0.0.1[127.0.0.1] refused to talk to me: 554 5.7.1
<xavier.mycompany.com[209.216.11.114]>: Client host rejected: Access
denied)

# 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

mynetworks = 209.216.11.0/24, 127.0.0.0/8, 209.216.12.0/24
newaliases_path = /usr/bin/newaliases.postfix
parent_domain_matches_subdomains =
queue_directory = /var/spool/postfix-out
readme_directory = /usr/share/doc/postfix-out/README_FILES
recipient_delimiter = +
sample_directory = /usr/share/doc/postfix-out/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix
smtp_bind_address = 0.0.0.0
smtp_tls_CAfile = /etc/letsencrypt/chain.pem
smtp_tls_CApath = /etc/letsencrypt
smtp_tls_security_level = may
smtpd_client_connection_count_limit = 0
smtpd_client_event_limit_exceptions = $mynetworks
smtpd_client_port_logging = no
smtpd_relay_restrictions = 127.0.0.1
smtpd_timeout = 1200s
smtpd_tls_cert_file = /etc/letsencrypt/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/privkey.pem
smtpd_tls_security_level = may

> > 127.0.0.1:10025 inet n    -       n       -       2     smtpd
> >     -o content_filter=
> >     ...
> >     -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
> >     -o local_header_rewrite_clients=
>
> This goes in "postfix-out" and instead of all the overrides, just apply
> the settings in main.cf instead.  And you don't need "no_milters", just
> don't define any milters you don't need.  Again think three separate
> machines, each configured for the task at hand.  Your current
> configuration is mostly distraction, start clean.

The FILTER_README still provides instructions for doing it as above.
How can I add these settings to main.cf instead?

Thanks,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces and domain names

Wietse Venema
Alex:
> Nov  3 12:17:16 xavier postfix-out/smtpd[578804]: NOQUEUE: reject:
> CONNECT from xavier.mycompany.com[209.216.11.114]: 554 5.7.1
> <xavier.mycompany.com[209.216.11.114]>: Client host rejected: Access
> denied; proto=SMTP

Look for smtpd_client_restrictions or check_client_access in main.cf,
master.cf, or in access tables of all Postfix instances.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces and domain names

Alex Regan
In reply to this post by Viktor Dukhovni
Hi,

> You've just described it.  Can you ask a more specific question?
> Each Postfix instance behaves like a full-blown independent MTA,
> they just happen to run on the same machine.  You can forward
> traffic between them via SMTP.
>
> For any given IP address and TCP port, at most one Postfix instance can
> listen on that IP and port, and if the port is used with a wildcard
> listener, then that generally precludes using it with specific IPs.
>
> > I have an existing system that uses amavisd, clamav and spamassassin
> > using "content_filter = smtp-amavis:[127.0.0.1]:10024". Just to be
> > sure, this (along with my postscreen and smtpd_recipient_restrictions)
> > goes in postfix-in, correct?
>
> With multiple instances one you don't actually need a "content_filter",
> you can instead arrange for the transport table and/or local_transport,
> virtual_transport, relay_transport, default_transport (whichever are
> applicable) to hand mail off to the filter port.  But you can continue
> to use content_filter if you like.

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

What am I missing? I don't know what more info I can provide to
troubleshoot this.