On 28/Sep/10 00:00, Sam Varshavchik wrote: > Alessandro Vesely writes: >> I think we may additionally need two things: >> >> 1. A mechanism to skip performing some lookups in case some other >> ones already succeeded. Currently, only if a given variable is >> already set, the corresponding lookup is skipped. > > This seems trivial. The lookup can also be skipped if some other > variable is also already set. The whitelists can be arranged to be > looked up first, followed by blacklists.
You mean "can be arranged" by properly setting the configuration file? Blocklists are currently checked respecting the order they have been defined. > The real challenge here is to come up with a sane syntax to specify > all of this. Hm... one possibility is to modify the "-block" syntax by appending a list of environment variables that prevent the lookup. E.g. -block=zen.spamhaus.org,BLOCK,"550 Reject ip=@",ALLOW,ALLOW2 \ -allow=swl.spamhaus.org,ALLOW where "-allow" has the same syntax of "-block", but new entries are pushed onto the head of the list rather than appended to its tail. An alternative is to define skiplists explicitly, e.g. -allow=swl.spamhaus.org,ALLOW \ -block=zen.spamhaus.org,BLOCK,"550 Reject ip=@" \ -block=some.other.example,BLOCK2 \ -skipif=ALLOW,BLOCK,BLOCK2 In this case "-allow" is exactly a synonym of "-block", because it feels ugly to say "block" for a whitelist. In the future, the SWL may have IPv6 capabilities --according to their techfaq, "IPv6 handling is not yet active. Spamhaus estimates IPv6 service starting in 2011". Do we need an additional comma to specify whether the list is (supposed to be) IPv6 capable? >> 2. A mechanism to pass (some of) these variables to global filters. >> (Values /from/ global filters can be set via header fields, but >> variable-passing can also be devised to work both ways.) > > I think that the best way is to record this metadata into an > additional header, than the filter can check. Thinking it over in my > ahead, I think this would be the easiest approach, and all the change > can be bundled in courieresmtpd, so that the command line sendmail > injection point, or the shared codepath between the two, does not need > to be overengineered for that. At first glance courieresmtpd doesn't seem to delve into distinguishing header from body. At any rate, yes, adding to the header may work for this specific case. The additional field, say X-Whitelisted-By: swl.spamhaus.org will remain attached to the message, and thus might also be used by client software to avoid discarding important messages. However, this header field has to be guarded against cheats already present in the original message. If the field name is specified on the command line, e.g. as -allow=swl.spamhaus.org,ALLOW,"X-Whitelisted-By: swl.spamhaus.org" checking for cheats may become quite cumbersome. A more generic approach could be to dump the whole environment to the ctlfile, in submit, just before closing it and only if filters are enabled, prepending, say, COMCTLFILE_ENVVAR before each line. This would also work for a bunch of corner cases, e.g. a filter wondering whether an authsmtp message came in via the MSA port. This may result in a size increase of around 1300 bytes, at mines; some known variables (PATH, SHELL, SHLVL, PWD, _) may be omitted. > I do not understand what the problem is. Wildcard DNS entries will > work fine. You just put a wildcard record for the /64. End of story. IMHO, even assuming that such granularity is not too coarse, the remaining 64 bits still provide for a too huge address space for the whack-a-mole game. But then you're right that someone may still run an IPv6 DNSBL, and it seems wise to plan a syntax that would allow to use it. > *.00.00.27.0c.03.05.01.20.blacklist.example.com TXT "Whatever" > > This presumes that, for consistency, hex is used at the octet-level > granularity for IPv6. Decimal can be used equally well. Probably that's the kind of decisions Spamhaus still has to make, since they have not given an IPv6 query example yet. -- ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
