Re: setting up postscreen on a system with multiple external interfaces
Expand Messages
- On 2/21/2013 10:46 AM, Erik Slagter wrote:
> Another variation I tried ("pass" and "postscreen" the other wayYou've shared too much. By now no one has any idea what you're doing.
> around).
Overview:
Postscreen is a front-end listener for smtpd. It's not a proxy.
Incoming connections are handled by postscreen until postscreen
either decides it's clean and passes the connection endpoint to
smtpd, or rejected. This is covered in more detail in the
POSTSCREEN_README.
When postscreen decides to pass the connection to smtpd, postscreen
is no longer involved, and smtpd has no knowledge of what transpired
between postscreen and a client.
Solution:
[this is not a complete how-to, but will show you how to use
multiple interfaces]
At some point you reported:
> mx1.ipv4.slagter.name:smtp inet n - n - 2 smtpdOk.
> -o myhostname=eriks.xs4all.nl
> -o smtpd_banner=mx1.slagter.name-ESMTP-$mail_name-mx1-ppp0-ipv4-25
> -o smtpd_tls_security_level=may
> -o postscreen_tls_security_level=mayboth these belong in main.cf, or better, set main.cf:
> -o tlsproxy_tls_security_level=may
"smtpd_security_level = may" and leave these at their defaults.
> -o smtpd_proxy_filter=nemesis.ipv4:10025The cache map parameter belongs in main.cf. Probably a mistake to
> -o soft_bounce=no
> -o postscreen_cache_map=btree:$data_directory/postscreen_cache-ipv4
create separate caches.
Same comments as above for the smtpd listener below.
>For the TLS part, it will be much easier to turn TLS on in main.cf,
> mx1.ipv6.slagter.name:smtp inet n - n - 2 smtpd
> -o myhostname=mx1.ipv6.slagter.name
> -o smtpd_banner=mx1.slagter.name-ESMTP-$mail_name-mx1-ppp0-ipv6-25
> -o smtpd_tls_security_level=may
> -o postscreen_tls_security_level=may
> -o tlsproxy_tls_security_level=may
> -o smtpd_proxy_filter=nemesis.ipv4:10025
> -o soft_bounce=no
> -o postscreen_cache_map=btree:$data_directory/postscreen_cache-ipv6
then turn it off on the interfaces where you don't want to offer it
with "-o smtpd_tls_security_level=none".
# main.cf
smtpd_tls_security_level = may
For the greeting banners, set them as macros in main.cf and then
refer to them by $name in master.cf
# main.cf
postscreen_greet_v4 = postscreen.v4.mx1 ESMTP greets you
postscreen_greet_v6 = postscreen.v6.mx1 ESTMP greets you
Now tell postscreen which ports to listen on and to enable the banner:
#would become:
mx1.ipv4.slagter.name:smtp pass - - n - 2 smtpd
Good luck.
-- Noel Jones
- On 21-02-13 19:17, DTNX Postmaster wrote:
> You keep blaming the documentation and the software, when the problemYes I blame the documentation, but not the software. I've been using
> is most likely in your understanding of it.
postfix for, well, something like ten years or more, I think it's the
best thing since sliced bread, especially compared to sendmail, qmail
and exchange.
The way I've configured it now, really suits the demands. I cannot
remember any phrases in the documentation recommending not to do it this
way (i.e. start multiple smtp listeners on different addresses with
different options, in one master process). If it actually appears to be
disrecommended, then that's clear to me, no problem.
> Simplify your configuration. Don't assume that what goes for 'smtpd'I'd like to, but where do I find what I CAN assume? The factual
> goes for 'postscreen' as well.
documentation of postscreen is so sparse, it's mostly HOWTO,
monkey-see-monkey-do.
> Pick sensible defaults for 'main.cf',That's already done.
> and override only the options that are absolutely necessary.
> If you have a legitimate reason (as in, contractual obligations orActually this way is much more KISS to me than running multiple
> whatnot) to require seperate hostnames, greetings, TLS settings and
> such, use the multi-instance features and seperate them. Otherwise the
> KISS principle applies.
instances of "master".
I'm starting to think that the reason this operation is not documented,
is because it's not possible. It looks like the postscreen layer
literaly sits between the remote client and the smtp process, and the
information where the connection took place (interface/address) is not
available at the point where the smtpd is invoked.
If that's the case, postscreen is not the way to go for me. I assumed
postscreen was implemented a bit like proxy-filter, where you can run
any number of filters on any number of addresses.
- On 21-02-13 19:30, Noel Jones wrote:
> You've shared too much. By now no one has any idea what you're doing.I'm just following the "REPORT A PROBLEM" procedure I was kindly pointed
at...
> When postscreen decides to pass the connection to smtpd, postscreenYes at this point the smtpd/master has no knowledge of the
> is no longer involved, and smtpd has no knowledge of what transpired
> between postscreen and a client.
interface/address, that's exactly the thing I fear.
> At some point you reported:Tried both, doesn't matter. The thing is that what way you set the smtpd
> [ .. ]
>> -o postscreen_tls_security_level=may
>> -o tlsproxy_tls_security_level=may
>
> both these belong in main.cf, or better, set main.cf:
> "smtpd_security_level = may" and leave these at their defaults.
options (in main.cf) you cannot override them with postscreen. So if you
set the default value suitable for address a and b, they must be
override for address c and d and vv. Yes, I have some internal address
that need to have tls_security=none and yes, that works like a charm
without postscreen enabled.
>> -o postscreen_cache_map=btree:$data_directory/postscreen_cache-ipv4Nope, the cache map cannot be shared between two smtpd processes (see
>
> The cache map parameter belongs in main.cf. Probably a mistake to
> create separate caches.
documentation ;-)). It's not a problem though, because one db holds ipv4
addresses and the other is ipv6 addresses.
> For the TLS part, it will be much easier to turn TLS on in main.cf,All relevant options for tls are actually set in main.cf. It's only that
> then turn it off on the interfaces where you don't want to offer it
> with "-o smtpd_tls_security_level=none".
it's not enabled there, it's enabled on a per-address base. Which works.
> For the greeting banners, set them as macros in main.cf and thenThat's a possibility, but it's not necessary and doesn't solve the problem.
> refer to them by $name in master.cf
> Now tell postscreen which ports to listen on and to enable the banner:I get your drift, but IIRC I already tried this (multiple times, with
>
> #
>
> would become:
> mx1.ipv4.slagter.name:smtp pass - - n - 2 smtpd
slight variations) and also reported about the outcoming of that:
"fatal: address already in use".
Did I already mention I have followed all the steps from the README as
closely as possible?
- On Thu, Feb 21, 2013 at 05:46:26PM +0100, Erik Slagter wrote:
> Another variation I tried ("pass" and "postscreen" the other wayTake a DEEP breath, relax and don't *try* implementing new
> around). This works, but gives the original problem, the smtpd
> options are not honoured (especially banner and starttls="may"),
> even though I set both:
configurations you don't yet understand. The shots in the dark will
just get you more confused.
It is time to try to *understand*.
1. A running Postfix instance is a collection of separate background
services (daemons) launched by an inetd-like service supervisor known
as "master. These services run independently in separate processes
and communicate with each other using unix-domain sockets.
They are configured either via main.cf (best practice) or via
master.cf "-o parameter=$value" overrides (when you must).
The MOST important thing you need to understand about this is:
Adding "-o FOO=BAR" to the master.cf entry for SERVICEA has
NO EFFECT on the value of FOO in SERVICEB!
Even when the MESSAGE is passed from SERVICEA to SERVICEB the
parameter settings ARE NOT.
Thus when you convert an existing "smtpd" entry to a "postscreen"
entry, it is a grave mistake to leave the "smtpd" (-o options)
that tune the functionality of smtpd attached to the "postscreen"
service. It (postscreen) won't care and the destination "smtpd"
to which the message is handed off will no longer know the parameters.
2. To provide multiple smtpd personalities, you need to implement multiple
"smtpd" services each with their own settings. (As you do when smtpd
listens directly on an "inet" socket).
3. To implement 2. with postscreen, each "inet" listening postscreen
(with settings relevant for postscreen) must hand the message off
to an "smtpd" appropriate for its listening IP address..
192.0.2.1:25 inet ... postscreen
-o smtpd_service_name=25@192.0.2.1
-o <postscreen-related-settings> ...
25@192.0.2.1 pass ... smtpd
-o <smtpd-related-settings> ...
Lather, rinse, repeat:
192.0.2.1:587 inet ... postscreen
-o smtpd_service_name=587@192.0.2.1
-o <postscreen-related-settings> ...
587@192.0.2.1 pass ... smtpd
-o <smtpd-related-settings> ...
Lather, rinse, repeat:
192.0.2.2:25 inet ... postscreen
-o smtpd_service_name=25@192.0.2.2
-o <postscreen-related-settings> ...
25@192.0.2.2 pass ... smtpd
-o <smtpd-related-settings> ...
Lather, rinse, repeat:
192.0.2.3:25 inet ... postscreen
-o smtpd_service_name=25@192.0.2.3
-o <postscreen-related-settings> ...
25@192.0.3.2 pass ... smtpd
-o <smtpd-related-settings> ...
... but do stop eventually ... :-)
--
Viktor.
- On 21-02-13 20:07, Viktor Dukhovni wrote:
> [ ... ] (lot of patronising text removed)And THAT is exactly the clue I was looking for! It works!
>.
The only thing that would have to be in the README file is the need to
use "smtpd service names" in case of multiple smtp listeners, point to and then add a
bit of really helpful text to the current one:
"The internal service that postscreen(8) hands off allowed connections
to. In a future version there may be different classes of SMTP service."
If you google for this command, you'll get references to either this
text or this thread :-(
So for other people seeking to do the same, this does the trick, it's
also simple once you know, the "service" parameter of a "pass" service
is not an address:portno combo but an identifier:
#
# outside -> inside
# postfix(25) -> amavis(10025)
#
mx1.ipv4.slagter.name:smtp inet n - n - 1 postscreen
-o postscreen_cache_map=btree:$data_directory/postscreen_cache-ipv4
-o
postscreen_greet_banner=mx1.slagter.name-ESMTP-mx1-postscreen-1-ppp0-ipv4-25
-o smtpd_banner=mx1.slagter.name-ESMTP-mx1-postscreen-2-ppp0-ipv4-25
-o postscreen_tls_security_level=none
-o smtpd_service_name=mx1_ipv4
mx1_ipv4 pass - - n - - smtpd
-o myhostname=mx1.slagter.name
-o smtpd_banner=mx1.slagter.name-ESMTP-$mail_name-mx1-ppp0-ipv4-25
-o smtpd_tls_security_level=may
-o smtpd_proxy_filter=nemesis.ipv4:10025 # amavis
mx1.ipv6.slagter.name:smtp inet n - n - 1 postscreen
-o postscreen_cache_map=btree:$data_directory/postscreen_cache-ipv6
-o
postscreen_greet_banner=mx1.slagter.name-ESMTP-mx1-postscreen-1-ppp0-ipv6-25
-o smtpd_banner=mx1.slagter.name-ESMTP-mx1-postscreen-2-ppp0-ipv6-25
-o postscreen_tls_security_level=none
-o smtpd_service_name=mx1_ipv6
mx1_ipv6 pass - - n - - smtpd
-o myhostname=mx1.slagter.name
-o smtpd_banner=mx1.slagter.name-ESMTP-$mail_name-mx1-ppp0-ipv6-25
-o smtpd_tls_security_level=may
-o smtpd_proxy_filter=nemesis.ipv4:10025 # amavis
On Fri, Feb 22, 2013 at 11:04:34AM +0100, Erik Slagter wrote:
First, a quick comment, all of the sturm and drang in this thread
is the result of a peculiar reluctance of most users to heed the
advice in MULTI_INSTANCE_README and simplify their configurations
by handling each distinct message flow in a separate Postfix
instance, each of which can be configured with few if any master.cf
tweaks, and understood and maintained much more easily.
A combination of MULTI_INSTANCE_README and POSTSCREEN_README would
get you there much more quickly, and even allow simpler configuration
of cases where identical policies apply to multiple protocol:address
endpoints, since you can just set inet_interfaces in main.cf to list
one or more network addresses for a given instance.
I strongly recommend that you take the time to refactor your
configuration to separate each flow into its own queue. The initial
investment of time pays off quickly in easier to manage configurations
and operational support (e.g. separate queues make it easier to
see which flow is having problems).
> On 21-02-13 20:07, Viktor Dukhovni wrote:
>
> > [ ... ] (lot of patronising text removed)
Text that is required background knowledge to understand what
follows, misconstrued to be patronizing rather than emphatic. Chill
man, the blustery tone of this thread is mostly the result of your
reticense to (AFAIK you never did) post the actual master.cf
configuration that failed to meet your expectations. You should
probably also not have included the text below in the initial post:
The options (-o) that I specify on the various per-interface
smtpd instances are NOT honoured anymore. ...
Is this intentional? A know[n] bug? ...
I must say the "howto" isn't very clear on this matter, it assumes you
only have only one external interface.
This is rude to the developers who take great pains to make Postfix
unusually robust and well documented. The "patronising" text is
sufficient to logically deduce that (and why) you need multiple
smtpd "pass" services, at which point one looks for a parameter to
specify the pass service, and finds it (in this case clustered
sub-optimally with unrelated settings, we'll fix that) in the postscreen(8)
manpage.
If Wietse is still reading this, we should move "smtpd_service_name"
to its ownn section nearer the top of the postscreen(8) manpage.
Fortunately, the parameter name is just what you'd expect if you've
ever seen "cleanup_service_name" which plays the same role one
handoff downstream.
> .
>
> And THAT is exactly the clue I was looking for! It works!
Naturally, since it is simply a logical consequence of understanding
the patronising text. :-) Perhaps some people even spotted the
transposition error in the last "Lather, rinse, repeat" example.
(It has been observed that students pay more attention to technical
books that contain minor errors that require them to pause and
think, and that they learn more from these than from polished
material that requires less attention).
[
Plus the fact that "unix" and "pass" service names are just file
names in /var/spool/postfix/private/ which I started to describe
in my first post, but decided to keep it more concise in the hope
that this will be apparent from context.
The master.cf services live in one of three namespaces:
- inet/public (inet can't be private).
- unix/public
- unix/private
Each of the "unix" cases subsumes "unix", "fifo" and "pass" since these
all are accessed via paths in /var/spool/postfix/{public,private}.
All delivery agents are "private" while "pickup", "qmgr", "flush"
and "showq" are "public" to support postdrop(1) and postqueue(1)
and their sendmail(1) interfaces. Almost everything else is private,
except for cleanup(8) which AFAIK is public only for historical
reasons.
]
--
Viktor.
- Viktor Dukhovni:
> All delivery agents are "private" while "pickup", "qmgr", "flush"This was changed from "private" into "public", so that postdrop
> and "showq" are "public" to support postdrop(1) and postqueue(1)
> and their sendmail(1) interfaces. Almost everything else is private,
> except for cleanup(8) which AFAIK is public only for historical
> reasons.
could directly submit mail into cleanup, using the maildrop directory
only as a fall-back mechanism in case cleanup transaction failed.
Recovering from all possible failure modes is complicated and I did
not get around to write that code (and there are few people who I
would trust to write it).
Wietse
Your message has been successfully submitted and would be delivered to recipients shortly.