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.
> >4. Therefore, you need multiple "smtpd" "pass" services for "postscreen"
> > to hand the connection to. The postscreen(8) manual page refers you to
> >
> > http://www.postfix.org/postconf.5.html#smtpd_service_name
> >
> > which must specify the service name of a "pass" entry in master.cf,
> > you need one of these for each distinct postscreen instance.
>
> 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.
