The amount of work to be done to make qpsmtpd deliver properly to local
and remote users may be more than it's worth?
Not particularly... You've already got the info as to whether it's to
be relayed or not (though I guess you need to check whether it's to be
relayed but to be delivered locally).
The big problem is what do you deliver to. procmail or imap or ... the
list is endless, so it becomes very custom to your setup.
You can probably already do this with a slight modification to one of
the queue/* plugins now and just hand off to any of the local delivery
agents. Better yet would be to separate into a
queue/* and
delivery/* architecture and for example, queue/smtp-forward would
actually move to delivery/smtp-forward (since it's not technically a
queuing mechanism).
Then it's a matter of adding plugins for the delivery mechanisms. That
would take care of receiving from remote hosts (assuming we want to be
lazy and never queue locally and always proxy or deliver locally).
That still leaves the matter of local queuing though (for your local and
authenticated users). You can probably use one of the CPAN modules that
manipulate queues for one of the existing MTA's for
insertion/modifications - then the only task left is a module or daemon
to process those queues.
Personally I am happy with queue/postfix and running postfix on
127.0.0.1 solves the problem nicely.
Tim
