Re: [PLUG] Postfix bastion host?

[Morgan Jones <morgan@morganjones.org>]

Hello JP et al,

On the testing front:  assuming the new machines are totally new (ie your current environment can run without it) then just set it up and point a sub domain or a domain you don't currently use for main and send test messages through it until you're comfortable that it routing mail correctly--send from gmail to all the possible addresses you want to test.. telnet to the port and spoof your gw.example vs example tests..

If you really want to avoid losing mail and there's overlap between your current production and the new environment you probably want to set up a test environment to get the config ironed out with test mail.. either with multiple machines, multiple VMs or maybe even just multiple postfix instances on one host: http://www.postfix.org/MULTI_INSTANCE_README.html

I've put additional comments inline.

-morgan



On Mar 21, 2011, at 4:11 AM, JP Vossen wrote:

> My mail server is currently co-lo'ed and I want to move it back onto my LAN for various reasons.  Due to ToS and anti-spam reasons, I need to route incoming and outgoing mail via a new co-lo server.  I know Postfix can do this [1].
> 
> The server hardware and IPA are also changing, and since the same machine hosts my web and DNS, that's a pain, but I've done all that before.
> 
> For the mail server side, at a high-level, I have to:
> 
> 1) Figure out DNS names, update internal and external DNS, and email clients.  I can do that in advance, then just change the local DNS CNAMEs to cutover.  The external server will be "mail." while the internal server will be "smtp." and "imap.".
> 
> 2) Install/configure IMAPD on the internal server (I already rsync the real external server twice a day, so I can locally rsync that into /home/ as needed for testing.)
> 
> 3) Tweak the internal server's Postfix to have local mail and only relay external mail (right now it relays everything).  Tricky to test without losing mail...  :-(
> 
> 4) Configure the external server to securely relay and not mangle names (i.e., I want to only have user@example.com, and not user@gw1.example.com).  Tricky to test without losing mail...  :-(

won't relay-domains cover this?

> 
> 5) Cutover servers (DNS, web, & incoming/outgoing SMTP)
> 
> 6) Final test
> 
> 7) Backout plan is to swap old DNS configs back in.
> 
> 
> Questions:
> 
> 1) What IMAP server do you recommend on Debian Squeeze 64-bit with Postfix and (mostly) Thunderbird?  I'm currently using courier-imap-4.4.0-2 (Maildir) on Debian Lenny 32-bit, so it might be a bit easier to re-use some configs.  But maybe something else is better?  These jump out at me in the stock Squeeze repos:
> 	courier-imap - Courier mail server - IMAP server  # Using now
> 	cyrus-imapd-2.2 - Cyrus mail system - IMAP support
> 	dovecot-imapd - secure IMAP server that supports mbox and maildir mailboxes
> 	mailutils-imap4d - GNU mailutils-based IMAP4 Daemon

I can vouch for cyrus-imapd--I've used it both personally and professionally and it works well.  Generally it's well documented.

> 
> 2) Has anyone done this before or have similar configs?
> 
> 3) Any comments, suggestions or things I missed?

Is there any reason not to use the co-lo'ed server for all of your mail routing ('mail' in your example) and the server on your local network as just an imap store ('imap' in your example)?  The gateway can take care of smtp routing, anti-abuse filtering and the store can handle delivery to user and imap service to users.  I suggest this as it's a simpler config than trying to put routing intelligence into back-end ('smtp') in your example.  It will also simplify your routing config--all of your outgoing mail will go directly to the co-lo'ed server and either delivered to back to the imap store or the Internet.. 

That said, if there is a reason to keep some routing intelligence on the back-end and you want to route mail for my-domain.org directly to the store back-end but the rest to your co-lo'ed gateway I *think* you'd just define my-domain.org as an entry in the transport table:
my-domain.org: imap.my-domain.org
http://www.postfix.org/transport.5.html

I'm pretty sure transport table entries override default_transport which you'd presumably use to cause all Internet mail to relay through your co-lo'ed server:
default_transport=smtp:mail.my-domain.org

If you're using cyrus and 'smtp' and 'imapd'  are the same machine I'm pretty sure a combination of putting my-domain.org in mynetworks and configuring postfix to deliver to a local cyrus instance will take care of it.

I'm reading quickly over lunch.. feel free to tell me I'm wrong or doesn't work and I'll dig deeper.

> 
> 4) Any suggestions on how to test this before cutover?  A client and my 2 servers are easy enough, but remote mail servers on the "Internet" are a bit harder.  I supposed I can add a 4th server as an "external" site and the fiddle up MX records in DNS...  Other/better ideas?

How about 2 mx records for my-domain.org: oldserver and newserver with either equal mx weight or perhaps weigh oldserver higher.  When you're ready to start testing start newserver and stop oldserver.  You can immediately reverse the process without depending on DNS to propagate.  If newserver is lower weight you start both and manually send mail to newserver and it will theoretically receive no Internet mail.. eventually it will start to get spam which could be a good test for your A/S sol'n.

> 
> 5) Any suggestions on how to cutover as smoothly as possible?

I think my answer to #4 applies.  Of course when you are happy with newserver just remove the mx record for oldserver and you're in business.

> 
> 
> I plan on attending at PLUG W tonight to hear Randall's email talk, so I thought this was kind of topical...
> 
> Thanks,
> JP
> 
> ____________________
> [1] This is interesting, but has no date (so obsolete?) and seems a little on the lite side:
> http://www.packetnexus.com/kb/greyarts/docs/1014086757:32027.html
> "Postfix as a bastion SMTP gateway"
> ----------------------------|:::======|-------------------------------
> JP Vossen, CISSP            |:::======|      http://bashcookbook.com/
> My Account, My Opinions     |=========|      http://www.jpsdomain.org/
> ----------------------------|=========|-------------------------------
> "Microsoft Tax" = the additional hardware & yearly fees for the add-on
> software required to protect Windows from its own poorly designed and
> implemented self, while the overhead incidentally flattens Moore's Law.
> ___________________________________________________________________________
> Philadelphia Linux Users Group         --        http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
> General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug