Jeff Potter writes:
I’m looking at selective nolisting — iptables rejecting connections to the primary MX for certain IP ranges, but if those MTAs are “smart” enough to be RFC compliant and fail-over to the secondary MX (which is actually the same machine as the primary, but listening on a different IP), then allowing the mail through.As part of this, I want to be able to ex-post-facto examine the headers to determine if spam came through the primary or ham was blocked on the primary but came in the secondary.(Of course, there’s a chance of ham failing to fail-over to the secondary MX, in which case I won’t know about those messages, and users won’t know why they didn’t get expected ham… but hopefully that won’t happen much.)
Normally, primary and secondary MXs are different, separate, servers, running their own mail server; this is a non-issue in that case. You are apparently just using multiple IPs on the same mail server.
But its doubtful that this is going to achieve much. Given high enough volume, random DNS and routing gremlins will ensure that some percentage of non-junk email will hit your backup MX; given that, and the fact that some junk mail sources will try primary MXs first, and others will try secondary MXs first, you wouldn't be able to draw any conclusions anyway.
pgpwMijmW0sLs.pgp
Description: PGP signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
