Forum OpenACS Q&A: (OT) SPAM SMTP Reply Code: Proposal

SPAM SMTP Reply Code: Proposal

We should establish a standard SMTP reply code to identify e-mail messages that have been rejected by SPAM filtering programs at the SMTP level so that originating SMTP servers could let legitimate senders know why their messages are being rejected.


- False positives from SPAM filtering programs would become less of an issue so administrators would be more apt to implement server-wide SPAM filtering at the SMTP level.

- Discerning administrators could monitor the number of messages originating from each user that are being rejected with the SPAM return code, and automate the process of identifying local spammers.

- SPAM would become less effective and pervasive.


Bouncing SPAM After It Has Been Delivered: BAD

It is poor practice to bounce SPAM after it has been queued because the return information is probably not the spammer's. The recipient could be someone the spammer wants to mailbomb, or the return address could be the spammer's desired recipient and you would be acting as a spam reflector.

Bouncing SPAM Before It Has Been Delivered: GOOD

However, with software such as sa-analyze, you can configure MTAs to filter SPAM before it's queued. If the message is identified as SPAM, the MTA will reject it and usually reply with an SMTP 550 code telling the upstream SMTP server that the mail will not be delivered.

Then, the upstream SMTP server may generate it's own bounce message back to the sender. Bounces to forged addresses are only sent if the messages are being relayed through poorly-configured open relays. In this case, the open relay ostmasters are responsible for generating the bounces so the onus is on them to close their open relays. If the upstream server is the originating 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.

Currently, if your filtering program generates a false-positive and blocks a message from a legitimate sender, their mail server will probably send them a failure notification; however, they won't know the real reason their message has been rejected. In RFC 822 (, the 550 reply code is defined as:

    550 Requested action not taken: mailbox unavailable
    [e.g., mailbox not found, no access]

Using the 550 reply code for SPAM rejections may cause legitimate senders to incorrectly conclude that their message has been rejected due to an invalid e-mail address, and server administrators cannot use it to monitor spam activity originating from their servers.

Virus SMTP Reply Code

We could also establish a virus reply code to identify messages that have been rejected by server-side virus scanners.

Posted by Andrew Piskorski on
What does this have to do with OpenACS?
Posted by Alfred Werner on
It has to do with the part of openacs that handles bounced emails. See bug 379 for example - notifications reply ..
the suggestion is we recognize the bounce as a spam filter so the user can adjust or tell their ISP/LAN admin.