Patrick Ben Koetter:
> * Wietse Venema <postfix-devel@postfix.org>:
> > Patrick Ben Koetter:
> > > Would it be possible to implement a new postqueue options that prints the
> > > top
> > > senders currently in queue? Something like 'postqueue -t':
> > >
> > > 109 sen...@example.com
> > > 7 some...@example.com
> > > . ...
> > >
> > > Of course I can do that with sort, awk, uniq etc.
> >
> > The current output format was cloned from sendmail, which was OK
> > to get started, but was not meant to be the only form.
> >
> > To provide other output forms, I think that the showq daemon should
> > spit out raw data, and that the formatting should happen in a client
> > program. Someone else on the list already did an attempt in that
> > direction a few months ago.
>
> I may have been that person.
Digging in my email archive, I found an off-list thread where I
discussed this with Markus Benning. That was near the end of
September.
I don't know how far he got; but the idea was that this would move
the formatting from the (showq) server to the (postqueue) client.
It is mostly a matter of moving the formatting loop from showq to
postqueue, plus sending the sender/size/recipient/etc information
over the showq/postqueue socket.
This internal communication uses Postfix-style records. For the
external interface to other programs, a different format would be
more suitable. I don't know if JSON is still cool these days, but
that would be a possibility. Transforming the Postfix-style record
stream into something else should not be difficult.
> > One option would be for Postfix to output just the raw data,
> > that it becomes more useful for processing by other programs.
> > How can I help?
I think choosing an appropriate external record stream format and
providing code that "consumes" that stream.
Here is a straw-man design for the showq-to-postqueue stream. It
has records like this: each message report starts with a queue name
record, and is followed by one (*1 xxx) or zero-or-more (* xxx)
records of type xxx.
*1 queue name
*1 queue ID
*1 UNIX-style arrival time
*1 message size in bytes
*1 sender envelope address
* (
recipient envelope address
reason for deferral
)
I suppose that the same order of "records" be used in the external
stream. There is no good reason to complicate the implementation.
Other record types might be added (DSN atributes, SMTPUTF8, etc.),
but a good program will ignore record types that it does not
understand.
Wietse
