On 08/05/2010 10:15 PM, Mike Morris wrote:
On 08/05/2010 11:57 AM, Jeroen Geilman wrote:
On 08/01/2010 08:42 PM, Mike Morris wrote:
On 08/01/2010 02:37 AM, Jeroen Geilman wrote:
On 08/01/2010 04:11 AM, Mike Morris wrote:
Hi,
I'm working on a mail server deployment that will only have one server
for MX and SASL submission purposes. Generally I like to have separate
Postfix instances to handle a specific task.
Why ?
It's totally useless in this case.
SMTP runs on port 25, and rejects anything not_invented_here.
Submission runs on port 587, and requires SASL.
Simple.
I don't believe it is "totally useless" to use separate instances for
distinct services.
Certainly, and postfix supplies its fair share, as I explained above.
Configurations can get complex. Outgoing mail may
be handled differently than incoming mail.
All mail comes in. all mail goes out.
I am aware that from the perspective of an MTA, all mail comes in and
all mail goes out. However, from the perspective of an organization,
there may be differences between how mail coming in to, and sent from,
that organization is handled.
Using multiple instances can
simplify the task. While it may not *work* in this case, using multiple
instances for MX and submission services is far from *useless*.
Instead of using multiple instances of postfix, why not use multiple
smtpd-listener instances, like we suggest ?
I've set up mail systems using both approaches. It isn't always
possible to foresee what may be required in the future. In the long run
it often is simpler to maintain the configurations of multiple instances
from the beginning rather than switch to such a setup after maintaining
a single instance becomes unwieldy.
I hadn't intended this to become a multiple- vs. single-instance debate.
Each individual user can decide which approach best suits their
environment, and when one is preferred over the other.
Anyhow, in this particular case we were able to configure the server
with a second IP address.
mail_version = 2.8-20100707
UNSTABLE.
sheesh.
Plenty of people would argue that Postfix experimental releases are
quite stable. In this case I would like to test and make use of postscreen.
Yes, postscreen is sexy... I think there are ways to get it to work with
2.7, if you're prepared to overlay it onto a 2.7 build and fix what
breaks (if anything breaks, I know of at least one successful deployment).
I was wondering if this was going to be your response. I find it
interesting that the person who shouted "UNSTABLE" in response to
someone using an experimental Postfix release would then suggest such an
approach. Out of curiosity, what would your reasons be for suggesting
running postscreen with 2.7 rather than using a 2.8 snapshot? Wouldn't
similar instability concerns about the latter apply to the former?
-Mike
That's not exactly what I meant.
2.8 is not out for release yet, and as such I personally would not
recommend using it in production systems, as a general rule, since my
testing (or that of any generic user) won't be as rigorous as the
developers'.
I meant to denominate the version as not being release/stable, not the
stability of the code as such.
However, earlier on the list Wietse commented on having pulled
postscreen from 2.7 (not quite ready yet) and others responsed that they
could successfully integrate it with 2.7 anyway.
So postscreen is a bit of a special case - it was /almost/ in 2.7.
But yeah, the shouting thing was a bit over the top.
Sry.
