-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Frederick Bruckman <fredb@immanent.net> writes:
> 
> cwr@nexthop.com (Christopher W. Richardson) writes:
> 
>> Frederick Bruckman <fredb@immanent.net> writes:
>> 
>>> cwr@nexthop.com (Christopher W. Richardson) writes:
>>> 
>>>> cwr@achilles$sendmail -Ac -bp
>>>> /var/spool/clientmqueue is empty
>>>>                 Total requests: 0
>>>> 
>>>> cwr@achilles$ls /var/spool/clientmqueue/
>>>> Qfj1D8F04B016585    Qfj1H18xMR023287    dfj1E8F1GH009587 sm-client.pid
>>> 
>>> Do you have an "/etc/mail/submit.cf"? "etcupdate" should have
>>> installed that for you.
>> 
>> Yep, I ran etcupdate, and do have a submit.cf.  Rebuilt
>> submit.cf with a DS rule so that mail could leave the machine
>> and added smmsp=YES to rc.conf
> 
> 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.

> It goes without saying that you also have "sendmail=YES" in
> "/etc/rc.conf"?

Actually, no.  But the heuristic "nothing else seems to have been
changed about the mail configuration but we would like locally
originated and locally destined mail to be delivered" is
accurately starting sendmail without it.

> 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?  If it's not, then what does the above mean.
Specifically, it sounds like you've got three daemons there: the
submission daemon, sendmail, and the client daemon.  (And
presumably by the "network daemon" you mean "sendmail" earlier in
your paragraph?). Exactly how many, and which, daemons should I
be running if, as you say at the beginning, I don't want to run
sendmail_suidroot?

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?

> 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.

> 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).

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.

Thanks again,
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCFRZ0P65RBOOHTzERAvJNAJ4rKqgGg1/n8hhypezk98C9sjOutwCglib0
RsUmhLL9JBPJ+zbF2BaZu2M=
=Oywg
-----END PGP SIGNATURE-----