Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This question already has an answer here:

I receive Mailer Daemon messages saying certain emails fail. My domain is itaccess.org which is administered by Google apps. Is there any way I can identify who is sending emails from my domain, and how they are doing it without me creating an account for them?

Delivered-To: 7e949ba@itaccess.org
Received: by 10.142.152.34 with SMTP id z34csp12042wfd;
        Wed, 8 Aug 2012 07:12:46 -0700 (PDT)
Received: by 10.152.112.34 with SMTP id in2mr18229790lab.6.1344435165782;
        Wed, 08 Aug 2012 07:12:45 -0700 (PDT)
Return-Path: <whao@www20.aname.net>
Received: from smtp-gw.fsdata.se (smtp-gw.fsdata.se. [195.35.82.145])
        by mx.google.com with ESMTP id b9si24888989lbg.77.2012.08.08.07.12.44;
        Wed, 08 Aug 2012 07:12:45 -0700 (PDT)
Received-SPF: neutral (google.com: 195.35.82.145 is neither permitted nor denied by best guess record for domain of whao@www20.aname.net) client-ip=195.35.82.145;
Authentication-Results: mx.google.com; spf=neutral (google.com: 195.35.82.145 is neither permitted nor denied by best guess record for domain of whao@www20.aname.net) smtp.mail=whao@www20.aname.net
Received: from www20.aname.net (www20.aname.net [89.221.250.20])
    by smtp-gw.fsdata.se (8.14.3/8.13.8) with ESMTP id q78EChia020085
    for <7E949BA@itaccess.org>; Wed, 8 Aug 2012 16:12:43 +0200
Received: from www20.aname.net (localhost [127.0.0.1])
    by www20.aname.net (8.14.3/8.14.3) with ESMTP id q78ECgQ1013882
    for <7E949BA@itaccess.org>; Wed, 8 Aug 2012 16:12:42 +0200
Received: (from whao@localhost)
    by www20.aname.net (8.14.3/8.12.0/Submit) id q78ECgKn013879;
    Wed, 8 Aug 2012 16:12:42 +0200
Date: Wed, 8 Aug 2012 16:12:42 +0200
Message-Id: <201208081412.q78ECgKn013879@www20.aname.net>
To: 7E949BA@itaccess.org
References: <20120808171231.CAC5128A79D815BC08430@USER-PC>
In-Reply-To: <20120808171231.CAC5128A79D815BC08430@USER-PC>
X-Loop: whao@whao.se
From: MAILER-DAEMON@whao.se
Subject: whao.se:  kontot avstängt - account closed
X-FS-SpamAssassinScore: 1.8
X-FS-SpamAssassinRules: ALL_TRUSTED,DCC_CHECK,FRT_CONTACT,SUBJECT_NEEDS_ENCODING

    Detta är ett automatiskt svar från F S Data - http://www.fsdata.se

    Kontot för domänen whao.se är tillsvidare avstängt.
    För mer information, kontakta info@fsdata.se

    Mvh,
    /F S Data

    -----

  This is an automatic reply from F S Data - http://www.fsdata.se

  The domain account "whao.se" is closed.
  For further information, please contact info@fsdata.se

  Best regards,
  /F S Data
share|improve this question
13  
Just in case you wish to further search the web for that problem, the common term for that kind of email misuse is called Joe Job. –  Oliver Aug 8 '12 at 14:56
    
btw regarding "technology liberates us all" - i grossly disagree –  Артём Царионов Aug 8 '12 at 17:02
15  
The problem is NOT that someone is claiming to be YOU (your domain), but rather, that someone (else) is believing them. If I send email to you claiming it is FROM Barack Obama, would you believe me? Of course not. You are getting "backscatter". Complain to those who have accepted the spoofed email ("joe job") and accepted that the from address was correct. But do this ONLY if your domain offers SPF records that show where (addresses, hosts) the only valid mail can come from. –  Skaperen Aug 9 '12 at 1:36
add comment

marked as duplicate by Chris S Dec 18 '13 at 19:27

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

9 Answers

up vote 88 down vote accepted

Since it hasn't been explicitly stated yet, I'll state it.

No one's using your domain to send spam.

They're using spoofed sender data to generate an email that looks like it's from your domain. It's about as easy as putting a fake return address on a piece of postal mail, so no, there's really no way to stop it. SPF (as suggested) can make it easier for other mail servers to identify email that actually comes from your domain and email that doesn't, but just like you can't stop me from putting your postal address as the return address on all the death threats I mail, you can't stop someone from putting your domain as the reply-to address on their spam.

SMTP just wasn't designed to be secure, and it isn't.

share|improve this answer
28  
+1 for the postal mail analogy. That's the one I always use with non-technical people. Nobody has to break into your house to send an outgoing piece of mail with your return address on it. They just need to be able to drop it into a mailbox. –  Evan Anderson Aug 8 '12 at 20:42
1  
You may want to explicitly link to answers instead of just saying "as suggested" –  Thorbjørn Ravn Andersen Aug 8 '12 at 21:56
12  
Really? You're the one sending all those death threats?!? :) –  John Robertson Aug 9 '12 at 0:15
add comment

It is the nature of SMTP (the protocol used to transfer mail) that no validation is done on the sender address listed in an email. If you want to send an email that appears to come from president@whitehouse.gov...you can go ahead and do that, and in many cases there's nothing anyone can do to stop you.

Having said that, if you establish SPF records for your domain, there's a better chance that receiving systems will recognize the forged email as spam. An SPF records identifies systems that are allowed to originate mail for your domain. Not all receiving systems pay attention to SPF records, but larger email providers will use this information.

