On 10/14/2005 6:40 AM, Magnus Holmgren wrote: > If you want to reject spam at SMTP time (which I think all agree is a > good practice as long as you weigh the risks against the benefits > properly), but also want to apply individual settings (according to the > "One person's ham is another person's spam." maxim), what is the best > practice for handling multiple recipients (RCPT TO: commands)?
Best current practice for rejecting per-user at MTA level is to configure your MTA so that it only allows one RCPT per message transfer, as you spotted in your option #1. > 2. Run a global check at SMTP time, using a conservative ruleset > (possibly including bayes with low scores) that only catches 100% > certain spam, then let each user run SA a second time any way they want > (but without the ability to reject, just accept/blackhole/file in spam > folder as usual). That's the better way, although it loses the ability to reject modest spam at the gateway. > 3. Run SA with custom configs for each user at SMTP time. Reject if > a) any user rejects, > b) all user rejects, > c) the majority rejects, > d) the average score is above the average limit, > e) other criterion. > (Potentially time-consuming with many recipients, risking that the > sending MTA times out.) You still need to limit recipients (actually more imporant since all processing load is now N*msg instead of 1*msg). > 6. Write an RFC about changing the SMTP protocol to allow DATA before > RCPT TO: (if the mail is sufficently short). :-) There have been several drafts trying to attack this problem. Mine is at http://www.ntrg.com/misc/I-Ds/draft-hall-inline-dsn-01.txt and suggests returning per-RCPT response codes after the DATA ack (eg, user1 returns 250, while user2 returns 550). > 1 and 2 are easy to implement, but I don't know if someone has > implemented support for 3 in current software. It's feasible enough with some scripting work. The hard part is applying the per-user settings into the chain (have to read the settings, apply them to the local scanning process without clobbering the others, etc). Really though the problem is load, since you are looking at multiples of scanning processes. FWIW, I wrote a primer on this kind of architecture for Network Computing Magazine, archived at http://www.ehsco.com/reading/20040916ncf.html -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
