[milters] Archive

Lists Index Date Thread Search

Article: 669
From: Taylor, Grant
Date: 2005-07-28 14:50:16 -0400
Subject: Re: White list pattern matching...

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support

> Using key/value pairs there is no way to specify any form of wildcard 
> matching in the key. Its simply not possible to derive a key to lookup 
> with from the email address. You need to know the patterns before the 
> keys can be generated.

*nod*  I was afraid of as much.

> Two possible methods:
> a) Create a separate file containing a list of regex/value to test. 
> Means restarting the milter when this file changes to reload patterns 
> into memory. I dislike this solution for some reason that escapes me now.

This does sound like a kludge.  Seeing as how the patterns that I would have to match are
a series of numeric strings seven, five, and ten digits long and very unpredictable it
would be VERY inefficient to try to cover all possible permutations in the included file. 
Thus this solution is really not much of one at all.

> b) More of a kludge, but keeps everything central in access.db. I have 
> considered a special lookup something like, where the right hand side 
> would be handled specially:
> milter-NAME-from:domain.com	
> 	/pattern/action /pattern/action ... [default-action]
> or maybe
> milter-NAME-TAG:sender@
> 	/pattern/action /pattern/action ... [default-action]
> For example:
> milter-sender-from:yahoogroups.com	
> 	/goof-[0-9]+-ball@/REJECT  /tosser-[a-z0-9]+-user@/REJECT OK
> milter-sender-connect:192.168		/.0.[0-9]+$/OK REJECT

This may be the ""kludge that I'm needing.  I would think that you would want to
implement something like this:

	milter-date-From:/sender-[0-9]+-[0-9]+-[0-9]+-gtaylor=riverviewtech.net@returns.groups.yahoo.com/OK	REJECT

Or possibly something more like:

	milter-date-RegEx-From:sender-[0-9]+-[0-9]+-[0-9]+-gtaylor=riverviewtech.net@returns.groups.yahoo.com	OK

This way you would have a different key in the AccessDB to indicate that you needed to run
a regular expression / pattern match on the user-address / user part / domain part of the
email address.  I think I would also not have a default action on the filter, just what
would be expected as the action to take if this pattern did match like the rest of your
present AccessDB entries.

Another option that you might consider doing would be to implement something similar to
milter-cli to allow all milters (milter-date in this case) to call a command line to
decide whether or not to process the email that is coming through.  If you had something
similar to "milter-date-cli-From:<milter-cli parameters> OK" where I could
write an external program to return the results to indicate whether or not milter-date
needed to process the email or not would be great.  This would allow me to augment
milter-date (and others) to handle the special addresses.

> Essentially I could implement some form of wildcard matching (either 
> regex or simple glob-like) by selecting a pattern set based on one of 
> the existing key lookups for address-local-part, address-domain, 
> client-ip, client-domain.

For what it is worth I would rather see regular expression support verses simple (f)grep
style pattern matching.  However having said that (f)grep pattern matching would be better
than nothing and I don't think it would be to difficult to implement (verses regexs).

> The actual syntax I've not really considereded in depth, but it has been 
> a rough idea I've been toying with. However, there would be a 
> performance overhead in doing this and one of the reasons I've put the 
> idea off.

I think having a different tag that the milters would look for in the AccessDB would help
reduce the overhead in such that it would not be called for any emails that did not
specifically need it.

Grant. . . .

Lists Index Date Thread Search