Re: [Exim] dnslists modification

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Wakko Warner
Data:  
Para: exim-users
Assunto: Re: [Exim] dnslists modification
> > I spoke to Philip in private email and I belive he prefered != (I originally
> > had =! since it was just a tad easier to code for). He also agrees with me
> > that this isn't a list in the normal exim sense as well.
>
> Yes indeed. I feel that if people see
>
> dnslists = a.b.c = ! 127.0.0.1, 127.0.0.2
>
> they will interpret that as being like all the other Exim lists. That is
> why I suggested using != instead. Of course, the above example is
> nonsense if interpreted as a "normal" Exim list because the address
> 127.0.0.2 matches the first item - so it can never match the second.


I agree.

> Negation in normal lists is useful only when the item that follow are
> wildcarded in some way so that the negated item is an exception to the
> wildcarding.


At the moment, I'm having a hard time trying to understand why you'd want
wildcarding for something like this. I guess it's because I wouldn't have a
use in it =)

> Somebody did mention the possibility of wildcarding, didn't they?
> Specifically, along the lines of
>
> dnelists = a.b.c = 127.0.0.0/29
>
> I'm not entirely sure that CIDR addressing would turn out to be all that
> useful here.


I would say it would depend on the RBL, but I wouldn't see it as very useful
unless RBLs used a larger range to describe why the host is blocked.

I see a bitmapped option to be more useful for something like this where
they use the bits to describe why a host was blocked. My entire reason for
the != patch was to allow hosts that were listed as dialup hosts, but block
everything else. So if a host is listed as dialup and open relay, they'd be
blocked anyway. I would allow if dialup was the *ONLY* reason they were
blocked.

> Current conclusion: If I implement the current != code, it provides a
> useful facility that people want. Furthermore, it does not lock out an
> extension in the future in which the list itself is interpreted in a
> more flexible way.


That's why I rewrote it. It's less intrusive and easier to understand.
Plus if it's incorporated, I wouldn't have to change my format in my own
.conf file =)

--
Lab tests show that use of micro$oft causes cancer in lab animals