Firewall and NAT

[Paul Howarth]

On Mon, 2004-11-01 at 18:55, Leonard Isham wrote:
> I suspect that these are the reasons sendmail.org recommends firewalling MSA:
> 
> Meant to be less strict on standards compliance
>     * Addresses don't have to be fully qualified
>     * Hostnames don't have to be fully qualified
>     * Don't require "required" headers, e.g. Message-ID: and Date: 

Having thought about this overnight, I've come to the conclusion that
the advice on firewalling off the MSA port is to prevent opening up what
is effectively a "second MTA" that could be tried by spammers/viruses
etc. when attempting to deliver mail to domains handled by that mail
server, i.e. to try to avoid spam/virus checkers that could be running
on the MTA but probably not on the MSA. Sendmail's default configuration
creates an MSA that does the same job that the MSP (Message Submission
Program) does for locally-generated mail, i.e. fully-qualifying
addresses, hostnames etc. as you mentioned above, in preparation for
sending mail out on to the Internet. However, it does nothing to prevent
any external client from connecting to it and using it to present mail
for local delivery. Hence the advice of firewalling it off from external
clients. However, there is another way to prevent this, i.e. by setting
up the MSA with the "a" daemon flag, like this:

FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl

The "a" flag makes the MSA require authentication from any client
connecting to it. This is how to ensure that only genuine roaming users
with the right username/password can access the MSA, without leaving it
open to anybody attempting local delivery. This setup allows roaming
users to always use the same mail sending settings in the mail clients,
which will work from wherever they are, even ISPs that block outbound
port 25.

The Security Considerations section of the Message Submission RFC
(http://www.faqs.org/rfcs/rfc2476.html - see section 9), appears to
support this viewpoint:

   Separation of submission and relay of messages can allow a site to
   implement different policies for the two types of services, including
   requiring use of additional security mechanisms for one or both.  It
   can do this in a way which is simpler, both technically and
   administratively.  This increases the likelihood that policies will
   be applied correctly.

   Separation also can aid in tracking and preventing unsolicited bulk
   email.

   For example, a site could configure its MSA to require authentication
   before accepting a message, and could configure its MTA to reject all
   RCPT TOs for non-local users.  This can be an important element in a
   site's total email security policy.

   If a site fails to require any form of authorization for message
   submissions (see section 3.3 for discussion), it is allowing open use
   of its resources and name; unsolicited bulk email can be injected
   using its facilities.

Paul.
-- 
Paul Howarth <paul at city-fan.org>