What can I do about a spammer using my email address?
January 8, 2005 3:42 PM Subscribe
A spammer is sending out spam using MY email address and name as the sender. I am getting hundreds of bounced emails now. Is there any way to stop this from continuing, or happening in the first place?
Well, I guess you could setup a procmail recipe that tosses the bounces to /dev/null so you wouldn't have to keep seeing them.
posted by cmonkey at 3:46 PM on January 8, 2005
posted by cmonkey at 3:46 PM on January 8, 2005
Sorry, I have to second the no. This happens to me on an almost daily basis, to the tune of hundreds of bounces every week. Some spam company really likes using one of my strange sounding domain names.
On preview - there are ways to avoid seeing the bounces, but no way to actually stop the messages.
posted by bh at 3:48 PM on January 8, 2005
On preview - there are ways to avoid seeing the bounces, but no way to actually stop the messages.
posted by bh at 3:48 PM on January 8, 2005
Not much you can do save for trying to block the undeliverables via pattern-match.
This is called a "joe job". More info here ; site responsible for the term here.
posted by aberrant at 3:49 PM on January 8, 2005
This is called a "joe job". More info here ; site responsible for the term here.
posted by aberrant at 3:49 PM on January 8, 2005
This happens to me on an almost daily basis, to the tune of hundreds of bounces every week.
Yeah, me too.
posted by Steve_at_Linnwood at 4:19 PM on January 8, 2005
Yeah, me too.
posted by Steve_at_Linnwood at 4:19 PM on January 8, 2005
Spammers seem much less inclined to joe-job accounts from domains that implement SPF -- it's not to their advantage to give recipients' filters a reason to discard the message unseen. But none of your lame-assed SPF records that allow "softfails", but a complete, definitive SPF record. I used to get joe-jobbed on one of my domains all the time, but since implementing hard SPF it almost never happens. Ask your provider to do it. They probably won't (if they were going to they would have already) but it's worth asking.
posted by George_Spiggott at 5:03 PM on January 8, 2005
posted by George_Spiggott at 5:03 PM on January 8, 2005
Ah, this has a name.... I've been seeing this for literally about four years. Never knew it had a name until just now. When it first started happening, I went nuts trying to track it down, and finally accepted that it wasn't caused by anything I could un-do. (Though I have taken care with all domains I've bought since then to make sure that everything that's not actually addressed somewhere valid gets blackholed...)
posted by lodurr at 7:11 PM on January 8, 2005
posted by lodurr at 7:11 PM on January 8, 2005
Short of using PGP (or GnuPG) to digitally sign your messages, and having your users throw away messages from you that aren't digitally signed, there's not much you can do.
There are equivalents of packet shapers for junk email, but that would be more for your system administrators to handle.
posted by AlexReynolds at 7:54 PM on January 8, 2005
There are equivalents of packet shapers for junk email, but that would be more for your system administrators to handle.
posted by AlexReynolds at 7:54 PM on January 8, 2005
SPF stands for Sender Policy Framework -- it's a new draft internet standard for preventing the sort of sender address spoofing we're talking about. There's some resistance to it because it has a few side effects and it doesn't really stop spam; if it becomes very widely adopted it should in theory put an end to spoofing but that's all.
It's a way that domain administrators can identify which IP addresses may legitimately send mail claiming to be "From" their domain. The idea is that receiving mail systems can check that the system that sends mail purporting to be from a particular domain is authorized by that domain to do so. If the domain doesn't identify the sending server as authorized to send mail on its behalf, the receiving mail system can flag it as suspect or even discard it outright.
It's not something an end user can manage personally unless you manage your domain's DNS records and you also either control the mail server(s) for your domain or at least are reasonably knowledgeable about what they are and confident they won't change. In a nutshell, unless you're your own sysadmin, it's more something to bug your sysadmin about than to do yourself.
posted by George_Spiggott at 8:22 PM on January 8, 2005
It's a way that domain administrators can identify which IP addresses may legitimately send mail claiming to be "From" their domain. The idea is that receiving mail systems can check that the system that sends mail purporting to be from a particular domain is authorized by that domain to do so. If the domain doesn't identify the sending server as authorized to send mail on its behalf, the receiving mail system can flag it as suspect or even discard it outright.
It's not something an end user can manage personally unless you manage your domain's DNS records and you also either control the mail server(s) for your domain or at least are reasonably knowledgeable about what they are and confident they won't change. In a nutshell, unless you're your own sysadmin, it's more something to bug your sysadmin about than to do yourself.
posted by George_Spiggott at 8:22 PM on January 8, 2005
I get a couple thousand joe job bounces every single day. Your only recourse is to dedicate your life to tracking each spammer down and beating them to a bloody mess with a tire iron. If you need a partner, give me a holler.
posted by majcher at 8:28 PM on January 8, 2005
posted by majcher at 8:28 PM on January 8, 2005
SPF is Sender Policy Framework, which is essentially verification of information in an MTA host's DNS records. What this means, is that essentially all email is spam and is dropped, unless it comes from a host that has certain information in its DNS records. This is not something end users can do.
posted by AlexReynolds at 8:28 PM on January 8, 2005
posted by AlexReynolds at 8:28 PM on January 8, 2005
I'd also mention that client-side bayesian spam filtering will catch most of these. As will server-side for that matter, but that's less within your control.
posted by kavasa at 10:55 AM on January 9, 2005
posted by kavasa at 10:55 AM on January 9, 2005
None of the solutions for this problem (SPF, DomainKeys) are widely implemented. As such, spammers seem content to send spam that fails spf and DomainKey tests.
I pulled some quick statistics from our anti-spam service db and it appears that spammers don't bother checking their source domains. This is probably because almost no recipients block messages that fail spf. Also, spammers tend to be completely retarded.
So unfortunately I have no useful advice for you other than filter out the bounce messages on the client, and pray you don't run into any vengeful morons who actually think you sent the spam.
posted by mosch at 9:44 PM on January 9, 2005
I pulled some quick statistics from our anti-spam service db and it appears that spammers don't bother checking their source domains. This is probably because almost no recipients block messages that fail spf. Also, spammers tend to be completely retarded.
So unfortunately I have no useful advice for you other than filter out the bounce messages on the client, and pray you don't run into any vengeful morons who actually think you sent the spam.
posted by mosch at 9:44 PM on January 9, 2005
Since so many mentioned SPF specifically... It might be worth getting that sorted out? It seems the one everyone has heard of and thus might implement....eventually. :)
posted by dabitch at 3:20 AM on January 11, 2005
posted by dabitch at 3:20 AM on January 11, 2005
« Older How to View eBay Prices as Item With Shipping... | How much are you like or different from your... Newer »
This thread is closed to new comments.
posted by cmonkey at 3:45 PM on January 8, 2005