
Ask HN: A spammer is spoofing my email address; what do I do? - hellofunk
About every 15 seconds all day, another Mail Delivery Subsystem Status Notification Failure pops in from random servers around the world for some email that supposedly I sent, but of course did not. Apparently someone is sending out thousands of emails as coming from my address, and there is nothing I can do about it, right? Here are my questions:<p>1) Or, is there something I can do about this?
2) Will this cause my email address to end up on blacklists and cause me significant problems?
3) Why in 2016 are Internet mechanisms not in place to prevent stuff like this?
======
bks
This is commonly known as a Joe Job -
[https://en.wikipedia.org/wiki/Joe_job](https://en.wikipedia.org/wiki/Joe_job)

Steps to mitigate.

1\. Setup SPF immediately. You can validate your records here-
[http://www.kitterman.com/spf/validate.html](http://www.kitterman.com/spf/validate.html)

You'll have to know who you send email through and their SPF record, but a
quick googling of "provider name SPF" should get you what you need.

Depending on your DNS provider the results may be instant.

2\. Filter those bounces keep them out of your inbox - it's going to take
while until this clears up.

3\. Make sure that YOU are not hacked, check the headers of the bounce back
messages here -
[http://mxtoolbox.com/EmailHeaders.aspx](http://mxtoolbox.com/EmailHeaders.aspx)

Ensure that your IP or hostname is not listed there. (This includes web
servers that your domain is hosted on, apps that send on your behalf etc)

4\. You can check to see if your domain is black listed -
[http://mxtoolbox.com/blacklists.aspx](http://mxtoolbox.com/blacklists.aspx)
probably not...but worth a check.

TL;DR - I run one of the largest spam filtering companies in the world.
Happens all day to clients...it's one of the reasons people switch to us.

~~~
linkregister
UPDATE: The OP is using GMail. This doesn't apply to her/him but it's still
good advice so I'm keeping it up.

I think it's also worthwhile to mention DMARC:
[https://dmarc.org/overview/](https://dmarc.org/overview/). Most of the major
Email Service Providors (ESPs) support it.

SPF and DKIM signatures are two data points to help form an opinion about
whether a message is legitimate. DMARC is your published policy about what to
do with email that fails SPF and DKIM. If you have the strictest DMARC policy
along with good SPF and DKIM records, and you're signing all your outgoing
email correctly with DKIM, then this should solve your problem.

It's recommended to start with the most permissive DMARC settings (p=none) so
you can make sure you don't prematurely block your own outgoing email.

I work for one of the larger (by market share) "send email via an API"
services. This is a common issue we come across with our customers.

~~~
jsvaughan
+1 for DMARC - you can set your policy to ask the recipient to reject (or mark
as spam) anything that fails the DMARC check. But yes, it is tricky to get
right, so go for no action initially and monitor the reports.

------
gupi
There are already mechanisms to prevent the spoofing of legit email addresses.
See details below:

DKIM -
[https://support.google.com/a/answer/174124?hl=en](https://support.google.com/a/answer/174124?hl=en)

SPF -
[https://support.google.com/a/answer/33786?hl=en](https://support.google.com/a/answer/33786?hl=en)

Dmarc -
[https://support.google.com/a/answer/2466580?hl=en](https://support.google.com/a/answer/2466580?hl=en)

However, implementing needs support from your email/hosting provider.

~~~
verst
I used to work on Spam, Abuse and Deliverability for Google Apps and am one of
the original authors of those help center articles (although they have been
changed a bunch since).

Can you share the full message headers of one of these bounces you are
receiving? Feel free to redact your email address.
[https://support.google.com/mail/answer/22454?hl=en](https://support.google.com/mail/answer/22454?hl=en)

Edit: I left Google in 2013

~~~
js2
I switched my domain away from Google Apps to Fastmail because Google was hard
bouncing emails that I sent to other Google Apps domains. I had both SPF and
DKIM set up correctly. I could send emails to gmail.com addresses just fine,
and to Google Apps addresses that weren't aliases (which Google implements via
groups as I recall). But anything that went to a Google Apps destination
address that was a group alias would bounce. I was on the grandfathered free
tier so I coudldn't really complain, but it was the final straw the drove me
to Fastmail. Now I can email those same addresses which used to bounce just
fine.

~~~
verst
Google Apps does have email aliases (they are really just pointers to regular
Google Apps Gmail accounts).

Google Groups uses a different sub system internally, and if you don't have
SPF configured (or configured it wrong) it definitely rejects messages
aggressively or queues them for moderation.

Virtually every problem where legitimate mail to any of your Google Apps email
addresses (or groups) bounced could be addressed by adding DKIM and SPF. Some
folks have strange dual delivery set ups, or perhaps use an outbound gateway
server (for compliance filtering, journaling etc) - in those cases you
definitely need to adjust the SPF records accordingly.

I never tried Fastmail before, maybe I'll check it out :)

~~~
js2
I'm fairly certain I had DKIM and SPF set up correctly. It was literally only
when emailing another Google Apps+Google Group address that bounced. It looked
like this:

    
    
        Delivery to the following recipient failed permanently:
    
        hi@smashrun.com
    
        Technical details of permanent failure:
    
        Message rejected by Google Groups. Please visit http://mail.google.com/support/bin/answer.py?hl=en&answer=188131 to review our Bulk Email Senders Guidelines.
    

Full headers:

    
    
        X-Received: by 10.55.15.30 with SMTP id z30mr25314313qkg.47.1440345211659;
               Sun, 23 Aug 2015 08:53:31 -0700 (PDT)
        Return-Path: <js2@example.org>
        Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com. [2607:f8b0:400d:c09::232])
               by mx.google.com with ESMTPS id 136si23593726qhc.102.2015.08.23.08.53.31
               for <hi@smashrun.com>
               (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
               Sun, 23 Aug 2015 08:53:31 -0700 (PDT)
        Received-SPF: pass (google.com: domain of js2@example.org designates 2607:f8b0:400d:c09::232 as permitted sender) client-ip=2607:f8b0:400d:c09::232;
        Authentication-Results: mx.google.com;
              spf=pass (google.com: domain of js2@example.org designates 2607:f8b0:400d:c09::232 as permitted sender) smtp.mailfrom=js2@example.org;
              dkim=pass header.i=@example.org
        Received: by qkda128 with SMTP id a128so5917057qkd.3
               for <hi@smashrun.com>; Sun, 23 Aug 2015 08:53:31 -0700 (PDT)
        DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
               d=example.org; s=google;
               h=from:content-type:content-transfer-encoding:mime-version:subject
                :message-id:date:to;
               bh=D6Jgw+8F97OpSz0ORbLuvcih9KdhWrTFusiNkbOms2w=;
               b=0X7YTsfGYQ31fR8zT8Vc4+7iYOtUmQT/kNx7SKdNyx9GxPPHo9kTqFxWhBHEKUbLiU
                zd0iFHh12IVn993lvSIkBLIBHnTaQSxgt7vpxCKhSGlvuJ1jbocHtCmYvF+FNwyiZAgE
                SNiTXBBmxCc7Z4g9GW0PGDz0hNbRp+PBJfabY=
        X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
               d=1e100.net; s=20130820;
               h=x-gm-message-state:from:content-type:content-transfer-encoding
                :mime-version:subject:message-id:date:to;
               bh=D6Jgw+8F97OpSz0ORbLuvcih9KdhWrTFusiNkbOms2w=;
               b=DfuecqdbbnVwcjQsa8Aon9ukQYC43RYb5V3uWnb3ayZzZagDyT7aVg8StcSjh9HsFZ
                +OPKwfULiQc9u3twxq5h/Q7urZQIlY/FVyBAXQbikK+c8rzfb9nB+2cSBZHPYrlgU0hd
                ZO/n0x7x6OsCOWePFVcO2sc9EEO6+YsoeapsnzAaWKgYxF2T8v34UPimKPKBtphJ7N3a
                W7anf2KbbGcsXSQiz+EfWgeNwhLMKSk5V8g0aXrCSMDXcPf20NW6NnKbcYms/rOIQRSM
                +J44wGA+rau6Wv+/0GA+XkGUOYpISMC2ATrEOO9/6XmmQSGmo3vb4oUSg9UmUCNGSVzY
                wKWg==
        X-Gm-Message-State: ALoCoQkfkZy/EZ2g8DXjWbFZEEaJou2F+r9Vhn5u4/H4A+bq9ZT/2IYeptS95RrShLFAzNDp9Bwd
        X-Received: by 10.55.21.140 with SMTP id 12mr3454160qkv.31.1440345211394;
               Sun, 23 Aug 2015 08:53:31 -0700 (PDT)
        Return-Path: <js2@example.org>
        Received: from [192.168.1.131] (cpe-XXX-XX-XXX-XXX.nc.res.rr.com. [XXX.XX.XXX.XXX])
               by smtp.gmail.com with ESMTPSA id x201sm9160834qkx.28.2015.08.23.08.53.30
               for <hi@smashrun.com>
               (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
               Sun, 23 Aug 2015 08:53:30 -0700 (PDT)
        From: js2 <js2@example.org>
    
    

This would fail 100% of the time when mailing any other Google Apps+Google
Groups address, no matter the message content. I had failures from three
separate Google Apps hosted domains over the course of a year. Once I moved my
domain from Google Apps to Fastmail, this stopped happening.

Yes, I pay Fastmail and I wasn't paying for Google Apps. But I also get
responsive support from Fastmail, IMAP push to iOS devices, more flexibility
in delivery rules, etc.

~~~
verst
Google Groups has a feature to automatically reject messages it considers to
be Spam. That feature has always been quite terrible. The Google Groups
Backend hasn't changed in a very long time.

[https://support.google.com/groups/answer/2627595?hl=en](https://support.google.com/groups/answer/2627595?hl=en)

I personally always disable it for public groups and then rely on Spam
filtering of the recipient inbox.

By the way - the bounce message you are seeing is what is sent when the Spam
Classification Server determined your message to be Spam. The main reasons for
that are things like sending from a bad IP, having certain keywords that are
strongly correlated with Spam, or having domains in your message that are
associated with Spam (based on other messages having been marked as Spam
containing those domains).

~~~
js2
Re: Spam Classification Server. The problem went away when I moved my domain
away from Google Apps. Literally, the exact same test message that I could not
send when I had my domain on Google Apps, I could send once my domain was on
Fastmail. Nothing changed, but that my message was now routing via Fastmail's
SMTP servers vs the Google Apps SMTP servers. Same message content, same
client IP, same MUA, same destination (I had a friend with a Google Apps
domain setup a test group for me to send to on his domain).

~~~
verst
So you are saying:

Google Apps SMTP -> Google Apps Group (different domain) == FAIL

Fastmail SMTP -> Google Apps Group (different domain) == SUCCESS?

It's been a long time since I looked at this. We did have great internal tools
to look up the classification of individual messages, including the top 10
deciding reasons for a given message classification. With a paid Google Apps
domain a support rep investigating your ticket would eventually look at this
tool to figure out what's going on.

~~~
js2
Yup, that's what was happening. Re: a paid account, I decided Fastmail was a
better fit for my needs. Besides that, the problem was on the receiving end.
So I somewhat disagree that I should have had to pay Google for someone to
look into that.

------
Animats
I had to deal with a joe-job problem once, but it was over a decade ago. I was
getting over 20,000 email bounces an hour. I looked at the spam emails, and
put considerable work into hassling the hosting providers that were hosting
the spam targets. I had the advantage that I owned the domain name as a
registered trademark, and could go after the hosting site as assisting in
trademark infringement.

Once I discovered that the spammer was doing credit card fraud, and paying for
their hosting with stolen credit cards, my conversations with hosting
companies became even more effective, and the target sites were shut down
within hours. Finally, the spammer retreated to an ISP in St. Petersburgh,
Russia. It took a while, but it turned out that the CEO was an American expat,
and we had some mutual friends. We had a nice chat. He told me the problem
would be taken care of. The spam stopped shortly thereafter and never resumed.

It's much harder now, because spammers use botnets. On the other hand, after
the CAN-SPAM act, "legitimate" spamming almost disappeared. Nobody spams from
their own site any more, because spam filters will blacklist them. If they
spam with phony origination, they're a crook, and can be prosecuted, so nobody
legit spams with a phony source. The stuff that's left is all criminal, and
because the number of spammer crooks really isn't that large, the spam gets
picked up by classifiers that can see the commonality across destinations.
(That's Gmail's edge.)

------
kogir
I had this problem. Back when I finally took action I was receiving 500+
bounce notifications a day.

If you fully and correctly implement SPF[1], DKIM[2], and DMARC[3], you'll see
a massive improvement as much of the SPAM gets dropped completely at recipient
MTAs.

To fully solve the problem, you need something to filter the backscatter[4] .
At the time I purchased Postini, but now that Google has bought them, Google
Apps for Work seems to have this feature built in. There may also be software
you can run on your own server, or other proxy services like Postini. I've not
looked since I use Google Apps for work. Such filters simply track all
outgoing messages you send, and reject bounces from addresses and domains you
never emailed.

This has complete solved my problem. Now I only get regular SPAM, a fact of
life now.

In practice, all these things together look like this for kogir.com:

    
    
        @ IN TXT "v=spf1 redirect=_spf.google.com"
    	_dmarc IN TXT "v=DMARC1; adkim=r; aspf=r; p=reject; pct=100; rf=afrf; ri=86400; rua=mailto:dmarc@kogir.com; ruf=mailto:dmarc@kogir.com; sp=reject;"
        mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCFlfDA1Gpz8BQVpcNsiDkSp6ayVCWKlfeYXhiW0CaCgJJJkBpZj9E9OGMGUSAFFgEhCs8wf/fZCx9jsWkH34joEuylNnBnGt8exPSokLwrtubTQajOZcUgbpUlxwyCkyuE41mbpYUfWkPCOaRTa1VqZVWYs+ZdEkYaKXh9UALYeQIDAQAB"
    	

The _sp=reject_ in the DMARC record is very important, but only works if all
valid email from your domain will pass both the SPF and DKIM checks.

[1] [http://www.openspf.org/](http://www.openspf.org/)

[2] [http://www.dkim.org/](http://www.dkim.org/)

[3] [https://dmarc.org/](https://dmarc.org/)

[4]
[https://en.wikipedia.org/wiki/Backscatter_(email)](https://en.wikipedia.org/wiki/Backscatter_\(email\))

~~~
Sephr
> The sp=reject in the DMARC record is very important

sp=reject is already implied by your p=reject. You only ever need to specify
sp= when it is different from your p=.

Additionally, adkim=r; aspf=r; pct=100; rf=afrf; and ri=86400; are all
implicit defaults.

~~~
kogir
You're right, I just looked for reject and picked the first I saw.

As for the defaults, you have much more faith in other people's correct
implementation of them than I do. Why not just be explicit?

~~~
nostrebored
do you think QA has done a better job testing the default implementation or
flag permutations?

------
spdustin
Postmark has a free tool to set up and monitor DMARC, which is another policy
setting that can be used (if you own your domain) so that major email
providers know whether or not to trust an email claiming to be from you.
Postmark's tool lets you get digests and nice visuals of these automated ISP
reports rather than you figuring out how to parse the XML they'd normally send
directly to you.

Disclosure: I'm not at all affiliated with Postmark, I use their free tier
transactional emails, and I use their DMARC tool.

[https://dmarc.postmarkapp.com](https://dmarc.postmarkapp.com)

------
mod
Not very helpful, but a neat story:

When I was a kid on AOL in ~2000 I made some script-kiddie mad and he did this
to me. One angry person replied to me, and I explained what was going on. He
took some convincing, but eventually he believed me. He became my good friend
--I've even met him in person. I'm really thankful it happened.

------
gargalatas
Everyone here told you that you have to use spf. But beaware that you need to
put the directive -all and not the ~all. Just take care of this point as it's
very important!

Second please check all of your systems that your email password is entered
atleast once. Maybe a system has a spyware or virus or something.

Third change your email's password.

Except you are 100% sure that the spammer is not using your MTA then you just
use an spf with the -all directive!

------
OSButler
It's extremely annoying, but usually the attacker will switch to another
domain after a few hours or days. The mail notifications can be delayed by a
few days, depending on the individual mail server's settings, so you should
see a slowdown of the incoming bounce messages after a while before it will
stop eventually.

------
paste0x78
This actually just happened to me yesterday. The spammer actually added a SPF
record for another host he apparently had control of.

Removing the bad SPF record and updating passwords fix it for me.

Still waiting on my web hosting provider to see if it was changed from my
account with a valid login or if they were compromised in some way.

------
tacone
In addition to all the other excellent answers:

Change your password. Check your settings for unknown API tokens or any app
you may have given to the permission to access your Google account.

------
cweagans
IMO, this is a good reason to use a provider that will let you use your own
domain. I recommend Fastmail. I've been using them for a while and have been
very happy with them. The chances of some spammer spoofing
you@somerandomdomain.com are much smaller than with username@gmail.com.

~~~
derekp7
True, unless you have a wildcard user for your domain. Whenever I give out my
email, I typically add a unique identifier to the user name, so I can have
something like "xyzHN@example.com". Then if I start getting spam, I know who
leaked my email address.

The problem that happened then is someone was using random users@example.com
causing the blowback spam to fill up my mail box. Until I added SPF, then
hadn't had an issue since.

~~~
varjag
There is a standard syntax for subaddresses with '+' suffix, e.g.
foo+oneoff@bar.com: the replies will end up at foo@bar.com. Wildcards in email
domains are a bad idea and been so for many years.

[https://en.wikipedia.org/wiki/Email_address#Sub-
addressing](https://en.wikipedia.org/wiki/Email_address#Sub-addressing)

~~~
justinlardinois
The problem with using a standard convention for this sort of thing is that
it's easy to detect and subvert (in this case, drop the + character and
everything following it from the username).

If I sign up for, say, a Sears mailing list with the address
sears@justinlardinois.com, it's not possible to divine what my "real" email
address is.

What are the arguments for this being a bad idea?

~~~
varjag
You can just use one subscription address for all unimportant services, thus
using e.g. subscription+sears@justinlardinois.com.

> What are the arguments for this being a bad idea?

It enables spammers _and_ makes you vulnerable to their backscatter, and there
is no good way around it.

~~~
icebraining
_You can just use one subscription address for all unimportant services, thus
using e.g. subscription+sears@justinlardinois.com._

Yes, but if they drop the "+sears" part, you lose the tracking information.

What do you mean by wildcard emails enabling spammers?

Backscatter is not really a problem, I just filter non-whitelisted addresses
to another folder which deletes them after a short while. Known problematic
address get filtered to /dev/null. This is really easy to do with Sieve.

------
samwillis
Do check that no one has hacked your email and is sending from it. You said
that its a gmail account; spf will all be allready setup.

It's quite common to see people have their gmail accounts hacked and used for
spam.

~~~
hellofunk
I assume if it was hacked, I'd see the sent mails in my sent folder or in
trash, no? I have 2-factor setup on my account so I doubt it was hacked.

~~~
fjarlq
Go through this Security Checkup of your Google account just to be sure:

[https://security.google.com/settings/security/secureaccount](https://security.google.com/settings/security/secureaccount)

I use 2-factor auth, but I had a significant discrepancy in this checkup
recently that I'm still trying to understand.

------
jontanemobay
is this a yahoo/gmail or similar , or are you using your own domain. You won't
get blacklisted if someone is spoofing your yahoo/gmail because their already
are mechanisms to validate spoof'd vs legitimate messages. If you are using
your own domain look into setting up SPF , DKIM and DMARC records .

~~~
hellofunk
It's my gmail account. According to a doc I just find on Gmail's site, they
recommend reporting the bounced messages themselves as Spam, so I've done
that.

~~~
linkregister
Because GMail uses SPF, DKIM, and DMARC effectively, I'd say you shouldn't
worry about it in general. And I can't really think of anything you could do
short of using another email address or provider.

The major email service providers (GMail, Yahoo, Hotmail, iCloud, AOL,
Comcast) should already be sticking these spoofed emails in their recipients'
spam folders.

If you rely on communication with a less- or un-managed email server, then you
might have issues, since they might not be filtering based off of SPF, DKIM
signatures, or DMARC policy.

