Historically, we have handled SMTP traffic across a handful of multipurpose servers each with their own local spam-fighting stack. We've grown and this is no longer feasible to maintain. Now we have a single anti-spam gateway in place which is performing well, but spammers still send messages directly to the SMTP endpoints as before. Most of our users connect to their server via mail.example.com for SMTP, IMAP, and POP, which points directly to their server IP.
How can I forward the "spammer" traffic, which completely ignores the MX records for the domains, while still leaving port 25 available to user SMTP traffic? Traffic from the users' MTA is supported on port 587 (auth required) and 25. I basically need the email traffic routed to the server to be forwarded to the anti-spam gateway for inspection, while allowing user SMTP traffic (their outgoing email) to be allowed and not take a trip through the anti-spam gateway. I'm using qmail on the endpoints. Is this possible?
UPDATE
I actually do not need to forward the spam to the remote spam filter. That would be good for learning spam (honey pot), but it's not necessary and I can do without it.
The endpoint SMTP servers need to...
- Allow users to send mail through the SMTP server, with authentication only, on ports 587 and 25. In an effort to not break legacy configurations, I still need port 25 open for authenticated sessions.
- Configure port 25 to accept unauthenticated mail from the anti-spam filter IP without accepting mail from any other unauthenticated IPs. The incoming filtered mail does not have authenticated. It is simply relayed through the filter by the MX records.
Why worry about forwarding e-mail from spammers? Reject or defer any remote messages on connections that aren't authenticated. If you defer, any misguided legitimate server will eventually deliver according to your MX. If it is a spambot, they will usually not retry in either case.
You can reject or deny as early as the "MAIL FROM" command. By that time your user's will have authenticated.
If you aren't spam filtering messages for authenticated connections, you could configure the spam filter to always reject messages. If you are filtering messages for authenticated connections, you may be able to configure the spam filter to always reject messages on unauthenticated connections.