[Mimedefang] Reject vs Drop and MX

[Troy Carpenter]

Richard,

I think you have made this more complicated than it should be.  See my
last reply in this thread (the one where I forgot to change the SUBJECT
line from the digest...doh!).

I finally just replaced my global variable with a function.  In that
function I return true if the hostname matches my MX (and therefore I need
to check the RECIEVED header just before that one), or false otherwise and
let the processing go on as normal.

I have the same algorithm as before, except I have avoided the global
variable AND the messy file operations.

Troy Carpenter
troy at carpenter.cx


> Date: Sat, 25 Sep 2004 11:00:30 -0700 (PDT)
> From: Richard A Nelson <cowboy at cavein.org>
> Subject: Re: [Mimedefang] Reject vs Drop and MX
> To: mimedefang at lists.roaringpenguin.com
> Message-ID:
> 	<Pine.LNX.4.58.0409251050340.22304 at hygvzn-guhyr.pnirva.bet>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Fri, 24 Sep 2004, David F. Skoll wrote:
>
>> On Fri, 24 Sep 2004, Troy Carpenter wrote:
>>
>> > 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.
>>
>> Don't do that.  Your filter will suffer random and unpredictable failures.
>> See the section  "GLOBAL VARIABLE LIFETIME" in the mimedefang-filter
man page.
>
> Hrm, I though about this and came up an approach that seemed to avoid
the state issues - but isn't quite robust; and I'm stumped !
>
> The idea is that I set a global (and constant) variable at the top of
the filter, and at return time, decide if the mail should be
> rejected(direct) or discarded(via mx or mailing list)
>