How can PayPal spoof emails so easily to say it comes from someone else?

Question

When I receive a payment in PayPal, it sends me an email about it (pictured below). The problem is that the email is shown to be coming from the money sender's email address and not from PayPal itself, even though the real sender is PayPal.

Here is the text that appears when I select "show original" in Gmail:

From: "[email protected]" <[email protected]>  
Sender: [email protected]

So you can see that the real sender is PayPal.

If PayPal can spoof the email sender so easily, and Gmail does not recognize it, does it mean that anybody can spoof the email sender address and Gmail will not recognize it?

When I send emails to Gmail myself using telnet, the email comes with the warning:

This message may not have been sent by: [email protected]

Is this a security issue? Because if I am used to the fact that payment emails in PayPal appear to come from the money sender's email and not from PayPal, then the sender can just spoof the payment himself by sending a message like that from his email, and I may think that this is the real payment.

Is this something specific to PayPal, or can anybody fool Gmail like that? And if anybody can, what is the exact method that PayPal is using to fool Gmail?

Answer 1

Here is a dramatization of how the communication goes, when a mail is received anywhere.

---

Context: an e-mail server, alone in a bay, somewhere in Moscow. The server just sits there idly, with an expression of expectancy.

Server:
Ah, long are the days of my servitude,
That shall be spent in ever solitude,
'Ere comes hailing from the outer rings
The swift bearer of external tidings.

A connection is opened.

Server:
An incoming client ! Perchance a mail
To my guardianship shall be entrusted
That I may convey as the fairest steed
And to the recipient bring the full tale.

220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)

Welcome to my realm, net wanderer,
Learn that I am a mighty mail server.
How will you in this day be addressed
Shall the need rise, for your name to be guessed ?

Client:

HELO whitehouse.gov

Hail to thee, keeper of the networking,
Know that I am spawned from the pale building.

Server:

250 mailserver.kremlin.ru

The incoming IP address resolves through the DNS to "nastyhackerz.cn".

Noble envoy, I am yours to command,
Even though your voice comes from the hot plains
Of the land beyond the Asian mountains,
I will comply to your flimsiest demand.

Client:

MAIL FROM: [email protected]
RCPT TO: [email protected]
Subject: biggest bomb

I challenge you to a contest of the biggest nuclear missile,
you pathetic dummy ! First Oussama, then the Commies !
.

Here is my message, for you to send,
And faithfully transmit on the ether;
Mind the addresses, and name of sender
That shall be displayed at the other end.

Server:

250 Ok

So it was written, so it shall be done.
The message is sent, and to Russia gone.

The server sends the email as is, adding only a "Received:" header to mark the name which the client gave in its first command. Then Third World War begins. The End.

---

Commentary: there's no security whatsoever in email. All the sender and receiver names are indicative and there is no reliable way to detect spoofing (otherwise there would me much fewer spams).

Answer 2

Any email 'from' address can be spoofed, as you can alter any outgoing data you like. You don't need to fool gmail. In saying that, gmail can spot obvious issues when an email marked as sent from one organisation comes to them from another domain.

You also can't be sure the original email is from Paypal in your example - that sender bit can be spoofed too!

If you want some sort of authentication to prevent this happening, you need a way of signing or encrypting emails, or an out of band check to confirm the email came from your friend (as you mentioned in your comment)

Seriously - do not trust any email. Do not click on any link in an email. Especially from high value targets such as Paypal. Instead you should log in as you normally would and check whether they have sent you something.

Answer 3

As others have mentioned, anyone can fake any email address, including that "Sender" field - there is no technical reason paypal even has to include their own email in the sender field, they only do it because they are an honest company. Don't expect spammers to be this nice.

As an aside, however, I'd like to mention that gmail has support for DKIM, which allows you to verify a Paypal email really came from Paypal.

To enable it: Click on the gear in the upper right --> mail settings --> labs --> Enable "Authentication icon for verified senders"

Now signed Paypal emails will show up with a small key icon next to them:

Answer 4

It is much like postal mail. Anyone can send you a letter with letterhead that looks like the local branch of your bank. There are some things that you can do to catch impersonators like these - you could ensure the postmark is from the right city. If your bank always uses bulk mail instead of individual stamps you might notice that, etc. But you probably never bother to check these things, and even if you did, that would not be enough to verify that the letter came from your bank.

