Prefactoring

16.2. Spam Checking

The ReceivingMailServer class performs two actions. It receives the mail and it examines the mail to see if it is spam. The spam checking is delegated to whatever programs or objects the mail server administrator or a user desires ("Separate Concerns To Make Smaller Concerns"). These actions can be separated into two processes: one that receives the mail and one that checks the mail for spam. However, the reason for checking for spam during mail receipt is that any responses that indicate rejection of a message (i.e., PermanentFailure) are sent to the SendingMailServer immediately for delivery to the user that sent the email. A legitimate SendingMailServer will deliver the rejection notice to the user. A spamming program will probably ignore the rejection.

A legitimate sender should be informed with a bounce message by the SendingMailServer that his email message was rejected because it appeared to be spam. That way, the sender can either alter the message or use an alternative means of communication to the recipient. Remaining silent by dropping a message and not informing the user can cause communication difficulties ("Never Be Silent"). You can imagine the exchange that begins with "I sent you an email. Are you telling me you didn't get it?" With an assured means of informing the message sender that he was identified as spam, spam filtering by the ReceivingMailServer can be more aggressive. It can have more false positives (messages erroneously identified ...