I submitted at ticket at PayPal, and received a response from PayPal that I should contact the domain referenced and tell them to whitelist all mail from PayPal's IP addresses. Talk about not getting it. PayPal is the domain at the source of the problem. I contacted them, and they just don't get it. Here, I'll lay it out as plainly as I can for you.
The problem? The PayPal Invoice tool is forging the MAIL FROM command. This is bad.
This occurs with every invoice we send thru the new PayPal interface. It's broken. Period.
The bottom line is: PayPal is FORGING email "from" me, when it should be coming "from" service#paypal.com. PayPal is one of THE most phished services in the world. Are you telling me that you really don't understand the SMTP protocol enough to send a legitimate message yourselves?
Let's start with SMTP 101:
http://www.faqs.org/rfcs/rfc2821.html
http://www.faqs.org/rfcs/rfc4409.html
I know SMTP has only been a standard for about THIRTY years, but seriously, hasn't PayPal learned ANYTHING with the amount of paypal forgeries out there?
Here's a few select quotes, with simplified explanations below each:
"The first step in the procedure is the MAIL command.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>"
The <reverse-path> is what you are forging or "spoofing". This is a violation of both SMTP and SPF. Please fix it. I'd stop here, but clearly you don't understand SMTP well enough without someone holding your hand.
"Similarly, when forwarding a message from another environment into
the Internet, the gateway SHOULD set the envelope return path in
accordance with an error message return address, if supplied by the
foreign environment. If the foreign environment has no equivalent
concept, the gateway must select and use a best approximation, with
the message originator's address as the default of last resort."
To boil that down for you, that says "don't forge the address used in the MAIL FROM command". To help you understand the situation here, I'll add "even if it's coming through the PayPal invoicing tool."
"Efforts to make it more difficult for users to set envelope return
path and header "From" fields to point to valid addresses other than
their own are largely misguided: they frustrate legitimate
applications in which mail is sent by one user on behalf of another
or in which error (or normal) replies should be directed to a special
address."
This says, "Yes, Paypal, you really are doing it wrong and there are better and more accurate ways to code your application!"
"Historically, the <reverse-path> was a reverse source routing list of
hosts and a source mailbox. The first host in the <reverse-path>
SHOULD be the host sending the MAIL command."
This says "the MAIL FROM command should have a paypal.com address if it's actually coming from a paypal server!"
"An SMTP-capable host SHOULD support both the alias and the list
models of address expansion for multiple delivery. When a message is
delivered or forwarded to each address of an expanded list form, the
return address in the envelope ("MAIL FROM:") MUST be changed to be
the address of a person or other entity who administers the list."
This says the exact same thing. Again.
"For example, some sites might configure their MTAs to reject all RCPT
commands for messages that do not reference local users, and
configure their MSA to reject all message submissions that do not
come from authorized users, with authorization based either on
authenticated identity or the submitting endpoint being within a
protected IP environment."
This says it is fully appropriate for my server to refuse mail with a forged sender. EVEN IF PayPal thinks it's okay. Especially if it's forging MY OWN address as the source.
"NOTE: It is better to reject a message than to risk sending one that
is damaged. This is especially true for problems that are
correctable by the MUA, for example, an invalid 'From' field."
Hey check it out: they actually tell people to block messages with spoofed addresses!
"If an MSA is not able to determine a return path to the submitting
user, from a valid MAIL FROM, a valid source IP address, or based on
authenticated identity, then the MSA SHOULD immediately reject the
message. A message can be immediately rejected by returning a 550
code to the MAIL command."
Twice!
Another good place to read is OpenSPF, especially this section on cross-user forgery:
http://www.openspf.org/RFC_4408#cross-user-forgery
"It is up to mail services and their MTAs to directly prevent
cross-user forgery: based on SMTP AUTH (RFC 2554), users
should be restricted to using only those E-Mail addresses
that are actually under their control (see RFC 4409, Section
6.1)."
And once again, a completely different protocol says that forging the MAIL FROM address is wrong. Duh.
More? http://www.openspf.org/RFC_4408#mfrom-ident
"The "MAIL FROM" identity derives from the SMTP MAIL command (see
RFC 2821). This command supplies the "reverse-path" for a message,
which generally consists of the sender mailbox, and is the
mailbox to which notification messages are to be sent if there
are problems delivering the message."
This means that ERRORS aren't even going back to PayPal now because their invoice system is like, totally broken? Yep.
"SPF clients MUST check the "MAIL FROM" identity. SPF clients
check the "MAIL FROM" identity by applying the check_host()
function to the "MAIL FROM" identity as the <sender>."
That's exactly what I've been saying now for several days. And PayPal staff have ignored or white-washed because they really just "don't get it".
Seriously, this is NOT rocket science. All you need to do is go into the source of your invoicing application and change the part where it sends the "MAIL FROM" command to use an email address that YOU control. This has ALWAYS been "service#paypal.com" or "sendmail#paypal.com" in the past, but if you want to spice it up a little I'll understand.
The bottom line is, you MUST NOT forge addresses within the MAIL FROM command. Doing so breaks the rules, and will really upset every single user in the whole world that sends invoices thru PayPal. Frankly, your ignorance of the problem and your unwillingness to even look into it make me want to publicly lambaste you for launching a project AT PAYPAL that intentionally spoofs addresses. After more than a decade of facing spoofing problems of your own, do you REALLY not understand that this is wrong?
I'll bet if you actually reviewed the number of PAID invoices since this launch you'd find it were significantly less than usual. Why? Because forged messages get rejected and you don't even get copies of the return messages - since that part is forged. Golly, I'll bet you could even review your own SMTP logs for 5.5.x errors and quickly see tens of thousands of messages relating to SPF.
Instead, you pass it off as if I don't know what I'm talking about, or even worse, that every ISP in the world should provide a specific EXCEPTION to the rules for PayPal, since they're an "important" business. It doesn't matter how "important" your business is if you're doing it WRONG!
This is no doubt why phishers are so effectively exploiting PayPal users. It's not that the users are too stupid to figure it out, but that PayPal itself doesn't even understand the problem.
-Shawn
