On Friday, March 9 at 02:40 PM, quoth Steve Brown:
Is it possible to change the order of the programs called by
tcpserver to do something wacky like:
tcpserver {options} <host> <port> \
fixcrio \
qmail-smtpd {options} \
rblsmtpd {options} \
qmail-smtpd {options}
Nope. qmail-smtpd does not call the program given in its arguments
(well, the smtp-auth patch can make it do so to check the
authentication, but that's a restricted case, and rblsmtpd wouldn't
apply anyway). qmail-smtpd receives email, and (essentially) nothing
more.
If you wanted to do something like that, you'd have to separate the
authentication from the reception, kinda like the way qmail-popup is
separated from qmail-pop3d (i.e. you'd need a separate program to do
the authenticating). Quite doable, but you'd have to write it
yourself. :)
Would setting the appropriate env vars by authenticating in the
first qmail-smtpd allow tcpserver to skip calling rblsmtpd?
I don't think you're quite understanding how this works. tcpserver
calls only ONE program: the first thing listed that isn't recognized
as one of its own options. Everything else is merely passed as options
to that program. So, when you do:
tcpserver {options} rblsmtpd {options} qmail-smtpd
What happens is that tcpserver runs rblsmtpd and nothing else.
tcpserver knows nothing of qmail-smtpd or rblsmtpd or anything else;
all it knows is that the string "rblsmtpd" is not an option that it
recognizes, so it's going to assume that it must be a program and
attempt to run it. Everything after that is assumed to be options to
that program, so it's as if you had run rblsmtpd by hand like so:
rblsmtpd {options} qmail-smtpd
So rblsmtpd then runs, makes it's decision, and then runs qmail-smtpd.
Again, just like tcpserver, rblsmtpd doesn't know qmail-smtpd from a
hole in the ground, it just knows that the string "qmail-smtpd" isn't
an option that it recognizes, and so it assumes it must be the name of
the next program to run.
And, when tcpserver or rblsmtpd runs the program it thinks it has
found in it's list of arguments, it's done, it can do nothing else.
(In fact, the way exec() works on Unix, when rblsmtpd (for example)
runs that program (or what it assumes must be a program) it ceases to
exist and its memory is replaced by the program it exec()'d, i.e.
qmail-smtpd.)
It's not that tcpserver runs rblsmtpd, checks the output, and then
runs qmail-smtpd.
Or at least allow rblsmtpd to not perform the checks? Or will
tcpserver still call rblsmtpd regardless of what happens in the
other programs called before it?
Given what I said above, think about it. If you have the following
setup:
tcpserver {options} \
qmail-smtpd \
rblsmtpd {options} \
qmail-smtpd
What will happen?
Well, tcpserver will see the first "qmail-smtpd", won't recognize it
as an option, and so will attempt to run the following program:
qmail-smtpd rblsmtpd {options} qmail-smtpd
So now qmail-smtpd is running. It speaks SMTP to the network. It
receives email. It exits. It completely ignores its arguments (let's
ignore SMTP-AUTH for the moment), because it *never* does anything
with its arguments. Thus, rblsmtpd simply never runs.
~Kyle
--
Time is an illusion. Lunchtime doubly so.
-- Douglas Adams
pgpWnqKVvoVzy.pgp
Description: PGP signature
|