Milter-greylist

manu@... (Emmanuel Dreyfus) writes:

> [e-mail addresses are truncated to 32 chars]
>> It triggers a problem when using regexp's in the configuration
>> file. E.g.
>> 
>> | rcpt /spamtrap-prefix.*@.../
>> | rcpt /maillists+foobarnet.blablub.com=mydomain.com@.*/
>>                                ^
>> would *never* be matched as no tested rcpt will have the characters
>> after the marked place (^). That's a very confusing behavior and it is
>> documented nowhere (afaik).
>
> Hum, that's a real problem. 
> I see several way of fixing the problem
> 1) raise the truncation to a higher value (64? 128?)

Longest 'FROM' addresses are around 90 characters (maillist bounce-addresses)
here. So 128 seems to be a good value.


> This impacts the memory usage.

* Is this really a problem with nowadays hardware (1GB+ RAM)?
* Why not allocate the needed memory dynamically?


> 2) ensure regex are matched on the address before it is truncated

Sounds good, and is probably the best choice. Doing this would allow to
store hashes in the database: the comparisions with settings in the
configuration file (rcpt/from) happens on the real addresses (pointers
given by the milter-interface), and the lookup in the database is done
with hashes.

This would make milter-greylist very efficiently:

* generate *one* hash over the entire triple, e.g.
  | sha1("%s#%s#%s", relay, from, rcpt)  -->  40 bytes ASCII resp. 20 bytes binary
  - I would recommend sha1 over md5 since it is more collision resistent
  - to stay at case insensitive comparisions, transform everything to
    lower- or uppercase
* order the pending- and auto-whitelist 
* do a binary search over these lists (insert is more expensive than
  the current linked-list implementation, but there should be far more
  'lookup' than 'insert' operations)


Advantages:
* reduced memory consumption (20 bytes + timestamp per entry)
* faster (O(log n) for lookup)
* enhanced privacy


> 3) Document it as a known problem

A last resort solution... ;)




Enrico