[Mimedefang] Issues with porting MIMEDefang to another MTA

[Justin]

I had looked at integrating MIMEDefang with qmail using a replacement for
the qmail-queue which I intended would call MIMEDefang in similar ways to
the milter.

What I eventually realized I could do is run both sendmail and qmail on
the same machine. I found a pop-before-smtp program that was able to catch
IMAP and POP3 authentications by monitoring the mail logs and update an
authentication db which sendmail checks using a CF hack.

Then, to use qmail for local delivery, I hacked up a custom sendmail
mailer which calls the qmail-inject program. This has been working stellar
for me.

What I suspect would be easiest for all attempting this, worried out
security, is to run sendmail non-root using NAT to give it port 25, and
then have it use a custom mailer to deliver to your in-house MTA. You have
the benefit of a full-featured MTA with superb
routing/handling/content-scanning capabilities without having to use it
for your organzational mail needs.

In my case, I really wanted/needed to use qmail-ldap with clustering
across multiple sites. qmail simply offered things nicely that sendmail
did not. However, sendmail is my favorite front-line MTA, and I found that
rather than force one to do what the other did best, I would just
integrate them :)

This is a clip of the magic from my .mc file:
MAILER_DEFINITIONS
Mqmail,         P=/var/qmail/bin/qmail-inject, F=msDFM:/|qShP,
S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrFromSMTP
                T=DNS/RFC822/X-Unix,
                A=qmail-inject -a -f$f $u

If you have any thoughts or questions, feel free to ask. As I am not an
experienced sendmail hacker, I am especially intersted in comments on my
mailer definition.

-Justin


On Tue, 1 Apr 2003, David F. Skoll wrote:

> 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.