> I think the above makes it very clear why I understood that your service > seeks to send out email for customers with source IPs *other* than the > customers' own IP, at least during the IPs "break-in period". The link was meant to provide an introduction to some of the issues. You are obviously focusing exclusively on possible ways the current situation can be gamed or abused. Unfortunately there are not 15 different ways to "warm up" IPs. It takes time and so costs money, as most people are still doing this at least semi-manually. You need to build up slowly, that is how the ISPs/MSPs require it. In any case, it takes weeks for an IP to earn a reputation and all that can be destroyed in a single send (couple of hours). When an IP has a reputation then you can dedicate it to a customer and the customer then becomes responsible for their own reputation. Again, this is the goal and there is only really one way to get there. If there were some magic program that all ISPs/MSPs adhered to and required a large bond to be posted in terms of guarantee, we would jump on it. If we could just say, "here are many thousands of dollars, if anyone sends anything dodgy from this IP then it is forfeit" that would save lots of time and hassle. It doesn't exist. Even whitelisting services like Return Path SenderScore certification require a minimum of 3mths on a dedicated IP before they will *consider* accepting an IP in the program! We have multi-year contracts with our clients - we are not at all interested in customers that come, send crap for a week or two and leave. That is not possible with our infrastructure because we have an involved acceptance process where databases are analysed, marketing programs reviewed, etc, and you sign a (absolute minimum) 12-mth contract. Sign up costs are also significant, and spammers need for things to be cheap. I recently read that on average 12.5 million spam messages need to be sent for $100 of "viagra" to be sold. You would be losing a LOT of money sending these messages on any reputable email service provider! > Now you explain what you are really trying to do is provide mail server > redundancy. You can do that easily and cheaply with DNS failover. But that > is off-topic. Sending and receiving email are two quite different needs. I would be very, very surprised if, say, Yahoo! did sending and receiving on the same machines. The various SMTP standards never suggest that email should only be sent from machines in the MX. The ISPs and MSPs don't care if you use machines referenced in the MX records. I know because anti-abuse masters have told me so. Sure, you need to provide robust infrastructure for dealing with bounces and any complaints (to postmaster@, abuse@, etc.) but that has nothing to do with sending infrastructure. You should also provide rDNS but again, that has very little to do with reputation indexes based on IP address. DNS failover isn't an option for providing MTA sending uptime from a particular IP. What I am trying to do is DNS failover for IPs - so having a public token (in DNS it's a name, for me it's an IP) that is translated to one or many internal values (IP for DNS, LAN local IP for me). Isn't this NAT? I am all up for alternative means for making sure a particular IP can be available for sending 24/7 cheaply, if there are any. (Don't mistake cheap for provider as cheap for sender though!) I thought iptables/netfilter would be a good way of doing it but I might be wrong... Cheers Anton -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
