[Mimedefang] Reject vs Drop and MX

[Troy Carpenter]

I have already done exactly what you are talking about.  I think I have
explained this before, but it's always good to be sure I can still explain
it if I have to.  This is the way I did it, but I'm sure there are other
ways.

1. Turn on filter_relay and filter_recipient checking.
2. In filter_relay() I do the following:
   * Check to see if the connecting relay is local. If so, accept with no
     further processing.
   * Check to see if the connecting relay is one of my known relays...
     that is, is it my backup MX, or my ISP's relay (I don't want to
     blindly accept SPAMs originating from others on my ISP).  If this
     condition is met, then I set a RELAY flag for later use.
3. In filter_recipient() I have all my checks.  This includes sender,
   recipient, relay (for my domain name), and RBL checks.  There is nothing
   special in this routine specifically for backup MXs.
4. In filter_begin(), I first check the RELAY flag.  If it is set, then
   I call a custom routine which opens the HEADERS file on disk and
   extracts the previous RECEIVED header (the one before my MX).  Using
   some regexp extraction, I pull out the hostname and IP address of the
   relay before my MX and send that information back through the
   filter_recipient() function and returns the result back to
   filter_begin().  If the result of that second trip through the filters
   is REJECT, then I discard instead of reject.

So the flow of a messages is this:
   filter_relay(): check for backup MX and set RELAY flag accordingly.
   filter_recipient(): Check RBLS, etc. and return REJECT, ACCEPT or
     CONTINUE as necessary. (Note backup MX always return CONTINUE since
     it should never be on the RBLs).
   filter_begin(): Checks RELAY flag and if set will find the relay prior
     to my backup MX and rerun that relay through filter_recipient.  A
     return code of "REJECT" at this triggers a call to action_discard().
     If RELAY flag is not set, then processing continues as normal.

One of the good things about explaining this is that I usually pull up my
mimedefang-filter file to help me explain, and I can see ways to improve
my implementation of the above description.

You can contact me off-list if you need more details than the algorithm
above provides.  I would be nice to have a routine built into mimedefang
that could fetch the previous relay information from the headers, but I
don't know what it would take to do that.  One question would be whether
or not mimedefang already parses the last RECEIVED header to get its
information, or is it passed to it via the MILTER interface.  The parsing
of the RECEIVED line is rather tricky because each MTA software formats
its strings a bit differently.

If you do reply on-list, you should know I am setup for digests so it may
take some time before I see any messages on this topic.

Troy Carpenter
troy at carpenter.cx

> Date: Thu, 23 Sep 2004 15:43:57 -0700 (PDT)
> From: Richard A Nelson <cowboy at cavein.org>
> Subject: [Mimedefang] Reject vs Drop and MX
> To: mimedefang at lists.roaringpenguin.com
> Message-ID:
> 	<Pine.LNX.4.58.0409231539060.28942 at hygvzn-guhyr.pnirva.bet>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>
> I've a few MX that aren't under my control, and have a few other
> machines that forward mail to me (also not under my control).
>
> I'm currently Rejecting (5xx) virus and high scoring spam, which
> will cause the forwarding MTA to issue bounces :(  However, the
> Reject works well for the direct connects.
>
> What I'd like to do, is extend the filter with a function to
> either:
> 	1) Drop the mail if received from a list of relay hosts
> 	2) Reject the mail otherwise
>
> Before I jump off the deep end and (poorly) re-invent the wheel,
> has anyone already done this (and can share the work) - or are
> other things for me to take into account in doing this ?
>
> Thanks,
> --
> Rick Nelson
> Life'll kill ya                         -- Warren Zevon
> Then you'll be dead                     -- Life'll kill ya
>