OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: new convert
From: Bennett Todd (betrahul.net)
Date: Fri Dec 15 2000 - 18:16:01 CST

2000-12-13-11:03:32 Thomas C. Smith:
> After being hacked six times in 8 weeks and all seemingly being
> the fault of my MTA I converted our servers to postfix yesterday.

I think it's fair to hope that if you get burgled again, it won't be
Postfix's fault.

> This is in regards to our Primary DNS acting as a top MX host
> for another server/domain. I get the 'mail loops back to myself
> error'

If I take your meaning, what is happening is that this server you're
setting up is the primary AKA preferred MX host for another domain,
but it's not to deliver email for that domain, it's to relay it on.

This isn't uncommon; it's a situation that often shows up in
firewall configs.

> Here's what I've done in main.cf:
>
> smtpd_recipient_restrictions = permit_mx_backup, check_relay_domains
> relay_domains = $mydestination, /etc/postfix/relay-domains
>
> The relay domains file is a text file with domains each on a separate line.
>
> The smptd_recipient_restrictions was just a guess after the relay_domains
> didn't seem to have any affect.

I think you're on the wrong route here; as best I can understand
this, the relay_domains should work as far as it goes. The problem
is, nothing you've done (that I can see) tells postfix what it
should do with this email once it gets it. You've correctly told it
to allow relaying for it (so it accepts the email, doens't give
"relay refused"); and you've correctly avoided telling it to deliver
for those users locally --- so it knows it needs to get rid of it.
When it tries to do so, it hasn't been told anything special to do
otherwise, so it does an MX lookup, then an A for the hostname
that's most preferred, then connects to it, then ... oops, talking
to myself.

You've got to find some way to tell your postfix server "sure, the
_rest_ of the world thinks you send email to this domain by
directing it to you, you're the primary MX for it, but _you_ know
better". I _think_, if I'm understanding transport(5) exactly right,
all you need to do is main.cf

        transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport:

        relay.domain smtp:[server.for.relay.domain]
        .relay.domain smtp:[server.for.relay.domain]

then "postmap /etc/postfix/transport" and "postfix reload" and you
should be cookin'.

And a tip, if you're having trouble debugging something and email is
bouncing on a live production server, a possibly-comforting tip is
to set postfix's soft_bounce=yes. It'll take most failures that
would bounce email, and turn 'em into soft, or temporary, problems,
so postfix will simply enqueue the email for later disposition.
Depending on the problem, the email may simply flow on the way it's
supposed to once you get it fixed, or else you may have to get
postfix to re-inspect the message by moving it from deferred into
incoming (preferably with postfix down while you do the mv). But I
_believe_ transport is not in this category, once you get that fix
it should start applying to stuff in deferred immediately as it gets
scheduled for retries --- so "postfix flush" will try everything
against the new transport map to see if that fixes it:-).

I'm afraid I'm not 100% positive about the above config advice, but
I'm hoping if I'm wrong someone will jump in and straighten us out.
I haven't had occasion to use a transport map as yet.

-Bennett

  • application/pgp-signature attachment: stored