Milter-greylist

--- In milter-greylist@yahoogroups.com, "l_facq" <facq@u...> wrote:
> --- In milter-greylist@yahoogroups.com, manu@n... wrote:
> > l_facq <facq@u...> wrote:
> > 
> > >  i have think to this : 
> > > 
> > >  using a hash function like md5 on ip/from/to info 
> > >  could be a good mean to
> > >  - speed up (to check) the matching process
> > >  - limit memory fragmentation (compared to futur string
allocation in
> > > replacement of the fixed ADDRLEN siwe)
> > >  - limit memory consumation
> > >  - limit .db size and speed up dump/reload process
> > 
> > milter-greylist supports regexs matching, you can't do that if you
store
> > hashes.
> 
>  as far as i undestrand/imagine the process, i think that this regex
> matching could be done *before* hashing
> 
>  1 regex match on from/to => exit if ok
>  2 hash
>  3 search this hash in db
>  4 if found => mail ok
>  5 not found => create an entry
> 
>  i didnt look all the process in detail, so may be i'm wrong

 well, all regex functions call are in except_ fuctions
 and except functions are only call from milter-greylist.c : 

milter-greylist.c:      if ((priv->priv_whitelist =
except_sender_filter(SA(&priv->priv_addr),
milter-greylist.c:      if ((priv->priv_whitelist =
except_rcpt_filter(rcpt,
milter-greylist.c:      except_init();

 this checks are done when all info are available, but after
 only the hash is needed - in the db in particular

 so, hashing the infos is not a probleme in regards with regex matching.

> 
> [...]
> > greylist walk, it's the text dump. I guess it could be solved by
> > partially dumping to multiples files, or by using a real database
> > backend.
> 
>  on the fly compression (zlib) could be an easy way reduce disk access
> (if this is the bottle neck).
> 
>  LF.
> 
> --
> Laurent FACQ - Réseau REAUMUR / Université Bordeaux I