Alessandro Vesely writes:
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,ALLOWwhere "-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,BLOCK2In this case "-allow" is exactly a synonym of "-block", because it feels ugly to say "block" for a whitelist.
This looks more reasonable. Appending environment variables after the message string won't work very well. In some case the message string is not specified, and the one returned from DNS gets used. Furthermore, an explicit message string cannot contain commas. Quotes get parsed by the shell, the whole option setting is parsed as a single string, and there are plenty of message strings out there on the order of "550 Go away, and see http://whatever";. Banning a comma in the message strings will break many people.
-skipif looks cleaner. Also, the lookup will be skipped anyway, if its environment variable is already set, so this is backwards compatible.
service starting in 2011". 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.
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.
It doesn't. It only needs to write new headers to submit before it sends the original message body. It will need to mask off any existing headers with the same name, though. This is fairly easy and does not require complicated parsing.
At any rate, yes, adding to the header may work for this specific case. The additional field, sayX-Whitelisted-By: swl.spamhaus.orgwill 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.
I think that similar to -skipif, you can specify variable name/header name pairs by a new option:
-header BLOCK,Blacklist \ -header ALLOW,WhitelistThis 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>" 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-".
A global mail filter could then look for "X-DNSBL-<name>" headers.
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.
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.
pgpAE4cOYEskn.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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
