Challenge/Response at the SMTP Level

Home	Blog	Bio	Projects	Contact	Latest Blog (new site): How to Get to Genius

JamesThornton.com $-\>$ Writing $-\>$ Challenge/Response at the SMTP Level

Challenge/Response at the SMTP Level

Summary: It may be possible to implement a challenge/response spam protection system using custom SMTP Delivery Status Notifications (DSNs) that include an HTML confirmation hyperlink.

As per RFC 3461 - Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) and RFC 3463 - Enhanced Mail System Status Codes, if an SMTP server cannot deliver or rejects an e-mail message, the upstream SMTP server sends the original sender a delivery notification message that can include a custom response from the rejecting SMTP server.
Last year I modified my qmail installation so that messages are scanned at the SMTP level with the clamav virus scanner and SpamAssassin before qmail accepts and queues e-mail for local delivery. If a virus is detected in the e-mail, it is rejected (not bounced) with a custom error message saying that a virus has been detected. Similarly, if SpamAssassin detects the e-mail message as spam, qmail rejects it with a custom error message saying that it has been identified as spam.
Here is an example of an SMTP delivery status notification I received in my Southwestern Bell/Yahoo inbox after I sent the benign EICAR test virus from it to an account on my modified SMTP server (I wrote the message in the "Remote host said" line).
Date: 6 Mar 2004 03:53:39 -0000 From: MAILER-DAEMON@yahoo.com To: jthornton@sbcglobal.net Subject: failure delivery Message from yahoo.com. Unable to deliver message to the following address(es). <james@jamesthornton.com>: 209.164.72.60 failed after I sent the message. Remote host said: 554 mail server rejected message because it contains a Virus (#5.3.0) --- Original message follows. Return-Path: <jthornton@sbcglobal.net> The original message is over 5k. Message truncated to 1K.

Challenging or bouncing spam/viruses after the messages have been queued is problematic because the return information is probably not the original sender's address. The recipient could be someone the spammer wants to mailbomb, or the return address could be the spammer's desired recipient so you would be acting as a spam reflector. Also, creating a bounce message from the rejecting server for every unaccepted e-mail wastes Internet resources as do the double bounces that are generated when bounces are sent to fake e-mail addresses.
With software such as sa-analyze, you can configure MTAs such as qmail to filter unknown senders' messages before they are queued for local delivery. If a message's sender is unknown, the MTA can reject the e-mail with an SMTP code telling the upstream SMTP server that the mail will not be delivered. The custom delivery notification message could contain instructions on how the sender can confirm himself via a URL pointing to a CAPTCHA confirmation system similar to that of TMDA/CGI.
Then, the upstream SMTP server generates its own bounce message back to the sender with the custom delivery notification message sent from the rejecting SMTP server. Bounces to forged addresses are only sent if the messages are being relayed through poorly-configured open relays. In this case, the open relay postmasters are responsible for generating the bounces so the onus is on them to close their open relays. If the original sender was not abusing an open relay, the delivery notification message will probably get returned to the actual sender.