In article <sxk650qn8g7.fsf@crichardson.nexthop.com>,
	cwr@nexthop.com (Christopher W. Richardson) writes:
>> 
>> It sounds as if you're running the setgid "smmsp" submission
>> daemon as if it were the network daemon. If you only want to
>> run the one "sendmail", set sendmail_suidroot=YES, then make it
>> so, but *not* running the network listener suid root avoids a
>> whole class of security issues.
> 
> Hm. Well, it may sound like that, but it certainly wasn't my
> intent :)
> 
>>> and added a sendmail rule to hosts.allow to let mail get
>>> delivered locally.
>> 
>> "submit.cf" should have "DS" with a null argument, so that it
>> connects to the local sendmail daemon (which is why you needed
>> the "sendmail: localhost." in "hosts.allow").
> 
> Actually, this was the first thing I changed.  submit.cf did (and
> sendmail.cf still does) have a DS with a null argument.  I
> changed that to be DSmail.mydomain.com so that mail would leave
> my workstation for the outside world through my mail server.

I think that's the problem. You're mixing the features of "smart relay"
with "mail submission program". The network daemon is the one that should
have the smart relay; the destination for the submission agent should be
given as the argument to FEATURE(`msp',...), and it's usually [127.0.0.1]
or [IPV6:::1], and it comes out as "D${MTAHost}", not "DS".

>> You don't even really need "smmsp=YES", since the submission
>> daemon will connect immediately to the sendmail on the
>> localhost; the client daemon just sweeps the client queue
>> periodically, in case the network daemon was down at submission
>> time.
> 
> This is somewhat confusing to me.  I thought smmsp was the
> submission daemon?

When you run "sendmail -oi -t", "sendmail" is a hardlink to,
"mailwrapper", and "mailwrapper" invokes the sgid-smmsp submission
*agent*, which isn't a daemon. If it connects to the network agent
(daemon), there's nothing left in the client queue. If it doesn't,
and leaves stuff in the client queue (which it did before you were
configured properly), the queue runner picks it up later. So there's
actually three "sendmail"'s involved, but only two are daemons:

1) The original submission agent, which uses "submit.cf".

2) The (optional) queue runner daemon, which also uses "submit.cf".

3) The classic network daemon, using "sendmail.cf", which must accept
connections on "localhost.".

> Currently, it looks like this
> 
> cwr@achilles$ps -auxw |grep send
> root     633  0.0  0.6  1036  1644 ?? Ss   11:14PM 0:01.53 sendmail: accepting connections
> smmsp    691  0.0  0.0   908     4 ?? IWs  11:14PM 0:00.09 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail)
> 
> The first sendmail accepting connections is (I presume) the one
> started by default since I didn't put sendmail=NO explicitly in
> rc.conf.  The second is the one started by smmsp=YES.  I'll
> accept that I don't need that one, but then, how do I start
> whatever my second daemon is?

No, it look fine. I overlooked the "rc.conf" magic.  The queue
runner is running, it's just not doing its job for some reason.
I suspect your changes to "submit.cf".

>> Also, please verify that all the files in "clientmqueue" are
>> chmod 770 group "smmsp", and that you have a group "smmsp".
> 
> Hmmm.  Is 770 important? They're 660, and I didn't change
> anything after doing the upgrade to change what that would have
> been.  Yes, I have a group smmsp, and yes, all the files are
> owned by it.

My mistake. That looks fine, too.

>> Regardless of how or whether the submission daemon is set up,
>> it should be possible to start a queue runner on any queue
>> directory whatsoever (as root). Something like "sendmail -q
>> -OQueueDirectory=/var/spool/clientmqueue".
> 
> Well, regardless of whether or not I should be running smmsp
> (though, not _too_ regardless, because I would like to have my
> setup be "correct"), this seems to be the issue.  As you can see
> from the above ps output, I do have a queue runner running.  And,
> in fact, no _new_ mail is getting stuck in clientmqueue (as near
> as I can tell, in fact, mail is working fine).  It just that the
> queue runner seems not to "see" the mail in the queue from before
> I got things working (hence the original "/var/spool/clientmqueue
> is empty", even though it clearly is not).

The MSP queue runner is "special". I bet it would go ahead and
advance that mail to the next queue if you undid your change to
"submit.cf" and restarted it. I was thinking that a  regular,
"non-special" sendmail, running as root, should be able to
process any queue, but the way you have things currently set up,
I suppose that that mail wouldn't go anywhere.

> In case I didn't say it before, I do appreciate your helping me
> out with this.  Perhaps, since things appear to be working, and
> since I know what those stuck messages are, I should just delete
> them and not worry about it.  But, I am interested in making sure
> I have things set up "right" just in case the appearance of
> things working correctly is not the reality.

I would undo the change to "submit.cf", to hopefully let the mail
advance. As far as making the mail leave the main queue, there's a
couple of ways to do it. The easiest way, if there's to be no
masquerading involved, would probably be to use the "mailertable"
feature with the NetBSD default config. Try adding a line

.	esmtp:mail.mydomain.com

in "/etc/mail/mailertable", and build the database with

	cd /etc/mail
	makemap hash mailertable < mailertable

You don't even have to restart "sendmail" for that to take effect.


Frederick