The main difference between postal mail and email, is that with email, a forgery is more practical - it can be designed once, and then repeated for almost zero cost.

This means that all forgeries and countermeasures are on a more massive scale, and (unless you are like me¹) some fake mail will arrive in your inbox, and it is up to you to filter it out manually.

Bottom line, just as you would not call a phone number on a letter to "verify your account information" (like your SSN, and Credit Card), you should also not click links in emails, and expect the login screen or whatever form to securely send the private information to your bank. If you do, you may find yourself sending your credentials to an impostor, and never realize it.

---

^1. I eliminated all of my spam. I have my own domain name. I give every contact their own email address, and it all lands into my one inbox. This way, if Bob gets a virus on his computer, and I start to get some of that low-level spam, then I can tell Bob to change his email password and to start using a new email address for his email to me. The new email address will not get any spam on it, and I can delete the old one, because only Bob was using it.

I don't have to go tell my bank, and my other buddies, my vendors, my co-workers, that my email address changed, because each has their own address. (I don't even have to update StackExchange and the Gravater.) This is good for me (no spam), good for Bob (he knows he has a "virus or something" - sometimes I can be direct, but one must be careful not to be wrong afterwards), good for my other buddies (I never complain about how many emails I got in the last 24 hours, and explain why I did not get back to them)

Answer 5

I think y'all have overlooked one small detail that was mentioned in the dramatization above, that is actually really easy to check:

Spoof emails do not come from an email address that legitimately belongs to the domain from which they claim to originate. Part of the SMTP protocol includes a set of full message headers that always includes the return path of the message, which is the email address that actually sent the message. Not only that, but IP addresses also have a definitive geographical region they're assigned to. So you can catch these discrepancies with a bit of digging.

Take, for example, said dramatization.

It mentions that the email is coming from whitehouse.gov. Here's its IP address:

calyodelphi@dragonpad:~ $ dig +short whitehouse.gov
173.223.0.110

Now, let's say that nastyhackerz.cn resolves to an IP address somewhere in the block 1.0.32.0-1.0.63.255 (for reference: http://www.nirsoft.net/countryip/cn.html first block in the list). That IP address is going to be in the full message headers. All you gotta do is take that IP online to track down its geolocation (you can use http://www.geoiptool.com/ for example)

The IP for whitehouse.gov (173.223.0.110) at the time of writing this post geolocates to Boston, Massachusetts (for some reason a spam prevention system won't let me post my search on geoiptool due to reputation points, so you can go do the search yourself) which is pretty close to home (District of Columbia)! Let's just assume that whitehouse.gov is hosted in a data center that's in Boston just to make this easier to explain.

As long as the IP and email address that the email was actually sent from does not match the IP and email address that the email claims to be sent from, it can be determined as spoof. You just need to look in the full message headers.

---

Let's look at the headers of an email I sent from one of my own domains (dragon-architect.com) to my own personal email address:

Delivered-To: [email protected]
Received: by 10.180.89.68 with SMTP id bm4csp105911wib;
    Tue, 29 Jan 2013 08:54:47 -0800 (PST)
X-Received: by 10.60.30.38 with SMTP id p6mr1296792oeh.2.1359478487251;
    Tue, 29 Jan 2013 08:54:47 -0800 (PST)
Return-Path: <[email protected]>
Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35])
    by mx.google.com with ESMTP id m7si14056914oee.29.2013.01.29.08.54.45;
    Tue, 29 Jan 2013 08:54:46 -0800 (PST)
Received-SPF: neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of [email protected]) client-ip=69.93.154.35;
Authentication-Results: mx.google.com;
   spf=neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of [email protected]) [email protected]
Received: by gateway14.websitewelcome.com (Postfix, from userid 5007)
    id 0530E1DFDB334; Tue, 29 Jan 2013 10:54:43 -0600 (CST)
Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130])
    by gateway14.websitewelcome.com (Postfix) with ESMTP id EA7191DFDB314
    for <[email protected]>; Tue, 29 Jan 2013 10:54:42 -0600 (CST)
