[O/T] MX vs. MSA (was: Re: InfoSecurity show)

[Mariano Absatz]

El 30 Apr 2003 a las 12:53, Spicer, Kevin escribió:

> Another problem with using spamassassin rules to implement a crude content
> filter is that this may require changes to spam filtering policies, and
> would require that outoing mail is filterd for spaminess, which could be
> embarassing / annoying (depending on what actions you choose) if you get
> false positives in outgoing mail. It just simply isn't granular enough. 

One solution to this is running 2 MailScanners (and 1 and a half sendmail) in 
the same box... or better yet, on different boxes...

This is slightly off-topic and a more SMTP-general, but anyway, here it goes.

For ages people has been running two different services with the same peace 
of software and, this is the bad part, with the same _instance_ of that 
software.

It is important to identify 2 different services and treat them differently 
or (as most people do) live with the problems of treating them (almost) 
equally.

The two services are:

1) MX (Mail eXchange): accepting mail from wherever for domains you provide 
incoming mail service. 

2) MSA (Message Submission Agent): accepting mail submitted by _your_ users 
and relaying it to wherever they should go.

There's still a third service that is usually added to the bunch:

3) MS (Message Store): the place where usually one or more of the MX's leave 
the messages for users to access them by whichever means (locally on disk, 
via POP, IMAP, web or other means)

but this one has been lately easily recognized as independent since lots of 
people like the 'featuritis' in Windows products like Exchange for this. 
Anyway, will leave this third option outside this analisys since it's not 
problematic from this point of view.

You can do both MX and MSA with an SMTP MTA (sendmail, exim, postfix, 
zmailer) but you should apply _different_ policies to messages coming from 
"outside" (MX) than to messages issued by your users (MSA). What's more, you 
have to clearly identify them in order to avoid being abused for relaying 
external mail.

All modern MTA's provide some kind of policy management that allows you to 
differentiate MX and MSA traffic, avoid relaying MX mail and the like, but 
it's usually a PITA when you want to apply fine control. SMTP AUTH is a big 
help, but then you _do_ have to make everyone use it or anyway be too 
cautious on how you configure policies on your MTA.

The easiest way to differentiate the services is to separate them completely. 
This is what most large ISPs do: they have a bunch of servers acting only as 
MX's, another bunch of servers acting only as MSA's for their customers, and 
then, a third bunch of servers acting as MS's for POP, IMAP, webmail, etc...

The configuration in the MX's and the MSA's are completely different.

Now, most of us can't afford (or justify to management) the expense of having 
2 or 3 servers dedicated to e-mail, but that is actually not a big problem. 
The only extra item we _do_ need is an extra IP address (not an extra network 
card, just the IP address).

Now you have two IP addresses, you can adjust your DNS accordingly, I'll show 
you later how, for now, let's just name the old IP "msa" and the new one 
"mx".

You must now configure 2 different instances of your mail server, one 
listening in the port 25 of mx for incoming mail and the other in the port 25 
of msa for outgoing mail. Each with its own configuration files, and its own 
set of queue and spool directories.

You also configure 2 different instances of MailScanner, with different 
configuration files and, if you want to, SA rules and scores. One works on 
the mx set of queue directories and the other one in the msa set of queue 
directories.

Depending on your MTA (I only know seriously how to configure zmailer), you 
might not even need 2 _complete_ MTA's... in the case of zmailer, I only need 
1 and 1/3 zmailers and 2 MailScanners to get this going.

The dns changes are like this... suppose you currently have something like 
this:

smtp.example.com.  IN A 172.20.22.22
example.com.       IN MX 5 smtp.example.com.
example.net.       IN MX 5 smtp.example.com.

and all your users know that they must send their mail thru smtp.example.com 
(i.e. configure their Outlook Express or whatever s..t they use with 
smtp.example.com as their SMTP server).

You now add the 172.20.22.33 address to your server (you can do this with 
only one network interface card).

In order to avoid major headaches (e.g. some use having the 172.20.22.22 
hardcoded since once, 2 years ago, dns wasn't working properly and some help 
desk person made him change the name for the address), you should use the old 
address for MSA and the new one for MX and configure DNS like this:

smtp.example.com.  IN A 172.20.22.22
mx.example.com.    IN A 172.20.22.23
example.com.       IN MX 5 mx.example.com.
example.net.       IN MX 5 mx.example.com.

Better still... if you plan to do this (you _don't_ decide this kind of thing 
overnight), you should prepare for the change by drastically lowering the 
TTL's of the dns record that will be changing some days in advance (ideally, 
at least one week in advance)... so the "preparing" DNS setup should look 
something like:

smtp.example.com.  IN A 172.20.22.22
example.com.  300  IN MX 5 smtp.example.com.
example.net.  300  IN MX 5 smtp.example.com.

A couple of hours before the change, do something like this:

smtp.example.com.  IN A 172.20.22.22
example.com.    1  IN MX 5 smtp.example.com.
example.net.    1  IN MX 5 smtp.example.com.


HTH

--
Mariano Absatz
El Baby
----------------------------------------------------------
I am not afraid of death, I just don't want to
be there when it happens.
        -- Woody Allen