Gordon Messmer wrote: >>> I just want to take a moment to shake a finger at the guy who came into >>> a conversation to complain that greylisting is broken, and finished it >>> by talking about transparent redirection. Shame on you >> The two issies are completely different. > > In both cases, you're breaking normal use to combat spam/virus > transmission via email. I don't think they're at all different.
Sure - so is using transparent proxy redirection of outgoing email for purposes of virus scanning. >> One is about maintaining control >> and awareness on your own network. The other is about breaking mail >> delivery for perfectly valid mail. > > Your visitors aren't sending "perfectly valid mail"? You got that backwards - re-read what I said. The point is that SPF can is as effective as blocking ham as spam. >> I'm sure there are enough essays on the >> internet on why SPF is broken that I don't have to summarise them here. > > If I write an essay explaining why transparently redirecting your users' > connections is broken, will you stop doing it? SPF has its faults, but > it's not broken just because people complain about it. No, people complain about it because it is broken. That's the second time you got things backwards in one post. >>> I'm not saying that greylisting isn't broken. It's a hack. I think >>> everyone knows that. The thing is that every effective anti-spam tech >>> is a broken hack. All of them. Content blacklisting (a'la >>> spamassassin), bayesian statistical content scanning, greylisting, and >>> (arguably) RBLs. They all break something in order that spammers can't >>> use SMTP to do what SMTP is supposed to do. The only non-broken-hack >>> way to deal with spam is to read your email and delete what you don't >>> care about. >> Not quite - nolisting works, has 0 false positives from RFC compliant >> senders, and even if there is a brief network outage that delays mail, the >> RFC compliant MTA will still retry, so the worst you get is a minor delay. > > Listing a primary MX that doesn't exist may not have many drawbacks, but > that hardly makes it a non-broken-hack. It's just a broken hack that > works well for now. OK, let's define a hack as broken if it results in an unacceptable number of false positives / undeliverable hams. Better? >>> You don't need to redirect connections to log them. You can log >>> connections using iptables without changing the packets at all. You can >>> log entire transactions with a number of packages, also without >>> redirecting them. >> I think any sane person would prefer to read the maillog instead of the >> packet log, especially if you need the useful protocol relevant >> information such as from and to headers. > > I didn't say you had to read the raw packet logs. You can log any > details of a transaction that you like, without modifying or redirecting > the connection. How would you virus-scan all outgoing email transparently and without option of avoiding it? Gordan ------------------------------------------------------------------------- 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 courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
