As per RFC 3461 (http://www.faqs.org/rfcs/rfc3461.html) and RFC 3463 (http://www.faqs.org/rfcs/rfc3463.html), the originating SMTP server sends the original sender a notification message that can include a custom response from the upstream SMTP server that rejected the message.
Last year, I modified my qmail installation so that messages are scanned at the SMTP level with the clamav virus scanner and SpamAssasin before qmail accepts and queues them for local delivery. If a virus is detected, the message is rejected (not bounced) with a custom error message saying that a virus has been detected. Similarly, if SpamAssassin detects the message as spam, qmail rejects it with a custom error message saying that the message has been identified as spam.
Example of an SMTP rejection message I received in my Southwestern Bell/ Yahoo inbox after I sent a 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: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: failure delivery
Message from yahoo.com. Unable to deliver message to the following address(es).
<[EMAIL PROTECTED]>:
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: <[EMAIL PROTECTED]>
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 after the 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 the message's sender is unknown, the MTA could reject with an SMTP code telling the upstream SMTP server that the mail will not be delivered. The custom notification message could contain instructions on how they can confirm themselves via a URL pointing to a CAPTCHA confirmation system similar to that of TMDA/CGI.
Then, the upstream SMTP server generates it's own bounce message back to the sender with the custom notification message from the upstream 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 upstream server is the originating sender's server, the bounce will probably get returned to the actual sender, not to some forged return path as would happen if you were filtering and bouncing mail after it has been queued.
--
James Thornton _____________________________________________ Internet Consultant, http://jamesthornton.com
_____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
