Alessandro Vesely writes:
On 28/Sep/10 23:18, Sam Varshavchik wrote:Alessandro Vesely writes: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.This looks more reasonable. [...] -skipif looks cleaner. Also, the lookup will be skipped anyway, if its environment variable is already set, so this is backwards compatible.That's also my opinion. (It would be nice to hear some other user, though.)Do we need an additional comma to specify whether the list is (supposed to be) IPv6 capable?I don't think it will be necessary. IPv6 addresses should automatically format an IPv6 query. An IPv6-formatted query to an IPv4 list will be quietly ignored, DNSBLs already get a lot of crap queries, and they should return an NXDOMAIN by default.Matthias Leisi said list.dnswl.org is also planning to do IPv6, "to adapt to the changing landscape of whitelisting", and "implementation should start towards the end of Q1/2011 the latest."In order to avoid noise, we may assume as a rule --until a counter example arises-- that white lists do IPv6 while black ones don't, however coincidental it may be. In any case, we cannot do IPv6 queries until they publish their syntax. (I've found an "ugly example" in http://tools.ietf.org/html/rfc5782#section-2.4)Another difference between "-block" and "-allow" may be to change the default variable name to something different from BLOCK, just to avoid rude surprises.
The logical choice, of course, would be ALLOW.In that case, the logical default for -skipif would be "BLOCK,ALLOW". I think this provides meaningful defaults and minimizes the number of settings for the most common use cases.
This would be syntactical sugar. couriertcpd doesn't know anything about the daemon it spawns for each connection. couriertcpd would use this to set a private list of environment variables: _HEADER1="Blacklist: <DNSBL message>" _HEADER2="Whitelist: <DNSBL message>""<DNSBL message>" is the content of the relevant environment variable, including substitution of '@' with the IP number, correct?
Yes, couriertcpd already constructs the message, either from the DNSBL itself or by providing a stock message of its own.
courieresmtpd can read these variables from the environment, prefix each one's contents by "X-DNSBL-" and prefix it to every received message. It would also need to take any existing "X-DNSBL-" header in the received message and rename it to "X-Old-DNSBL-".Renaming can be done conveniently in submit, along with "Old-Return-Path" and "Old-Received-SPF".
Yes, I see that. This would mean that handling of the environment variables from couriertcpd would need to be done in submit rather than courieresmtpd, and arrangements will have to be made to preserve the environment variables for submit. It makes no sense to have similar functionality in two places, and to be consisted it would have to be Old-X-DNSBL.
pgpGR9kU6aBcS.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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 [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
