|Spam Filtering for Mail Exchangers: How to reject junk mail in incoming SMTP transactions.|
|Prev||Chapter 3. Considerations||Next|
There are other situations where you may want to support settings and data for each user at site. For instance, if you scan incoming mail with SpamAssassin (see Spam Scanners), you may want to allow for individual spam thresholds, acceptable languages and character sets, and Bayesian training/data.
A sticking point is that SMTP-time filtering of incoming mail is done at the system level, before mail is being delivered to a particular user, and as such, does not lend itself too well to individual preferences. A single message may have several recipients; and unlike the case with Forwarded Mail, using an aggregate of each recipient's preferences is not a good option. Consider a scenario where you have users from different linguistic backgrounds.
As it turns out, though, there is a modification to this truth. The trick is to limit the number of recipients in incoming messages to one, so that the message can be analyzed in accordance with the settings and data that belongs to the corresponding user.
To do this, you would accept the first RCPT TO:, then issue a SMTP 451 (defer) response to subsequent commands. If the caller is a well-behaved MTA, it will know how to interpret this response, and try later. (If it is confused, then, well, it is probably a sender from which you don't want to receive mail in the first place).
Obviously, this is a hack. Every mail sent to several users at your site will be slowed down by 30 minutes or more per recipient. Especially in corporate environments, where it is common to see e-mail discussions involving several people on the inside and several others on the outside, and where timelines of mail deliveries are essential, this is probably not a good solution at all.
Another issue that mainly pertains to corporate enterprises and other large sites is that incoming mail is often forwarded to internal machines for delivery, and that recipients don't normally have accounts on the mail exchanger. It may still be possible to support user-specific settings and data in these situations (e.g. via database lookups or LDAP queries), but you may also want to consider whether it's worth the effort.
That said, if you are on a small site, and where you are not afraid of delayed deliveries, this may be an acceptable way to allow each user to fine tune their filtering criteria.