On 9/13/2011 2:39 PM, Quinn Comendant wrote:
We've managed the mail server in question with Rackspace for over 10
years. We're considering moving to their cloud servers to free up the
dedicated hardware it's currently on.
Rackspace admits that the IPs which are given with their cloud
servers will very likely be on DNSBLs. As a solution, they've offered
free Bronze accounts with SendGrid for each server. Hence my question
to this list for their experience with ESPs like SendGrid.
Alternatively, Rackspace has offered that we setup a private
RackConnect network between a Cloud Server and our existing dedicated
firewall with clean public-facing IPs. However the drawback of this
scenario is the need to use port mapping for sites which are hosted
on the same server, which is only a drawback insofar that we'll need
to adapt our systems to work with sites not hosted on port 80
internally. This would also solve the problem of each Cloud Server
having a maximum of 5 IP addresses assigned (apparently a Xen
limitation?).
And if a spammer relays through your server than bang-those "clean
facing" IPs will be "dirty" and then what? Using your logic your
screwed.
Your entire premise is wrong. There are no "dirty" or "clean" IP
addresses. There are only IP addresses. If you misuse them then they
will be in a BL until removed. If you don't misuse them then they won't
be in a BL. And if you get an IP that some prior user has misused then
your going to need to delist it using the same techniques that you would
have to delist IP addresses that you were using that accidentally had a
spammer use.
You need to ask Rackspace why they think their cloud IP addresses
would be "dirty" and how exactly they are gonna guarentee that they
can give you "clean" public-facing IPs?
As far as offering a "free" Bronze SendGrid account, that is nothing
more than a marketing gimmick. All that happened here is that SendGrid
approached Rackspace and offered them a marketing deal - in exchange
for referring Rackspace users to SendGrid, Sendgrid would hand out free
limited accounts. That gives SendGrid your name and phone number so
they can set their sales dogs on you to upsell you, and it costs
SendGrid a minimal amount. It's pure lead generation. Surely you are
familiar enough with how sales operates that you can recognize this kind
of thing when you see it? The baloney that Rackspace cloud IPs are
dirty is pure sales and marketing BS to convince you to hand over
your name and phone number to SendGrid so they can start calling you.
If Rackspace has a way that they can guarentee their public IPs are
clean, then they can use this same method on their cloud IPs to
guarentee that they are clean, too. They don't because there is no
such method and they cannot guarentee their public-facing IPs are
going to be "clean" anymore than they can guarentee that their
cloud IPs are going to be "dirty" Their last customer using the
public-facing IP that they give you might have been Cyberpromo
for all you know. Get them to sign a piece of paper saying that
the public IP's are guaranteed to be "clean" and then you will have
something, but until then all you have is a pile of steaming BS.
And incidentally, there is no such Xen limitation on the number of
IP addresses. If Rackspace is only assigning 5 IPs per cloud server
it is because they can meet justification utilizations to the RIR
by assigning no more than a /29 to each customer, without having to
fill out a RIR justification form. If Rackspace is telling you it
is a Xen limitation then that it more lying BS.
Look, I have customers that use Rackspace. Their biggest and strongest
point is that they are cheap - and they are cheap because they
cookie-cutter everything. If you can shoehorn your application
into their cookie cutter virtual server then you can save a lot
of money. But as I said before Rackspace is not interested in
offering you tech support for anything so they will manufacture
BS on the spot if you ask them questions about anything other than
their core competency which is running clones of virtual servers.
Ted
Quinn
