On 7/13/2011 10:51 AM, Geert Mak wrote: > > On 13.07.2011, at 17:07, Victor Duchovni wrote: > >> On Wed, Jul 13, 2011 at 04:57:02PM +0200, Geert Mak wrote: >> >>> is it possible to reject/redirect on postfix level (to a spam catcher >>> account we monitor) - >>> >>> - all mail sent to undisclosed recipients
You could use header_checks and a PCRE to reject or redirect all such mail addressed to "undisclosed recipients", but given how often this is used legitimately, I don't think it wise to filter on this criteria alone. It would be better to have SA bump the score up a bit with a custom rule. >> Why not focus on spam, rather than weakly correlated factors. It is probably >> best to deploy a decent spam filter. > > We have Spamassassin. But its effectiveness relies on how well you tune it to your environment and mail flow. > But I thought that this is a simple enough case to be handled directly on > Postfix level before even entering Spamassassin. It could very well be. But you need to be looking more at the characteristics of the sending hosts, not the message content. Remember this valuable phrase: "Spam is defined by *consent* not *content*". Reject those senders who do not have consent to send mail to your users. Almost all spam sending hosts can be relatively easily rejected with fairly simply countermeasures. It's the spam that comes from primarily ham hosts that can't be blocked via these means, such as phished webmail or gorilla (Gmail, Hotmail, etc) mail servers. That's where a well tuned content filter comes in handy. >>> - all mail sent with "our" addresses in From: but not originating from >>> us (or mail server is in-house, one server with one IP) >> >> This would be a mistake. For example, you'd never see your own posts to >> this list. > > Oh... I see. > >> This said, you may find that filtering the envelope sender (rather than >> the From: header) is reasonably effective. The main collateral damage is >> "forward an article" newspaper sites, ... which send email with envelope >> address set to the visitor's alleged address. > > I see, this seems not an easy one. Many people use what Viktor mentions here and it can be very effective against forged mail. However, there may be better ways to combat forged mail. In my experience most forged mail is sent from bot infected PCs, some from phished webmail accounts, almost never from snowshoe farms. You can stop such spam easily using many techniques, including the CBL and PBL (included in the Spamhaus Zen dnsbl) and other dnsbls, with greylisting, or with a PCRE file that targets hosts with generic rDNS (mainly residential broadband PCs). Many people use a combination of 2 or all 3. The more you use the greater the load on the server. Using a dnsbl, or many of them, incurs a per message lookup delay of tends to hundreds of milliseconds per message, more if a timeout occurs due to network conditions in reaching the remote dnsbl server. Using greylisting inserts a delivery delay, often less than 5 minutes, potentially up to 30 minutes or more, for legit mail (unless done selectively). Using a PCRE file with a REJECT action incurs no delays of any kind. You can combine the above techniques, such that a match in the PCRE file returns a dnsbl lookup or greylist action instead of an outright rejection. Or, you can PREPEND a header that SA can then use to increase the spam score. A fairly complex Postfix configuration is required when combining these countermeasures. Such a PCRE file that targets hosts with generic rDNS can be found here: http://www.hardwarefreak.com/fqrdns.pcre The default version rejects on most matches, but it does a PREPEND for some rDNS patterns which include many ham hosts, mostly SOHO connections. The default setup works very well. A number of list members use it but I don't have a count. It's very easy to implement with concise instructions at the top of the file. Give it a shot and see if it helps. The resource footprint is tiny. Post a sample (dozen or so) of the IP addresses sending you this mail with "undisclosed recipients" and that which is forged with your own domain. I'd like to see what categories these hosts fall into to give you the best recommendation for means to combat it, if not already mentioned above. -- Stan