Received: from [127.0.0.1] (port=43458 helo=dragon-architect.com)
    by bentley.websitewelcome.com with esmtpa (Exim 4.80)
    (envelope-from <[email protected]>)
    id 1U0ESK-0001KE-DP
    for [email protected]; Tue, 29 Jan 2013 10:54:44 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 29 Jan 2013 10:54:44 -0600
From: [email protected]
To: <[email protected]>
Subject: Headers Test
Message-ID: <[email protected]>
X-Sender: [email protected]
User-Agent: Roundcube Webmail/0.8.4
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - bentley.websitewelcome.com
X-AntiAbuse: Original Domain - gmail.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dragon-architect.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (dragon-architect.com) [127.0.0.1]:43458
X-Source-Auth: [email protected]
X-Email-Count: 1
X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20=

Testing testing!

That's a lot of random data to sift through, but there are two lines that we are looking at here: return-path and from. Since I legitimately sent this email to myself, they both match. The return-path cannot be spoofed. Or if it can, it's incredibly difficult to effectively spoof and requires some deliberate configuration of the SMTP daemon used to send mail. Comparing the return-path and the from data fields in the full headers is one way that I and my coworkers where I work can identify spoof and determine if a support ticket needs to be submitted.

So, what if they both match, but the email should still be spoof? I'll get to that in the next section...

---

Now, as mentioned before, there are other means of determining the spoofiness of an email. SPF records are one of those ways, but they're not always perfect. Take, for example, the SPF of whitehouse.gov, and compare it to the SPF of my own domain:

calyodelphi@dragonpad:~ $ dig +short txt whitehouse.gov
"v=spf1 +mx ~all"
calyodelphi@dragonpad:~ $ dig +short txt dragon-architect.com
"v=spf1 +a +mx +ip4:70.84.243.130 ?all"

Usually, a good SPF record also includes the IP address of the server that sent the mail, so whoever made the SPF record for whitehouse.gov probably doesn't know this. I would consider whitehouse.gov's SPF record to be too generic to be effective at determining the actual origins of any messages claiming to be from whitehouse.gov. The SPF for my own domain, on the other hand, which was automatically generated by the server that hosts my domain (courtesy of my webhost), is very specific and includes the IP address of the server itself.

I will admit to not being intimately familiar with how SPF records are formatted and how they work, but I've learned enough on my job that I can at least identify generic and specific SPF records. Guess that's something I should probably dig into some weekend when I'm bored and want some technical reading material!

Anyways, back on track here. Look at the Received lines. One of them states thus: Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Guess what? That matches the IP address in my domain's SPF record.

If the IP in the SPF doesn't match the IP of the server that actually sent the email, that's another indication that you've got spoof on your hands. Therefore, a generic SPF record like "v=spf1 +mx ~all" just isn't going to cut the security mustard. I wouldn't even trust emails coming from a legitimate domain that has a generic SPF like this.

Perhaps we should file a petition on petitions.whitehouse.gov to demand that their security admins revisit the SPF record they made for the domain! (I kid, I kid.)

EDIT

I actually have to MASSIVELY correct myself about SPF records! I made some wrong assumptions and learned a few things today after asking a coworker who was more in-the-know than I am about SPF records. So, I'll use the two SPFs for whitehouse.gov and dragon-architect.com in my self-correction:

calyodelphi@dragonpad:~ $ dig +short txt whitehouse.gov
"v=spf1 +mx ~all"
calyodelphi@dragonpad:~ $ dig +short txt dragon-architect.com
"v=spf1 +a +mx +ip4:70.84.243.130 ?all"

The SPF for my own domain is actually more lenient than the SPF for whitehouse.gov (something I plan to correct tonight after I finish this edit). I'll explain why:

"v=spf1 +mx ~all" basically says that emails from whitehouse.gov are supposed to come from the hostnames defined in the MX records for whitehouse.gov, and any emails that do not come from those hostnames are supposed to be spoof, but whether they're marked spoof or not is up to the recipient of the email.

calyodelphi@dragonpad:~ $ dig +short mx whitehouse.gov
110 mail6.eop.gov.
105 mail2.eop.gov.
110 mail5.eop.gov.
105 mail1.eop.gov.
105 mail4.eop.gov.
105 mail3.eop.gov.

