16.2. Spam Checking

 <  Day Day Up  >  

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 as spam), since false positives will be reported back to the sender.

If spam checking is performed after the connection between the SendingMailServer and ReceivingMailServer is terminated , it becomes problematic to send a message back to the sender of a message identified as spam. All of the information in an email can be faked. Sending a rejection notice to a faked sender ( especially with the message body attached) simply propagates the spam. The only reliable information is the IPAddress of the SendingMailServer . However, a message sent to the postmaster at that IPAddress might not be relayed back to the sender. There might not even be a ReceivingMailServer at that IPAddress , so even the connection could fail.

The considerations outlined in this section make ReceivingMailServer more complicated than if it simply received mail and placed it in a queue for delivery. Sometimes designs cannot follow the "Separate Concerns To Make Smaller Concerns" guideline.

 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net