RE: [SLUG] IPTables/Firewall/SMTP

From: Bradley Brown (bradley@segrestfarms.com)
Date: Tue Jun 10 2003 - 12:59:54 EDT


The transport map did the trick. Delays are 5 seconds or less on most mail
to our domain. Thanks for the tip.

> -----Original Message-----
> From: Ian C. Blenke [mailto:icblenke@nks.net]
> Sent: Tuesday, June 10, 2003 12:05 PM
> To: slug@nks.net; Bradley Brown
> Subject: Re: [SLUG] IPTables/Firewall/SMTP
>
>
> On Tuesday 10 June 2003 10:21, Bradley Brown wrote:
> > We have two mx records for our internet dns. MX 10 points to our
> > firewall so that incoming mail gets scanned. MX 20 points to the offsite
> > email server. This works because once mail is submitted to our
> > firewall/SMTP hub, postfix times out trying to send to MX 10 (of course)
> > and then sends the mail to MX 20.
>
> Ah. Have you considered split-horizon DNS to "fix" this problem? I'm a
> split-horizon DNS fool at home.

        I've not heard of this before. Can you point me to some resources on the
subject? I have O'Reilly's "DNS and Bind" book, 4th edition. I haven't
looked through it in a while though. Is there anything in there that would
be on this subject?

>
> > This works really well and is so far quite reliable. The only thing
> > about it is that since the mail destined for our domain has to
> timeout on
> > the first MX record, it takes quite a while to receive mail in
> and also to
> > send mail to someone locally.
>
> In sendmail, you can use a mailertable directive to relay mail to
> another SMTP
> host. We use this feature in our NKS MailAssistant managed
> service product.
>
> From a quick google, it appears you can add a mailertable like map with:
>
> And add a line to your /etc/postfix/mailertable (or is it
> /etc/postfix/transport ?) file like:
>
> yourcompany.com smtp:[remotemailserver.yourcompany.com]
>
> Then re-run postmap:
>
> postmap /etc/postfix/mailertable
> postmap /etc/postfix/transport
>
> And reload postfix:
>
> postfix reload
>
> But I'm not a postfix expert, nor do I claim to be.

        Again... worked like a charm. One thing you missed though...
        in the main.cf file include the following:
        transport_maps = hash:/etc/postfix/transport

        Need to use "hash" if you use the "postmap /etc/postfix/transport" command
without other options.

>
> > I thought about using iptables to just forward the
> connections directly
> > to the offsite mail server, but so far I have not been able to
> come up with
> > a rule or rules that would do the trick. I can't just forward all SMTP
> > connections from the av scanner directly to the offsite mail
> server as that
> > would also forward any bounce messages or other error messages to people
> > trying to send mail in. The offsite mail server will just refuse those
> > messages and that will just clog the av scanner with
> undeliverable/deferred
> > messages.
>
> You're already using a DNAT rule inbound for port 25 to relay to the av
> server, correct? Adding another DNAT rule outbound for port 25 to
> relay to
> the external server should work as well.

        Yes, but like I said, I don't want to forward non-domain emails to the
offsite server. I attempted to match the host address and smtp port that was
going to the MX 10 host with iptables rules but couldn't seem to find the
right combination to make it work.
        That's not to say that it wouldn't work if I had more time to sit with it.
>
> > In an attempt to find a way to do what I need to do with iptables, I
> > used tcpdump to attempt to isolate the smtp traffic coming from the
> > firewall machine as it attempted to deliver mail to our domain. I was
> > trying to match the host ip address of the firewall going to smtp to
> > itself, but it never matched. It only matched when it began to send the
> > messages to the offsite firewall.
>
> > I thought about decreasing the timeout in postfix to reduce
> the amount
> > of time to takes to send the messages, but I don't want to affect mail
> > going to other domains.
>
> Play with timers as a last resort. Reducing the cycle time will
> probably also
> increase system load. It may have unexpected consequences as well (ie
> excessive "attempting to deliver email" messages during internet backbone
> outages).

        Those were my thoughts as well.

>
> > Any thoughts or ideas on how I may be able to speed up the delivery
> > times would be appreciated.
>
> Address the problem. Either configure postfix'
> mailertable/transport tables,
> or use a split-horizon DNS setup to hide the perference 10 MX record from
> machines that cannot connect to the host in question.

        Postfix solution worked great but I'm still interested in the split-horizon
DNS configuration.
        Many thanks. I appreciate the help.
Bradley

>
> --
> - Ian C. Blenke <icblenke@nks.net>
>
> (This message bound by the following:
> http://www.nks.net/email_disclaimer.html)
>
>



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:26:03 EDT