"v=spf1 +a +mx +ip4:70.84.243.130 ?all" says that emails from dragon-architect.com are supposed to come from either the IP address for dragon-architect.com (67.18.28.78), the hostnames defined in the MX record(s) for dragon-architect.com, or the IP address of the server that hosts dragon-architect.com (70.84.243.130). Any emails that do not come from those, well, that ?all at the end just means that there's no advice on whether to pass or reject the emails.

So what's the meat and potatoes of an SPF record? The "all" at the very end. To quote this coworker about the "all":

+all basically means ALL pass -- the record is useless, sender domain doesn't care
?all indicates neutral and is advising to not pass or reject mail
~all indicates fail, and the server is considered invalid, but does not specifically suggest an action.
-all is a hard fail, anything else is invalid, reject or flag it.

So that "all" is where you define just how strict your SPF record is. But whether or not the SPF record is actually used to determine the spoofiness of an email is completely up to the receiving email service.

So there you have it. SPF in a nutshell.

---

So yeah. TL;DR: check your full headers to see if the return-path and from fields match. Then double-check your SPF records if there are any to see if you get matching IP addresses.

Answer 6

SMTP (Simple Mail Transfer Protocol) is named that for a very good reason.

SMTP originated in 1982 on the old ARPANET, which was owned and controlled by the US DoD, and intended for communication between people with security clearances working on government projects who could generally be trusted not to misuse it. "Security" of this network was accomplished quite simply by placing the machines that could connect to it within physically-secured areas of the various facilities, right alongside the classified work these facilities were performing. As a result, actually securing the data being sent along the network was generally not considered until after ARPANET was decommissioned, with the first quantum leap coming about 1993 with the Secure Network Programming API (which laid the foundations for Secure Sockets Layer, now generally known as Transport Layer Security). While most protocols (including SMTP/POP/IMAP) can now add TLS for a secure communications channel, all this provides is confidentiality, and server authenticity; it doesn't provide sender authenticity or message integrity, and it also does not provide non-repudiation.

There is an option available for e-mail security, called PGP (Pretty Good Privacy; it's Phil Zimmerman's tongue-in-cheek humor for a system that no computer on the planet could break if properly implemented). It can, with various options, provide all four fundamental tenets of information security; confidentiality, integrity, authenticity, and non-repudiation (the sender, who signed the e-mail using their certificate, can't claim that they didn't actually send it; nobody else could have, unless the certificate was compromised). It uses a similar system of public-key certificates and secure key exchange as is seen in a two-way TLS handshake, but some details are changed to reflect the asynchronous nature of e-mail transport, and to reflect the desire for a decentralized "web of trust" precluding the need for globally-trusted certificate authorities.

However, this system has yet to really take off despite being over 25 years old, and as such it is only required by government agencies and certain large corporations. Virtually all e-mail providers will still happily deliver fraudulent e-mails over secure connections to your inbox. You can, in many cases, encourage your friends and other people from whom you want to receive e-mail to adopt the PGP scheme, and anything not validly signed goes into "quarantine", but this is really just another level of "spam filtering", and I don't know of a single public e-mail provider that you can instruct to reject e-mails without a digital signature outright; the e-mail server would have to be under your control, such as a corporate Exchange server.

Answer 7

tl;dr

• Is Paypal exploiting a security issue here? ... How can PayPal spoof emails so easily?

Technically, no its not a security issue, email isn't secure to start with. They are using one of the following SMTP headers located in the message header (not envelope header)

1. Resent-From
2. Resent-Sender
3. Sender

There is a conceptual difference between "remailing" and "spoofing". The email client should display this difference. The Gmail client does not do this.

• Paypal isn't spoofing, they are using one of these SMTP headers: Resent-From, Resent-Sender, or Sender

• It's very easy to spoof a domain ...even with SPF controls enabled

• The MUA (email client) should display the Display From, its SPF, DKIM, and DMARC verification status.

• The Resent-* header should be used in in a way that makes it clear this message is "remailed".

• In general the the best solution is to use DKIM + DMARC, or SPF + DMARC and a MUA that displays the verification results.

---

Some background

Generally speaking, there are two "from" addresses and two "to" addresses in every SMTP message. One is known as the RFC2821 Envelope, the other is the RFC2822 Message. They serve different purposes

The Envelope: (RFC2821)

