Gordan Bobic wrote: > On Fri, 19 Oct 2007, Alessandro Vesely wrote: > >> Gordan Bobic wrote: >>> But now that you mentioned it - is there a way to make Courier make an >>> additional check? >>> >>> e.g. it receives a message: >>> From: [EMAIL PROTECTED] >>> To: [EMAIL PROTECTED] >>> >>> Normally, this is not too plausible to check if from is for a non-locally >>> hosted domain, but if from is from a locally hosted domain, can we make >>> Courier check if from is deliverable, and if not, reject with "unknown >>> sender" or some such? >> That's not one of the checks that Courier performs, AFAIK. >> To carry out that check, you need to roll out your own filter. > > Are there any docs on how to write filters for courier?
It is different writing "global filters" than local ones. The former can be written in Perl, Python, or C. Besides Courier examples, see http://search.cpan.org/dist/Courier-Filter/ http://phantom.dragonsdawn.net/~gordon/courier-pythonfilter/latest/README Local filters come in two flavors: delivery and recipient a.k.a. whitelisting API. Both are based on Maildrop, which is extensively documented. However, there are few examples about the recipient filters. They use the "embedded" mode of Maildrop, and can reject a message without taking the burden of sending the relevant DSN to the sender. In both flavors, local filters can read recipient-specific recipes. > [...] >>> On a separate note, is it possible to get Courier to do return path >>> verification? i.e. for the from address, look up mx, connect, and do: >>> HELO, MAIL FROM, RCPT TO, QUIT, just to see if the FROM address is >>> deliverable? >> Ditto for how to implement that using a filter. However, I cannot >> imagine what would happen in case the remote domain filters according >> to the same principle, or uses greylisting, or is temporarily down. > > If the remote domain filters on the same principle, spam will get through > if the sender address is valid. But that's to be expected. However, they may issue a connection to your server to verify the MAIL FROM that you are using for the purpose of verifying the MAIL FROM that... Hm... perhaps one should use an empty MAIL FROM for doing that check. > Greylists are also OK, as it'll respond with a transient failure (which is > probably as good as a "yes"). Permanent failures (e.g. no such user), > OTOH, are a definite "no". Fine. > If the site is down, then that's questionable, especially if all their > MX-es are out of action. Secondary MXes usually ignore if a mailbox exists on the primary server. It is probably better to skip this check when the primary is down. > But it seems daft to be implementing all this in a filter. It would > effectively mean implementing almost a full SMTP server. Granted, this > could probably be done with a few hundred lines of Bash or Perl, but it > still seems silly... Yes, it would work better integrated into the server. Consider that Courier, if configured to do so, has already looked up the MX record for the sender's domain. > And how would one filter ALL incoming email using such a filter (e.g. big > virtual domain mail server)? That can have a quite heavy impact on the throughput. Just consider how long a mail queue can grow if mail is being rejected in delivery mode: that means it is not very common to get a quick "no such user". One should use rather severe timeouts and default to a "yes" when anything goes wrong. But then how effective would that be? Spammers are probably good at picking up problematic MAIL FROMs. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
