Separate Submission Instance on Same IP as MX

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. In this case I'm running
in to problems when the submission instance uses the same IP address as
the MX instance. (Due to a limited IP address pool there is currently
only one routable IP address assigned to this server.)
Using the submission instance to send a message to a recipient address
for which the server is also the MX host triggers Postfix' loop
detection. Mail for foreign addresses is relayed correctly. I realize
this can be done easily enough without using multiple instances. Is
there a way to work around this so that an MX instance and submission
instance can share single IP address? I've gotten used to the queue,
logging, and configuration separation provided by multiple instances and
would rather like to use that approach here if I can.
Configuration and debugging information follow. In this example, the
server is the MX host for both domains 'example.com' and 'example.org'.
mike@mail[~]$ nc 127.0.0.1 587
220 smtp.example.com ESMTP Postfix
EHLO test
250-smtp.example.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN blahblahblah
235 2.7.0 Authentication successful
MAIL FROM:
250 2.1.0 Ok
RCPT TO:
250 2.1.5 Ok
DATA
354 End data with .
test
.
250 2.0.0 Ok: queued as 098981BF0969
quit
221 2.0.0 Bye

Corresponding log entries for above transaction:
Jul 31 18:27:48 mail postfix-submission/smtpd[13440]: connect from
localhost.localdomain[127.0.0.1]
Jul 31 18:27:56 mail postfix-submission/smtpd[13440]: 098981BF0969:
client=localhost.localdomain[127.0.0.1], sasl-method=PLAIN,
sasl-username=mike@example.com
Jul 31 18:27:59 mail postfix-submission/cleanup[13442]: 098981BF0969:
message-id=
Jul 31 18:27:59 mail postfix-submission/qmgr[13433]: 098981BF0969:
from=, size48, nrcpt=1(queue active)
Jul 31 18:27:59 mail postfix-submission/smtp[13443]: 098981BF0969:
to=, relay=none, delay=47, delays=46/0.09/0/0,
dsn=54.6, status=bunced (mail for example.org loops back to myself)
Jul 31 18:27:59 mail postfix-submission/cleanup[13442]: AB7021BF096B:
message-id=
Jul 31 18:27:59 mail postfix-submission/qmgr[13433]: AB7021BF096B:
from=, size!51, nrcpt=1(queue active)
Jul 31 18:27:59 mail postfix-submission/bounce[13445]: 098981BF0969:
sender non-delivery notification: AB7021BF096B
Jul 31 18:27:59 mail postfix-submission/qmgr[13433]: 098981BF0969: removed
Jul 31 18:27:59 mail postfix-submission/smtp[13443]: AB7021BF096B:
to=, relay=none, delay=015, delays=015/0/0/0,
dsn=54.6, status=bunced (mail for example.com loops back to myself)
Jul 31 18:27:59 mail postfix-submission/qmgr[13433]: AB7021BF096B: removed
Jul 31 18:28:02 mail postfix-submission/smtpd[13440]: disconnect from
localhost.localdomain[127.0.0.1]
postconf -c /etc/postfix-submission -n:
alias-database alias-maps config-directory = /etc/postfix-submission
data-directory = /var/lib/postfix-submission
default-database-type = cdb
local-recipient-maps local-transport = error:5.1.1 Mailbox unavailable
multi-instance-enable = yes
multi-instance-name = postfix-submission
mydestination mydomain = example.com
myhostname = smtp.example.com
myorigin = $mydomain
parent-domain-matches-subdomains queue-directory = /var/spool/postfix-submission
smtpd-client-restrictions = permit-sasl-authenticated reject
smtpd-helo-required = yes
smtpd-recipient-restrictions = reject-non-fqdn-recipient
permit-sasl-authenticated reject
smtpd-sasl-auth-enable = yes
smtpd-sasl-path = /var/run/dovecot/auth-client
smtpd-sasl-security-options = noanonymous
smtpd-sasl-type = dovecot
smtpd-sender-restrictions = reject-non-fqdn-sender
reject-unknown-sender-domain
strict-rfc821-envelopes = yes
unknown-address-reject-code = 554
unknown-client-reject-code = 554
unknown-hostname-reject-code = 554
mail-version = 2.8-20100707
In master.cf for the postfix-submission instance, the "smtp inet ...
smtpd" entry is commented out, and "submission inet ... smtpd" is enabled.
Thanks,
Mike

On 08/01/2010 04:11 AM, Mike Morris wrote:
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.
Indeed.
You're going to have to do a lot better than "I want to do this".
Use a single instance, and save yourself some time.
Since submission is a separate transport, it does log separately.
UNSTABLE.
sheesh.

Mike Morris:
If you use different MTAs, then use different myhostname AND
different inet-interfaces settings. Otherwise it is just too easy
to screw up and have a high-speed mail system meltdown/explosion/etc.
Postfix is not just about "secure" for some vague definition of
secure, it is about making a safe to use, so that it does not rip
off your arms and legs when you make a trivial mistake.
Wietse

On 08/01/2010 02:37 AM, Jeroen Geilman wrote:
I don't believe it is "totally useless" to use separate instances for
distinct services. Configurations can get complex. Outgoing mail may
be handled differently than incoming mail. 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*.
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.

On 08/01/2010 09:29 AM, Wietse Venema wrote:
Fair enough. I'll see what can be done about a second IP address.
-Mike

Mike Morris:
[ Charset ISO-8859-1 unsupported, converting... ]
Or enable the commented-out submission service (port 587) in the
default master.cf file. With this, use port 587 for submission,
and port 25 for final delivery.
Wietse

On 08/01/2010 08:42 PM, Mike Morris wrote:
Certainly, and postfix supplies its fair share, as I explained above.
All mail comes in. all mail goes out.
Instead of using multiple instances of postfix, why not use multiple
smtpd-listener instances, like we suggest ?
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).
J.

On 08/05/2010 11:57 AM, Jeroen Geilman wrote:
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.
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.
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

On 08/05/2010 10:15 PM, Mike Morris wrote:
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.

Mike Morris:
The difference is that stable release features not change except
in case of emergency, so you can upgrade from one stable Postfix
version to the next without having to reconfigure Postfix. And when
features do have to change, there is a great deal of backwards
compatibility.
The snapshot releases introduce new features, and those can still
change in incompatible ways. For example, postscreen is a prototype
that I threw together in a few weeks so that I could present some
new measurements at a conference. Once this program is finished
sites will almost certainly need to update configuration files.
Wietse