• The envelope is metadata that doesn't appear in the SMTP header. It disappears when the message goes to the next MTA.

• The RCPT From: is where the NDRs will go. If a message is coming from Postmaster or a remailer service this is usually <> or [email protected]. It's interesting to see that salesforce uses this similar to constantContact as a key in a database like [email protected] to see if the message bounced.

• The RCPT TO: is who the message is actually being sent to. It is used for "to" and "bcc" users alike. This doesn't usually affect the "display of addresses" in the mail client, but there are occasions where MTAs will display this field (if the RFC2822 headers are corrupt).

The Message (RFC2822)

• The message portion begins when the data command is issued.

• This information includes the SMTP headers you're familiar with, the message, and its attachments. Imagine all this data being copied and pasted from each MTA to the next, in succession until the message reaches the inbox.

• It is customary for each MTA to prefix the above mentioned copy and paste with information about the MTA (source IP, destination IP, etc). It also pastes the SPF check details.

• This is the Display From is placed. This is important. Spoofers are able to modify this.

• The Mail From: in the envelope is discarded and usually placed here as the return-path: address for NDRs

So how do we prevent people from modifying the Display From? Well DMARC redefines a second meaning for the SPF record. It recognizes that there is a difference between the Envelope From and the Display From, and that there are legitimate reasons for them to not match. Since SPF was originally defined to only care about Envelope From, if the Display From is different, DMARC will require a second DNS check to see if the message is allowed from that IP address.

To allow for forwarding scenarios, DMARC also allows the Display From to be cryptographically signed by DKIM, and if any unauthorized spammer or phisher were to attempt to assume that identity, the encryption would fail.

What is DKIM? DKIM is a lightweight encryption technology that signs the data residing in the message. if you ever received a message from Gmail, Yahoo, or AOL then your messages were DKIM signed. Point being is that no one will ever know youre using DKIM encryption and signing unless you look in the headers. It's transparent.

DKIM can usually survive being forwarded, and transfered to different MTAs. Something that SPF can't do. Email administrators can use this to our advantage to prevent spoofing.

---

The problem lies with the SPF only checking the RFC2821 envelope, and not the Display From. Since most people care about the Display From shown in an email message, and not the return path NDR, we need a solution to protect and secure this piece.

This is where DMARC comes in. DMARC allows you to use a combination of a modified SPF check or DKIM to verify the Display From. DKIM allows you to cryptographically sign the RFC2822 Display From whenever the SPF doesn't match the Display From (which happens frequently).

---

Is spoofing Display From a security issue?

Yes, phishing though email is a important security issue many vendors are looking at. Namely Paypal, AOL, Google, Yahoo and other companies are implementing DMARC to fix this very phishing issue.

Why is it still possible to forge "From: " header in e-mails?

Some server administrators haven't implemented the latest technologies to prevent this sort of thing from happening. One of the major things preventing adoption of these technologies is "email forwarding services" such as a mailing list software, auto-forwarders, or school alumni remailer (.forwarder). Namely:

1. Either SPF or DKIM isn't configured.

2. A DMARC policy isn't set up.

3. The email client isn't displaying the verification results of the Display From and the Resent-* or Sender field.

What is paypal doing?

Paypal is using the Sender header to indicate it was remailed. This is the correct and intended use of this header.

What is GMail doing wrong?

Gmail doesn't make it clear that the Sender header is being used, they don't validate the Display From address in a user friendly way, and it doesn't distinguish between display from and sender.

Answer 8

It has nothing to do with "spoofing" or deviousness of any kind.

For years and years many of us have received a copy of various forms in particular 'tell-a-friend' type forms etc where programmatically the 'from' address identifying the "user sender" is not one from the sending mail server although it is legitimate mail not through an open mail server used for relaying.

Perhaps a forum or guestbook program returns an internal "contact user" email "From:" identifying another user and not the home site.

When we set up our email clients WE can set the default "From:" address often totaly unrelated to the actual mail server.

In other words the defined 'from' address has absolutely nothing in reality to do with the machine performing the actual mailing.

Although these days in the case of 'spam-level scoring' it is risky to (SERVER SIDE) "programaticly" use from addresses not of the originating domain / machine we should take the "From:" address as merely nothing more than an identifier for human consumption.