From: Craig Sanders (no email)
Date: Wed Dec 01 2004 - 00:58:44 EST
On Tue, Nov 30, 2004 at 11:44:23PM -0500, Victor Duchovni wrote:
> On Wed, Dec 01, 2004 at 08:58:08AM +1100, Craig Sanders wrote:
>
> > would it be possible for postsuper to be able to REDIRECT a queued
> > message, same as an access map or body/header checks rule can do?
>
> No,
i know postsuper can't do it now, i'm asking if it's *possible* (as in, "there
are no technical or design reasons why it is *impossible*") for it to be in a
future version.
> but you can put the message on hold, postcat it, and re-inject it with
> a new envelope via sendmail(1), then delete the held message.
that wouldn't work.
the message would be tagged by amavisd/spamassassin and would be held
again.
how does REDIRECT on the RHS of an access map do it? i assume it just
changes the recipient address in the queue file, it doesn't reinject the
message with a new envelope.
so, is it theoretically possible for postsuper to do this, or is it too
late in the game for such tricks to be played?
<digression>
the only way i can think of to make it work without a redirect function
in postsuper is to reinject with SMTP to a separate smtpd running
on, say, 127.0.0.2 that had all content-filtering and header_checks
etc disabled. seems like massive overkill to run a separate smtpd
just for this, and to have the script be an SMTP client complete with
error-checking if it was possible for postsuper to do it.
reinjection also changes the message slightly (extra received headers
at minimum), which is undesirable if you are redirecting to an sa-learn
alias or to a spamtrap address.
</digression>
> This is what postsuper would have to do, and it is not clear that
> there is any benefit in bolting this into postsuper, since a simple
> shell or Perl script will do just as well.
a simple shell/perl script can do a bad emulation of "postsuper -d" and
"postcat" too, but it's better to use the provided facilities than to
make assumptions about the structure of the spool directories (which may
change) or the format of the queue file (which may also change).
the point is to provide simple tools that other programs (and shell
users) can use to examine or manipulate the queue in a safe and standard
manner. when tools like this exist, users will find uses for them that
the original author never would have thought of....or doesn't have the
time or inclination to implement themselves.
my q* programs are a classic example. people have wanted a queue browser
for years, but nobody had written one. i started off writing tiny shell
& perl script tools called qv (postcat a queue-id) and qvl (postcat a
queue-id into less) long before postcat had the "-q" argument (before
then you had to use find in /var/spool/postfix to identify the exact
filename), and (qrm to delete a queue-id, again using find) before
postsuper even existed. eventually i discovered the Curses::UI perl
module and wrote the qvmenu curses-based queue browser.
when postcat improved and postsuper arrived, i modified qvmenu to take
advantage of what they could do rather than implement their features
internally....because the Right Thing<tm> for third-party scripts like
mine to do is to use the provided standard interface.
dunno about other people, but i've wanted an easy command-line tool to
bounce a queued message for years. redirect would be very useful too.
craig
-- craig sanders <> (part time cyborg)
|
|
|