On Tue, 02 Nov 2004 09:00:39 +0000, Paul Howarth <paul@xxxxxxxxxxxx> 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. > Thanks for the clarification I had googled MSA, but did not find such detailed information with my quick search. I will have to try this out. -- Leonard Isham, CISSP Ostendo non ostento.
