PayPal 404 errors

Has anyone else been experiencing problems with PayPal's IPN service? I've noticed that all of a sudden it doesn't seem to be working. I suspect the problem is entirely PayPal's, as I've read that they are known to change things without telling anyone. However, I just wanted to make sure that it's not something that I'm doing wrong.

The problem basically comes down to the fact that my script for handling the IPN POST request is unable to POST back to the PayPal server. I was using fsockopen() and fputs() as per PayPal's example on their site, but it was for some reason returning 404 errors. I changed the script to now use the curl() functions and POSt back to https://www.paypal.com/cgi-bin/webscr, but now curl is complaining that it can't connect to the host when I call curl_exec (errno = 7).

If someone could help me get to the bottom of this, I may actually have some hair left.



--Brad Barkhouse
Be a Contender!
http://www.beacontender.com
brad.barkhouse@beacontender.com

Hey Brad,

This was actually a problem on our end.. a potential customer signed up for the "paypal.com" domain, which resulted in it being added to our local dns servers! We were having the same problem as you with our paypal IPN actually until we figured it out! We've now removed the offending entry and made it so nobody can sign up for that domain again (since we're most likely never going to host paypal.com!)

Sorry about the trouble!

josh!

There seem to be, potentially at least, some very serious security risks coming from the ability of Dreamhost customers to set up any domain they wish. People can cause trusted sites, including those of financial institutions, to redirect to their own site when accessed from a Dreamhost server (which would catch "back-end" stuff from DH customers like the above-referenced PayPal thing, as well as possibly the Web surfing of DH employees at work). In this case, it apparently just caused a "not-found" error, but somebody might get more devious and mimic the actual site's interface, in an attempt to steal personal info. This could be scary.

I don't know what DH could do about it, though; it would be a shame if they had to make it harder for legitimate users to set up domains. Doing something like checking whether the domain in question has DH's servers set up in it already before allowing the setup would inconvenience people trying to transfer a domain from elsewhere in a smooth fashion without downtime, which requires setting it up at the destination host before changing the DNS servers.

-- Dan

There are a few ways to deal with this. However a few things:

1) We don't resolve off of our authoritative servers at the office, so it wouldn't affect our office web surfing or email.

2) We are already switching to a setup where mail and web machines will be resolving off of caching-only servers which are not slaved to the authoritative servers. Thus, our customer-facing servers will all "see" the same thing that the real world sees. Only catch is if a customer is on the same group of mail servers, and that mail server is configured to accept mail locally for a domain, the mail server may still accept it even if it sees that it's not an MX for the domain.

These changes are long overdue, and are partially designed to help reduce the chances of problems like this coming up.

3) We do already have a number of commonly added domains that we know we don't own and that people might try to spoof setup as domains that can't be added to the system.

There is a pretty interesting paper that was released about this a while back. Other than separating authoritative and caching functions as much as possible, there's not really a lot that we can do without implementing much stricter checks. If this type of thing becomes more of a problem, we may have to do that.