If you are performing spam filtering services for a customer, the customer's actual mail server should not be performing any additional IP-based spam checks, as the IP will be SpamFilter's server, not the actual sender. The IP checks do include the SPF tests - these should not be performed by the mail server.
SRS was intended to be used in cases where the emails are *forwarded* to a different email address, for example an email from ecards@amerciangreetings.com originally sent to mike@mydomain.com is then forwarded by the SMTP server to mike@gmail.com. In this case, the recipient's domain has been changed, and SRS is used to handle that rewrite. In the case you described, if I understand correctly, the email is from ecards@amerciangreetings.com to mike@mydomain.com. This email is then forwarded by SpamFilter, as-is, to the same address - mike@mydomain.com, onto a different SMTP server. Here the destination email address is not rewritten, the email is simply delivered in the original format to a different SMTP server. In your example above, smtproutes.com "fakes" an intermediate address on their own domain, and pretend that that was the original recipient so that they can then use SRS to bypass the SPF test.
Also please note that there are a few issues with implementing SRS. For example, in case the email can't be delivered and NDR bounce notifications are sent, the "man in the middle" server will receive a bounce, since that's the "faked" email address where they will be sent to. This man in the middle server (the spam server) will then need to process these emails and make sure the bounce is then in turn emailed back to the original sender. Another even more serious issue is that the original "Mail From" address is modified by SRS by adding several characters in the local part of the email address (the one before the "@" sign). Per RFC 2821, there is a 64-character limit on this. Adding the SRS signature could very easily cause this limit to be exceeded, and there are antispam devices out there that will block emails that violate this. Cisco MailGuard is notorious for this.
------------- Roberto Franceschetti
http://www.logsat.com" rel="nofollow - LogSat Software
http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP
|