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. >>>> 2. >>> >>> 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. > > It doesn't. It only needs to write new headers to submit before it > sends the original message body. Ah, I hadn't thought about that. That way, it will correctly place the new fields on the top (right after Courier's "Received", IIRC). > It will need to mask off any existing headers with the same name, > though. This is fairly easy and does not require complicated > parsing. Agreed, using a prefix makes it clear. > I think that similar to -skipif, you can specify variable name/header > name pairs by a new option: > > -header BLOCK,Blacklist \ > -header ALLOW,Whitelist > > 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? > The environment variables would be named _HEADERn, beginning at 1. > > 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". > A global mail filter could then look for "X-DNSBL-<name>" headers. This looks fine to me. The name will have to be confirmed in the filter's config file anyway. For a nit, the "B" in "X-DNSBL-" is wrong. RFC 5782 uses "DNSxL", but such term doesn't seem to be widely used outside the ASRG. >> 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. > > The environment is sanitized before submit gets invoked. Yup, that's why it may be cool to dump it. Nevertheless, bash adds some variables for its own use. I collected the parenthesized name list above from /proc/<pid>/environ. >>> 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. > > An ISP allocates a /64 for each customer. A /64 is a reasonable > starting point. The customer may connect different hosts to that block, and, say, only use the ones equipped with a secure OS for sending mail. A smart DNSBL should only list any infected hosts, or actual spammers, for this neighborhood. -- ------------------------------------------------------------------------------ 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
