I figured I'd express my ignorance here before bothering the
official sendmail list, since this problem is new for me with RH9, so
it may be of interest to other Linux users.
Synopsys:
The new two-daemon form of sendmail causes my outgoing mail to
(unnecessarily, it seems to me) make a stop-over in the new client
queue, before going to the main daemon's queue anyway. And it won't
make the jump to the main queue when I'm off line. This is making it
a pain to figure out just what to run to force the queue's to be
processed in what order to get mail to go out during my brief
intervals of being connected to the internet.
What I want (and how I have done it with older sendmails):
I still live in the land of dial-up. Further, I only get so
much connect time for my base monthly fee (though I never approach it
except when there are a spate of updates to download). When I dial
from home (this is a laptop), I also get charged message units by the
phone company (and I can easily exceed my base 30 of those). Therefor
I read and compose E-mail off line.
I occasionally go on line just long enough to run fetchmail to
suck down my incomming mail and run sendmail -q to transmit my queued
outgoing mail to MV's outgoing mail host (my "smart relay"). By
letting fetchmail invoke sendmail directly to get incomming mail
delivered, instead of connecting to port 25 on localhost, I don't need
a sendmail daemon running at all. (I invoke sendmail -q and fetchmail
in /etc/ppp/ip-up.local .)
The new sendmail configuration:
To eliminate some (local only, I think) exploits, it is now
desired that the sendmail binary not be setuid root. Yet the main
queue needs to read-write-execute only by root (again, security
arguments). So when your MUA invokes sendmail, and it can't deliver
the mail itself, it also can't write it into the main queue. Instead
it writes it into a new "client" queue (/var/spool/clientqueue), which
is owned by a shell-less special user, which it can do because it is
setgid to that user (so if you work the local exploit you only gain
group rights to that user's group, not root user rights).
A new "sm-client" daemon runs solely for the purpose of taking
stuff out of the client queue to pass it to the main queue. (Either
because it is started as the root user in /etc/init.d/sendmail it can
write the main queue, or it passes the stuff to the local port 25.
I'm not sure which, but I suspect the former, since it does seem to
wind up in /var/spool/mqueue, rather than being sent straight out.)
Meanwhile, there is a plain root sendmail daemon running,
listening on port 25 (though, as I understand it, configured by
default, at least on RedHat, to only accept connections from the local
host, without benefit of tcp wrappers or iptables), and periodicly
"running" the main queue(s).
The ugly things:
OK. So I have to run sendmail daemons. This is running on my
new(er) laptop, which is much faster and has much more memory than my
old 75MHz 40MB laptop, so maybe I can afford the foot print. But...
The queue runner for the client queue is apparently unwilling
to move things to the main queue unless I'm on line, so I can't do
that in advance. (Perhaps it wants to qualify the target domains, but
why, isn't the main daemon just going to do that again? And since I
define a smart host, don't I really want to put such qualification off
on the smart host?)
Despite the fact that I'm then on line when the client queue
gets run, it still shifts things to the main queue, rather than
passing it on to the target (or smart host) smtp ports itself. (Maybe
since it's not root it can't authenticate itself to the remote MTA?)
[It is probably a good thing that the outgoing mail has to be
processed by the main daemon, since the sm-client daemon uses a
different configuration file (/etc/mail/submit.cf instead of
/etc/mail/sendmail.cf), which doesn't tend to have things like the
masquerading settings or the smart host. (Yes, there's a DS in
submit.cf, which I tried without improvemnt. But there's nowhere in
the submit.mc file like that in the sendmail.mc file that *invites*
specification of a smart host to a macro that will generate the DS
when the mc file is processed by m4 to produce the cf file. Similar
for the masquerade rules.)]
So I have to be on line when it runs the client queue. I
either need to have be on line a long time, have the daemon running
the queue very often, or have something that I can invoke in
/etc/ppp/ip-up.local to run the queue *NOW*. sendmail -q -Ac seems to
serve the last purpose, but I sometimes seem to have to run it twice
to have it take effect??? Then after that happens I need the main
queue to run, with similar options. sendmail -q still works for this,
but also sometimes seems to have to be invoked twice??? (Maybe it
needs to lock a file that is occasionally locked by the main daemons.
I guess I should try it without the main daemons running. Except that
IIRC the client queue runner won't deliver to the main queue unless
the daemon's are running.)
So I'd be happy with suggestions as to how to do any of:
Get the client queue runner to deliver to the main queue when
I'm not on line.
Get the submitting invocation of sendmail to talk to the
main daemon via TCP/IP to put the stuff in the main queue, rather
than putting it into the client queue.
Get the client queue runner to deliver mail directly from the
client queue to the smart relay host when I'm on line. Preferably
when invoked from ip-up.local, rather than at daemon queue run
intervals. (I'd have to know how to cleanly add the masquerading
stuff to the submit.mc file. Apparently RH regularly regenerates the
cf files from the mc files to keep me honest.)
Get the main daemon to also run the client queue. (sendmail
*will* run multiple queues, after all.)
Get a hand (script - non-daemon) invoked sendmail to run the
client queue, but otherwise use sendmail.cf (for masquerading and
smart host specification, and any other necessary re-writing). I
haven't tried this, but I'm close to knowing how: I believe that there
is a command line switch that specificies the queue director, and
which would hopefully override the setting in the sendmail.cf file.
I'd really like to find an approach using sendmail close to stock RH9:
Yes, I could switch to another MTA/MSA. But then I'd have to
learn to set it up, and I'm not sure that I get any guarantee that I
won't have similar problems. Also, if it's not a standard RedHat
package, then that's one more program for which I have to separately
track security updates (as opposed to just watching the RH site, which
I need to do anyway).
Any thoughts?
Bill
_______________________________________________
gnhlug-discuss mailing list
[EMAIL PROTECTED]
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
