Re: [courier-users] Whitelist filtering, including a draft patch

[Alessandro V. <ve...@ta...>]

On Thu 24/Jan/2013 02:00:15 +0100 Sam Varshavchik wrote:
> Alessandro Vesely writes:
> 
>>   -allow=zone[,varspec]...
>>
>> [...]
>> Now for passing the results to global filters.  In 2010 we thought of
> 
> I still think -allow is ok, but I don't see much need to do anything
> with regards to the headers. If the purpose is to allow per-recipient
> mail filtering, then environment variables set by couriertcpd should
> be accessible in rcptfilter and smtpfilter-based scripts for that
> purpose, and it's better to do it there.

Global filters, however, cannot.  My initial idea was to use ctlfile
records to pass values to --and possibly among-- filters.  It's you
who said it's simpler to use the message header (there were traces of
that argument quoted in my previous message.)  An advantage, in large
systems, is that it makes it possible to pass values from a boundary
MTA to an internal MTA.  In addition, using a standardized header
would allow independently developed filters, e.g. SA, to reuse that
result rather than querying the list again on their own.

Oh, I forgot to mention to add, say, "opt BOFHARGUARDATOMS=2".  That
is the number of rightmost "atoms" to be kept from config-me:  The
lower the safer.  For example, if me is host.example.com, 2 yields
example.com, and an A-R header purportedly by whatever.example.com
gets renamed.  That's a possible implementation of RFC 5451.

> And I'd rather keep it simple, and avoid the need to bring in PCRE.
> I'm not even quite sure why that's necessary. A DNSBL that offers
> multiple results should do it by returning pseudo-IP addresses, which
> couriertcpd should be able to handle.

Yes, that was my initial approach as well.  Lists deliver their
content as A records in the 127.0.0.0/8 range, but each list has its
own encoding.  Dnswl.org, for example, encodes the score is the last
byte, valued 0-3.  After a few attempts at defining a suitable syntax,
I realized I was reinventing regular expressions, so I turned to the
real thing.  Some decisions, e.g. SPFALLOW, ought to be made that early.

Would PCRE unduly aggravate tcpd's footprint?  And how'd you compare
its cpu cost to the time/bandwidth cost of the query itself?