== Another reason to reject spam at SMTP time: as a signal I'm sure that people know all of the usual reasons to reject spam at SMTP time; in part they boil down to the fact that if you accept spam, the best you can do later is discard it, while rejecting at SMTP time means that if senders will find out if their email got mis-characterized as spam. You'll probably also lessen the load on your systems and have some other benefits (and avoid things like [[the forwarding problem ForwardingDanger]]). It's recently occurred to me that there's another advantage to SMTP-time spam rejection: it's at least potentially a feedback signal to email providers about the quality of what they're sending out. In an ideal world free webmail providers, free mailing list providers, and so on would take great steps to make sure that they emit no spam (and certainly no spam that any commonly used spam scoring system can recognize). This is not an ideal world. This is not even anywhere close to an ideal world. Places like GMail, Yahoo Groups, and so on regularly host spammers and send us spam. If we accept that spam and then quietly discard it, there is no feedback to these places that their user is generating bad email. However, if we reject it at SMTP time there is at least a chance that automated systems on the sender's end will notice that this user or mailing list is sending email that generates a lot of delivery failures and either react immediately or flag it for human attention. If nothing else, many mailing list setups will remove 'subscribers' who have repeated delivery failures. Obviously, this only works for sending systems that have at least some interest in stopping spam emitting from them. But I'm optimistic enough to think that this actually does describe a lot of the free email places and mailing list providers. (And I've read that at least some of them do track SMTP rejections and other delivery failures and raise alarms if the levels get 'too high', whatever that is.)