share|improve this answer
17  
Specifically for Google Apps you can follow these steps. –  Byte56 Aug 8 '12 at 21:51
    
I have this problem at the moment, too, and my SPF records are correct. Unfortunately, a lot of big mail providers ignore SPF records. Including such luminaries as Yahoo. :-( –  staticsan Aug 9 '12 at 1:58
6  
Don't forget about DomainKeys. DKIM. –  desbest Aug 9 '12 at 13:22
add comment

I endorse the answers already given regarding SPF (+1, each of you!) but please note that if you decide to go this way - and it's a good way - there is no point in doing it unless you identify and advertise all hosts that are approved to send email for your domain, and hard-disallow all others with -all.

Not only will ?all and ~all not have the desired effect, but some mail admins on SF regard them as a sign of a positively-spammy sender domain.

share|improve this answer
8  
Google's guidance on creating an SPF entry for domains using Google Apps to send mail: "Publishing an SPF record that uses -all instead of ~all may result in delivery problems." –  Ariel Aug 8 '12 at 21:32
7  
Yes, it may, that's the whole point of it. As long as you've exhaustively listed those hosts who may legitimately send your mail, you want all other hosts to have delivery problems; the problems will only affect you if you've failed to list all your valid sending hosts, and that's what google's referring to. See Chris S's comment on serverfault.com/questions/374452/… for one example of an admin who takes against useless (lacking a -all) SPF records. –  MadHatter Aug 9 '12 at 5:50
    
But if you use -all, anyone who uses mail forwarding will not receive the mail. I believe people still use mail forwarding (whether they should use it is another question) –  netvope Sep 24 '12 at 13:56
    
You're absolutely right, but that's what SRS (Sender Rewriting System) is for. I'd argue that it should be understood that SPF and simple (non-SRS) forwarding are mutually-exclusive and that admins should pick just one, not that you can still use SPF alongside simple forwarding if you just change -all to eg ~all. That's essentially not using SPF at all. –  MadHatter Sep 24 '12 at 14:12
add comment

Sender Policy Framework (SPF) can help. It is an email validation system designed to prevent email spam by verifying sender IP addresses. SPF allows administrators to specify which hosts are allowed to send mail from a given domain by creating a specific SPF record (or TXT record) in the Domain Name System (DNS). Mail exchangers use the DNS to check that mail from a given domain is being sent by a host sanctioned by that domain's administrators.

share|improve this answer
add comment

It doesn't look like a SPF would have helped in this particular example. A machine that was bothering to check SPF records to reject mail is unlikely to be so broken as to accept mail for a nonexistent domain, then decide it can't deliver it and generate the bounce message. If mail-gw01.fsdata.se, the machine accepting mail for whao.se, had bounced it properly, your bounce message would be coming from a Google SMTP server.

Sadly, this kind of broken behavior (accepting and later generating a bounce) is not that uncommon. There is not a thing you can do to keep some random machine from pretending it has a message to deliver from your domain. There is also not a thing you can do about delayed bounces.

You can, however, have less of these blowback bounces to read. If 7E949BA is not a real user on itaccess.org, as I suspect it may not be, you're getting the bounce message because you have your catch-all address enabled. A catch-all means that your domain will accept email for any non-existent user and deliver it to you. This is primarily a good way to grow your collection of spam and bounce messages. In Google Apps, to configure your catch-all, it's under "Manage this domain" -> Settings -> Email, about halfway down.

share|improve this answer
add comment

What yo are referring to is actually called a BACKSCATTER attack. what is it actually, its explained well above. how to solve it??

Backscatter can be preveted with self hosted solutions like Postfix, qmail and exim etc, but not with googleapps, as its popular for not having protection present for dealing with backscatter, Except only SPF records.

share|improve this answer
add comment

An idea not yet mentioned is to reject the backscatter. All of it that I've seen comes through open mail relays, and there are two blackhole lists which you may find useful for reducing the amount of backscatter you receive.

  • Backscatterer is a DNSBL which explicitly lists SMTP servers that send backscatter and sender callouts.

  • RFC-Ignorant is a DNSBL which lists SMTP servers that do not obey various important RFCs.

Adding these in (along with several other more traditionally focused BLs) reduced the amount of backscatter that I receive by over 90%.

share|improve this answer
add comment

The mail system relies on From: headers, which are really easy to spoof.

For instance, this PHP code:

mail('someone@live.com', 'Your new Outlook alias is ready to go', 'Ha ha! This is spoofed!', "From: Outlook Team<member_services@live.com>\r\n");

will send an email to someone@live.com pretending to be the Outlook Team.

share|improve this answer
1  
No, it relies on the SMTP "envelope" sender (and recipients, too) (the ones sent in the MAIL FROM command), which can be completely different than the From: header. –  derobert Aug 13 '12 at 18:58
    
@derobert Okay, I didn't know that. Thanks! –  uınbɐɥs Aug 13 '12 at 20:35
2  
Please go ahead and edit your post to correct it… that's one of the many encouraged reasons to use the edit link. –  derobert Aug 14 '12 at 14:42
add comment

As the other answers have mentioned, you're receiving bounces from someone else's emails. SpamCop has previously not called this spam, but these days it accepts reports for this. E.g. I copied the message you quoted (and I've included my Gmail account to determine my mailhosts) and got this result (which I cancelled).

In summary, you can use SpamCop to report the senders of these bounces. It doesn't (directly) stop the initiators of the problem, but it may reduce these bounces.

share|improve this answer
add comment

protected by voretaq7 Aug 27 '12 at 19:19

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.