Quick recap: when a dynamic routing filter is specified for a
print queue, the job is sent through the normal 'if' filter even though
the detination is another queue. This is the behavior I might expect from
a bounce queue, but it was a surprise in this case.
In certain situations (determined by my routing script) I want a
queue to be able to retain/print normally or redirect the job to another
queue. If the job is to be printed normally, I obviously want the filters
to be run. If the job is to be redirected, I think it shouldn't be
filtered (unless I specify lpd_bounce, or some such).
I reported earlier that I thought that specifying lpr -l or lpr -b
would short circut this particular behavior. I was mistaken.
Is this behavior intentional? Is it worth fixing? If I manage to
wade through what is possibly the most complicated portion of LPRng, would
a patch be accepted? Does it make sense to do things as I suggest? Is
there a better way to get what I want?
Specifically, I'm trying to use the dynamic routing facility to
implement a local security policy based on information in the job. If the
job passes my tests, I want to let it print to the named queue. Otherwise
I want to send the job elsewhere (but not reject it outright, as per
lpd.perms).
-----------------------------------------------------------------------------
YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST
The address you post from MUST be your subscription address
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
