sendmail configuring port numbers

[Ben Scott]

On Tue, Oct 13, 2009 at 11:02 PM, Steven W. Orr <steveo at syslang.net> wrote:
> The way I understand it, sendmail made to switchover a while back to separate
> out the sendmail process from the MSP. I guess the question is: Why did they
> do this in the first place?

  Security.  To avoid having to run quite as much stuff as "root" all
the time.  I'm not really sure it helped all that much, since the
public-facing SMTP listener daemon (where attacks usually come in)
still runs as root.  But I guess they had to start somewhere.

> I'm running a small home server.

  That sends "500K messages out per month"?

> Frankly, if anything comes in with more than *5* recipients, the likelihood
> that it's spam is about 99 44/100%.

  That's your call.  As I said, I don't know if restricting on
recipient count is likely to be a problem or not.

> I'd really like to know what the intent is of these extra ports. Is lmtp
> related to the sendmail MAILER(local)? Who is it that creates the listener on
> localhost:25? Is it the MSP or is it the MTA? If it comes from the MSP then
> shouldn't the listener on port 24 also come from the MSP?

  TCP/25 is the default SMTP MTA (Mail Transfer Agent).  MTAs are
nominally fully-capable mail exchangers, participating in the Internet
email infrastructure.

  TCP/587 is the default SMTP MSA (Mail Submission Agent).  The intent
is for programs like Outlook, Eudora, etc., to use MSA to submit new
messages.  These programs don't have a complete SMTP implementation,
and so blasting to SMTP on TCP/25 isn't really a "clean" solution.  In
practice, MSA is basically a traditional SMTP MTA with certain
capabilities restricted.  In particular, they normally require
authentication, so the "open relay" problem didn't happen again.

  TCP/24 is assigned to LMTP, Local Mail Transfer Protocol.  I've
never touched this, but the RFC says it's basically an SMTP MTA
variant that allows individual envelope recipients to be rejected.
This lets a system without local mail queue storage exchange mail in a
limited fashion.  (SMTP requires MTAs to store and retry failed
recipients.)

  MSP (Mail Submission Program) is none of these.  MSP is a Sendmail
internals thing.

> Since I changed the value of MAX_RCPTS_PER_MESSAGE in sendmail.mc and I never
> specified anything re Port 25 on localhost and I was stopped from sending out
> mail to a lot of people, then it stands to reason that localhost:25 was
> defined in sendmail.mc ...

  I'm not exactly sure what you mean by "never specified anything re
Port 25 on localhost".

  You say your sendmail.mc contained

	DAEMON_OPTIONS(`Name=MTA')

  That doesn't specify a port number.  Sendmail defaults to TCP/25.
So the above defines a daemon instance, named "MTA", otherwise with
defaults, including TCP/25.  That happens to be the default if you
don't specify *any* DAEMON_OPTIONS, but it needs to be explicit for
you because your config defines a second daemon instance as well.

  Incidentally, if you don't also use

	FEATURE(` no_default_msa')

then you're supposed to get an MSA on TCP/587 as well, regardless of
what your DAEMON_OPTIONS say.

  See docs at:

	http://www.sendmail.org/m4/tweaking_config.html

> ... if that's true then what does submit.mc actually do?

  It's a Sendmail internals thing used to manage the mail queue for
local programs.  It's got about as much to do with SMTP as EXT2FS
does.  :)  A Google for "sendmail submit.mc" (hint, hint :) ) found a
nice diagram as the third site hit:

	http://sial.org/howto/sendmail/

  The official word from Sendmail is:

	http://www.sendmail.org/m4/msp.html

	http://www.sendmail.org/~ca/email/doc8.12/SECURITY

  Beyond that, you'll have to RTFS, I think.  :)  Me, I don't want to know!  :)

> *682 > telnet saturn.syslang.net 24
> Trying 207.172.210.41...
> telnet: connect to address 207.172.210.41: Connection refused

  According to the config except you posted:

	DAEMON_OPTIONS(`address=localhost, Port=24, Name=NCMSA, M=EC')

the "address=localhost" part means you're telling that daemon instance
to bind to that address.  It's bound to 127.0.0.1, so connections to
other addresses won't work.  The other DAEMON_OPTIONS didn't specify
any address, so it uses the default, which is "all addresses"
(0.0.0.0).

-- Ben