On Wed, 24 Mar 1999, Sam wrote:
> Scott D. Yelich writes:
> > I came back to it and the mail gives me some insight -- but what is done
> > in the mail isn't documented anywhere. Oh, show me how it's done and
> > give me a reference to where multiple -r's is documented in the manual
> > and I promise I'll unsubscribe from this list and never say another word
> > to it.
>
> Please explain how you expect to find documentation for something that
> doesn't exist. The last time I checked, rblsmtpd didn't seem to implement
> multiple -r options, therefore I'm at a loss to understand how you expect
> to document a non-existent fact.
Sorry, my statement was poorly phrased.
``Please give me a reference in the rblsmtpd package where the use of
more than one RBL lookup is used.''
I asked another poster on this list to give me an example of where else
in UNIX a program calls itself as a standard practice. He couldn't come
up with one. He provided a *working* example, but just because my car
can probably go 30 miles an hour BACKWARD, it doesn't mean that (1) I've
tested this or that (2) it was meant to. My opinion stands that a
program calling itself multiple times is *not* inherently intuitive and
it should be documented! The other example the poster gave was of a flow
control statement in the csh programming language (which was incorrect,
btw.).
> rblsmtpd's docs describe rblsmtpd's functionality. Your problem is that
> you did not realize that what you want is to chain multiple invocations of
> rblsmtpd. You can argue that that's a rather stupid thing to do, but you
> can't argue that something which doesn't exist isn't documented. Well,
> duh...
er, close. It wasn't the fact that I didn't know it could do that -- I
didn't realize that was how it was supposed to be done! I'm not going to
argue over multiple -rs or multiple instances now that I know it's
supposed to be multiple instances. I'll just wait for the next poor sap
that runs across this and I'll post ``I told you sos'' ...
> > > > Just for curiosity? How would you suggest learning more about qmail > > > who
>has installed qmail to be able to install the qmail-uce? It's really
> > > > too bad it's written in c++ and not in a more standard language.
> > > The qmail-uce patch is not written in C++.
> >
> > *sigh* Perhaps it's possible to run the qmail-uce without the
> > dependencies that it has. Perhaps not. But, when I was installing
> > the dependencies for qmail-uce, I was told that my compiler didn't
> > create c++ files.
>
> I was almost afraid to ask what in blazes you are talking about, but I
> think that I've finally figure it out.
>
> What you are referring to as a 'dependency' is a separate package, but the
> patch itself can be easily adapted to use any filtering engine, even
> procmail, instead. In fact, I used to include instructions on using
> procmail as an alternative, at some point in the fact. However, I felt
> that procmail is rather broken in that regard, and was giving people a
> nasty
> headache.
Right... but procmail gets bad-mouthed. maildrop is the prescribed
medicine... but we all know that one doesn't need c++ to get qmail-uce
going. nope.
Scott
