postfix compatability?

[Leland J. Steinke]

Peter Bates wrote:
> Hello all...
>
>
>>mailscanner at ECS.SOTON.AC.UK 03/01/03 20:02 PM >>>
>>Exim is *fairly* easy to configure. I can probably give you some >help if you need it. Get Exim built first, then I guess we need to >set it up so that it listens on port 25, with postfix listening on >port 26. You will have to get postfix listening on port 26 >yourself, I don't know how to do that.
>
>
> Running Postfix still as I am, I can say the answer is in Postfix's 'master.cf' (this controls the transports, where main.cf controls mosts other things).
>
> There is a line in master.cf saying:
>
> smtp    inet    n       -       y       -       -       smtpd
>
> where 'smtp' is the name in /etc/services:
> smtp            25/tcp          mail
>

look in /etc/postfix/README_FILES/FILTER_README.  You can pipe to external
processes from within postfix to handle content filtering (this is what we do;
actually we invoke a program that converts the messages from postfix queue files
into queue files that MailScanner will understand).  You can spawn multiple
daemon processes to speak on non-standard ports (this is what is discussed in
the FILTER_README).  Or, you could just set up exim on non-standard ports and
let postfix forward to that port; exim could then send the processed messages
back on a different port for postfix to handle final queueing and delivery.
Anyway, the master.cf file is absolutely key to getting filtering to work with
postfix, however you choose to do it.


Leland

ps:  What is the problem with the "official" MailScanner/postfix connection?
Maybe we can help.  Postfix is VERY powerful, but it takes a couple of "aha!"
moments to figure out how to harness that power.  Julian has already said that
he does not want to build another MTA, so that pretty much removes my second
option above.  It does not make sense to run exim or another MTA on a
postfix-equipped box just so MailScanner will work; just run the non-postfix MTA
and be done with it, which removes the third option above.  There was a
reference to something like "Obtuse SMTPD" as a possible avenue of attack, but I
do not recall hearing the outcome of that one.  As I already said, we have
postfix create MailScanner-compatible queue files, through a perl script;
another perl script takes the processed messages and re-injects them into
postfix.  Postfix is designed to be as secure as possible, with multiple layers
of defense against software errors (either accidental or intentional).  Postfix
queues, and the files therein, are at the very heart of postfix and I would not
want to try to "spoof" them into something else.  This is why we decided to
ignore the issue entirely, make postfix run a program to create files for
MailScanner to process, make MailScanner give the processed files back to
postfix, and process millions of messages per month.

pps:  Having said all that, postfix has a "hold" queue.  From the postfix docs:
  "The hold queue is for mail that is frozen in the queue; no delivery attempts
are made until someone releases these messages with the postsuper command."
Maybe that would be a place to start?