* /dev/rob0 <r...@gmx.co.uk>: > On Friday 21 August 2009 00:23:07 Olivier Nicole wrote: > > > > This is a difficult question. > > > > > > I disagree. > > > > Just that because you disagree makes the question not simple :) > > Perhaps you didn't understand. I tried to explain why the choice of > pre-DATA reject_rbl_client lookups should be preferred to doing them > through content filters. Yes, I made the exception of untrustworthy > lists. If you look back, you'll possibly see that I was proposing > responsible, informed use of DNSBLs.
I have to disagree here. For me it would simply be unacceptable to reject a mail based on only _one_ criterion. As you said, if e.g. gmail get's listed on any DNSBL, this might not be a false positive, but OTOH, it's highly undesireable to block the dozillions of other legitimate customer mail originating from gmail. Nowadays, I'd always favour computing a score for every incoming email as soon as we know the HELO/EHLO, (r)DNS data and MAIL FROM. With Postfix's "smtpd_delay_reject", this is easily realized by calling a policy service at an appropriate place in smtpd_recipient_restrictions. While I know that the original reason to introduce the delayed rejects was not to make more data available, rejection at the "rcpt to" stage allows for making much more comprehensive decisions about the fate of an email. You could, for example, make it easier to contact "postmaster" - because that's where third parties will seek help if they are blocked by your system. It's only logical to extend this conception when it comes to other, sender/sending host specific criteria: Instead of evaluating one criterion at a time, basing a rejection decision on the one currently being examined, you should use _all_ the data you have about an incoming message to decide on that message's fate. > I think blind reliance on content filtering is ill-advised, based on > poor logic and lack of understanding of the nature of spam. SA and > other content filters will be checking the same DNSBL as I am, with > addition of some that I'd consider less trustworthy. Furthermore, by > virtue of having accepted the DATA, a MTA assumes responsibility for > these few messages amidst all the spam garbage. Actually (that's for the archives only, I know you are well aware of that), my server only accepted a message after giving a 2xx to the DATA-DOT. > I'm not opposed to content filtering; on the contrary, I know it's > an important third or fourth line of defense for many sites. Those > sites which are using it as the first line get what they deserve. I have to disagree here, again. From your description, I think that when you are talking about "content filtering", you are referring to a post queue filter setup. There are a million sites out there using a post queue setup, and IMNSHO, they should all die in a fire for torturing their users with ancient technology like that. About 14 months ago, I switched to a pre queue setup. The main reason for this was that even with Nazi style rejection rules (that's one Godwin for me, please!) at the SMTP level, there were still mailboxes for which our content_filter quarantined (rerouted to plus'd addresses, $WHATEVER) about 30 messages per day - while killing another 50 ones silently. And no, there wasn't any chance we could have set the "kill" level even lower. C'mon. We are living in the 21st century. Why on earth should anyone have to look through a folder/quarantine with 30 messages per day? We are humans, not machines. I know that there are many concerns regarding the use of smtpd_proxy_filter - many of them having to do with the lack of scalability. So what? Buy more hardware. Or buy better hardware. If you are worried about rejecting mailing list mails, learn how to use your filter framework. But, for God's sake, step into the 21st century, finally! Postfix could easily help this if it supported the same kind of "routing" it does with a content_filter (where you can specify "content_filter = smtp-foo:filter.domain.com:10024" and it will lookup the MX records for filter.domain.com) to faciliate load balancing and increase robustness, but we probably won't see that too soon. Cheers Stefan
