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@xxxxxxxxxxxx>
