[Mimedefang] Architecture question - Using MD/SA on external MX'es

[David F. Skoll]

On Wed, 28 Aug 2002, Andy Miller wrote:

> 1. Must not bounce spam to valid recipients , only mark in
>    headers.

No problem; that's the default.

> 2. Must be configurable on a per-user basis, preferably:
>    - opt-int/opt-out of filtering
>    - whitelists
>    - blacklists
>    - spam "point" threshold

That's tricky.  What if a message comes in for 2 people with
different preferences?

> 3. It must operate in a "fail stop" way.  Losing spam
>    filtering is acceptable, rejecting incoming mail is not.
>    (even if not out of the box, we can design this in)

That's OK.

> 4. It must scale to our volume of mail. (Approx 100k/day,
>    typical uneven load).

That's OK.

> 5. The preference is that it will be able to survive a
>    concentrated dictionary attack.  We have had _several_
>    attacks in the last several months where a spammer will
>    cause 50-100 open relays to send mail at us as fast as
>    they all can, using iterative/dictionary type usernames.
>    (aa@ ab@ ac@, etc.)

That's OK -- you can do a lookup in the filter_recipient function.

Actually, I have a (commercial) product which does almost everything
you want -- it's called CanIt.  The only thing it doesn't do is per-user
preferences, and that's coming up in a new product called CanIt-ISP.

> Regarding the second point, it looks like there is some good
> contributed code for managing user prefs for SA via a CGI.

You have to be careful -- see above if an e-mail comes in for more than
one person.  You have to stream and resend it -- see stream_by_recipient().
It's part of MD.

> Is SpamAssassin a cheap enough operation once MD is already
> invoked to bother checking for user's whitelists and
> blacklists before to call to SA?  Or just let SA with it's
> userprefs patch handle it?

SA is expensive.  Anything you can do to avoid calling it is a win.

> It is especially bad for us because our MX'es live
> outside the firewall, and do not have the lists of valid
> users; they accept all mail and then forward it to our
> mailhub.

Ouch.  But if you have a way to look up valid users from Perl, then
you can use filter_recipient to handle this.

> The way we are thinking we can solve this is to use an
> extension of the user-prefs database idea.  We would like to
> write another milter that is called right after RCPT to:.

MIMEDefang has this built in.  You can also configure sendmail to
throttle the connection after a certain number of RCPT TO: commands.

Overall, your architecture is sound.

Regards,

David.