North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)

  • From: Justin Shore
  • Date: Sat Jul 05 02:06:17 2008
Phil Vandry wrote:
On Tue, Jul 01, 2008 at 11:54:46AM +0200, Jeroen Massar wrote:
The magic keyword: REJECT-ON-SMTP-DATA.
[snip description on how to reject during DATA phase]
Unfortunately there is also a side-effect, partially, one has to have all inbound servers use this trick, and it might be that they need to be a bit heavier to process and scan all that mail. Then again, you can 

More than that: you also need to have all users in the domain (indeed
all users who share an MX server) agree on the accept/reject policy.
If users are free to use different spam filtering techniques and tune
them to their liking (e.g. someone uses SpamAssassin with a low threshold,
someone else uses it with a high threshold, someone else uses bogofilter
instead) then what do you do with mails that are addresses to more than
one user? You can have some users reject the message during the RCPT
phase and others accept it, but if you've waited until the DATA phase,
it's too late for that.

Phil,

This is a non-problem if you use the right spam filter. I mentioned CanIt earlier in the thread. It individually applies filtering rules to incoming mail and can apply different rules and take actions on a per-user basis. It handles messages with multiple recipients by feeding copies of the message into an individual user's stream where that user's settings dictate what actions are taken. A user may have an aggressive spam score or an extremely conservative score, message rejection with SpamHaus and SORBS or no DNSBLs at all, tons of custom rules and lots of bells and whistles or spam filtering disabled completely. They've already anticipated all the possible problems that have been brought up in this thread. Arrange for a demo and give it a try. I don't think you'd be disappointed.

http://mailman.nanog.org/pipermail/nanog/2008-July/001884.html

Justin