[Mimedefang] Issues with porting MIMEDefang to another MTA

David F. Skoll dfs at roaringpenguin.com
Tue Apr 1 09:10:01 EST 2003


Hi,

I've been thinking some more about this.  There are some serious
difficulties.

I require the following functionality from MIMEDefang:

1) filter_relay, filter_sender, filter_recipient
2) add/delete/change headers
3) accept/bounce/discard/tempfail messages
4) replace message body
5) re-submit split-up message for filtering (stream_by_* functions)

There are also a couple of ways to implement MIMEDefang for another MTA:

1) Modify the MTA source code to include milter-like functionality
2) Write a proxy that accepts connections on port 25 and relays it to
   the real MTA.

Approach (1) has the disadvantage that we have to mess with the
internals of another MTA's source code, and such changes might not be
accepted into the mainstream source.  However, it makes it easier to
get all the functionality.

Approach (2) is nice because it's MTA-independent -- one proxy will
work with any MTA.  On the other hand, you then lose the ability to do
access control in your MTA (all connections appear to come from
127.0.0.1 or whatever), and worst of all, requirement (5) means you
have to implement queueing and retransmission in the proxy.  In other
words, you end up re-implementing most of an MTA anyway.

So for now, sorry.  Sendmail is it.  Milter is just too nice and
convenient.  If/when other MTA authors implement a filtering API as
flexible as Milter, I will revisit the issue.

Regards,

David.




More information about the MIMEDefang mailing list