one note about whether to filter at receiving SMTP server or later.
The receiving SMTP server is the one that has the conversation with the
sender.
Rejecting mail from servers having an un-backtranslatable IP is best
done right away by the receiving server right after the HELO command by
issuing error message about the IP being unbacktranslatable. Reduces the
load.
later on (for instance at the client level), you need to parse the
RFC822 text header and there are some bits that are missing, notably the
RCPT TO: commands. This is especially true when the "TO" in the 822
header is faked.
Blocking messages as early as possible also greatly reduces the load on
your system, disk storage requirements etc.
Jean-Fran�ois Mezei wrote:
Blocking messages as early as possible also greatly reduces the load on
your system, disk storage requirements etc.
Rejecting during the SMTP dialog but before you signal that you've accepted the DATA output also also pushes the responsibility for sending a DSN to the sending MTA. It's is a spammer then they'll drop the DSN. If it's a compromised PC running Storm Worm or the like it won't generate DSNs anyway. If it's a legit but poorly-configured MTA acting as an open relay it will generate the DSN and eventually get itself blacklisted. Sending a DSN to a spoofed envelope From is considered spam in and of itself and will get an MTA blacklisted. You could always not send DSNs in which case the sender of a legit message that had a few to many !!!s in it will not get a bounce and will not know that there message was blocked. It disappears into an email blackhole. Few things piss off users like disappearing email.
It's best all around to force the sending MTA to send the bounce. Your MTA doesn't get blacklisted, spammers' relays are forced to do a little extra work, and senders of legit mail that's a false-positive get a DSN telling them that their message didn't go through (and hopefully why). Everyone wins. Block early and block often.
Justin