Firewall and NAT

[Neil Marjoram]

Thanks guys, I have enabled the MSA, I didn't know it existed! 

Neil.


On Tue, 2004-11-02 at 09:00, Paul Howarth wrote:
> 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>
-- 
Neil Marjoram.
Systems Manager
University College London
Adastral Park Campus
Martlesham Heath
Ipswich
Suffolk
IP5 3RL

01473 663711