Bounce back email SPAM?

G'day all,

I've got a client today who has started getting a heap of emails that appear to be a bounce back to a particular (generic) user - info@domain.com - see below

From: postmaster@ccla.local [mailto:postmaster@ccla.local]
Sent: Monday, 4 May 2015 9:20 PM
To: Info
Subject: Undeliverable: Pills for Health

Delivery has failed to these recipients or distribution lists:
mmalone@ccla.org
The recipient's e-mail address was not found in the recipient's e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.


Diagnostic information for administrators:

Generating server: ccla.local
mmalone@ccla.org
#< #5.1.1 smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found> #SMTP#
Original message headers:
Received: from 187-53-252-134.pltce701.dsl.brasiltelecom.net.br
 (187.53.252.134) by SERVER02.ccla.local (172.16.10.3) with Microsoft SMTP
 Server id 14.3.123.3; Mon, 4 May 2015 09:20:13 -0400
From: "mmalone@ccla.org" <info@domain.com>
To: <mmalone@ccla.org>
Subject: Pills for Health
Date: Mon, 4 May 2015 06:02:13 -0400
Message-ID: <003b01d08653$076576dc$87993f99$@domain.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Aca67quvds303nifa67quvds303nif==
Content-Language: en
x-cr-hashedpuzzle: 2D4= 7quv ds30 3nif a67q uvds 303n ifa6 7quv ds30 3nif a67q uvds 303n ifa6 7quv;1;ds303nifa67quvds303nifa67quvds303nifa67quvds303n;Sosha1_v1;7;{9936E9E2-C746-3DCC-63BC-B79213689936};ZQB3AGUAZg7quvds303nifa67quvds303nifa67quvds303n;4 May 2015 06:02:13 -0400;avv273navv273nav
x-cr-puzzleid: {9936E9E2-C746-3DCC-63BC-B79213689936}
Return-Path: info@domain.com
Received-SPF: None (SERVER02.ccla.local: info@domain.com does not
 designate permitted sender hosts)

I'm pretty certain that it is spammers trying to make use of another entry point, but what I can't figure out is that the SPAM engine doesn't mark it as SPAM.

I'm using Sophos PureMessage with the latest SPAM definitions of the day being enabled. Is this a configuration error?

Cheers in advance.

Steven Swarts
TechCare
sjswartsAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Cliff GaliherCommented:
You may have a compromised account which would bypass any spam filters. Or you may be experiencing a backscatter barrage, which is a method used to bypass some spam filters. Usually the proper use of SPF or DKIM can avoid backscatter.

http://en.m.wikipedia.org/wiki/Backscatter_(e-mail)
0
arnoldCommented:
The issue appears to be external to you.
There is only one entry indicating a connection to the mailserver.

Received: from 187-53-252-134.pltce701.dsl.brasiltelecom.net.br
 (187.53.252.134) by SERVER02.ccla.local (172.16.10.3) with Microsoft SMTP
 Server id 14.3.123.3; Mon, 4 May 2015 09:20:13 -0400

One option you might want to look at is using DNS rbl lists to reduce the likelihood that known spammers will directly try to send your own users using your domain.

As long as you have nit white listed your own domain, externally originating emails even when they use your own domain, might be detected.

The bounce/ndr does it include the entire original message, or the header you posted is the only thing?
0
Simon Butler (Sembee)ConsultantCommented:
It is an NDR. Most spam filters will ignore NDRs.

The user's email address is probably being used as the sender address for the spam, and the recipient is bouncing the email back to the "sender". The real problem is that the original recipient doesn't have their email setup correct and is accepting, then rejecting the email, rather than using recipient filtering.

Simon.
0
Introducing the "443 Security Simplified" Podcast

This new podcast puts you inside the minds of leading white-hat hackers and security researchers. Hosts Marc Laliberte and Corey Nachreiner turn complex security concepts into easily understood and actionable insights on the latest cyber security headlines and trends.

sjswartsAuthor Commented:
G'day all,

Thanks for the responses.

Maybe I should be some light on this a bit more. Basically I have one server with two domain's directed in. One was their old domain (old-domain.com) and the other is their new one (new-domain.com). Just recently I was asked to renew their old domain because they missed out on some big opportunities because they didn't respond to any email sent to them. I know people need to learn how to read NDR's but seriously in Australia most people just don't care. Very slack.

Anyway so I did my usual added it again to the accepted domain list in Exchange Management Console. Checked that all the correct email accounts had listed both the old and new domain as an email address again. Tested it and all is good.

However SPAM is now a big issue, they are getting 600 odd SPAM emails a day. Sophos is catching most of them, but a few are getting through. Mainly due to this NDR issue.

I do agree that the problem is most likely external. The only thing tying us is the use of the return email address.

It definitely is a NDR, at least one that looks like it and formatted like it. But can I mitigate against false NDR's ??

Although I some of what you are saying I am in no way proficient at understanding exactly what you all mean. So the newb approach please guys.

Steve
0
sjswartsAuthor Commented:
In relation to the proper SPF record I didn't have one on the newly renewed old-domain.com, would that cause this to happen?

I have since then configured one, but again I'm not proficient at this.

Steve
0
sjswartsAuthor Commented:
Just found this too:

https://www.sophos.com/en-us/support/knowledgebase/36854.aspx

See attached file.

But this would also block or quarantine in this case legitimate NDR's and I won't be around to keep checking if that is the case.
NDR-Block.txt
0
Cliff GaliherCommented:
I would just monitor after creating the SPF. You may find that resolves the issue.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sjswartsAuthor Commented:
Ok will do.

Funnily enough a friend of mine works at a fairly sized school as the IT Administrator. My dad also works at this school and he just came in with a similar SPAM email. Using his legitimate email address as the reply to.

I did find this link, currently still reading it.

http://www.gfi.com/whitepapers/ndr-spam.pdf
0
Simon Butler (Sembee)ConsultantCommented:
While an SPF record may help, if an administrator cannot setup their environment correctly to reject emails for users that do not exist, then they are unlikely to be using something as advanced as SPF records.

Simon.
0
sjswartsAuthor Commented:
Well that is helpful Simon.

The point is that the user DOES exist otherwise why would he/she receive the NDR message??
The problem is that if an organization uses NDR's (I'm led to believe that many do not), then how can you mitigate against this NDR Spam?

It is my understanding that the server DOES reject emails for users that do not exist.

Exchange Management Shell

get-recipientfilterconfig | ft RecipientValidationEnabled

Open in new window


True
0
Cliff GaliherCommented:
The issue is when the filtering occurs.  If the user filtering occurs during the SMTP connection then receiving machine simply rejects the connection and it is up to the sending machine to generate the NDR.  This can be exploited by machines misconfigured as an open relay, as they'll assume the sending address is correct and they are simply relaying.  An SPF record can and often will still work here because creating an open relay (or even a closed relay with a compromised account) can happen easily, but the relay server will not relay for your domain if it is still properly set up to filter SPF.  One misconfiguration does not necessarily mean the SPF filtering is also misconfigured.  

The other, more common, NDR generation, and what it appears you are seeing, is one where the receiving server is accepting the mail and then only checking the user after the connection and mail is received.  Because it accepted the mail, *it* is now responsible for generating the NDR.  And it'll happily send an NDR back to you, even though you weren't the real sender. Your sending address was spoofed.

This type of configuration was actually recommended because not rejecting connections based on user prevented a type of attack known as a directory harvest attack.  Spam bots would connect and then send a ton of addresses to see which ones the server rejected.  Not rejecting any, but later generating NDRs, prevented the bot from gathering and generating a list of valid emails without ever trying to send a message.  As such, for many years, configuring to prevent DHA was quite normal.  I've even seen Exchange 2010 print books and blog posts recommend this.  However with the rise in backscatter attacks, this configuration has fallen out of favor.  Most people consider a DHA attack a lesser risk than a backscatter attack, and filtering users inherently allows one or the other.

Again, an SPF record can help here because the admin may not have even "misconfigured" their server. They may be following old guidance, or may be one of the more rare admins that doesn't care of they get hit with the occasional backscatter (because they expect most domains to have SPF) and would rather prevent the DHA.  There is some validity to that decision as SPF is widespread so the connection creating the backscatter would still be rejected if the SPF record existed.

In any case, an SPF record helps prevent these types of NDRs regardless of which of the above is the case.  Nothing is 100%, but my experience has been that SPF is far more effective than it is being given credit for.  As I said, simply monitor for now. You may find your problem is resolved for the most part already.
0
sjswartsAuthor Commented:
Thank you Cliff,

Appreciate the effort.

Will continue to monitor.
0
Simon Butler (Sembee)ConsultantCommented:
DHA hasn't been a problem since Exchange 2003 introduced the tarpit. Exchange 2007 and higher has the tarpit enabled by default. Therefore there is no excuse not to have recipient filtering enabled.

Simon.
0
Cliff GaliherCommented:
Well, as it happens, the thread is not about debating the benefits or costs of DHA vs backscatter.  Nor would the op have control over the server that is configured contrary to your preference. So the debate is moot in this instance. While I happen to agree with you that filtering recipients makes more sense in most instances, it doesn't really keep this thread on topic and I don't see the benefit of the debate here and now. I only mentioned it as an explanation to why an SPF record can and often is still effective, which *does* help the op with their immediate problem.
0
sjswartsAuthor Commented:
Apparently after successfully creating a SPF record and letting it propagate, the "Spam" NDR's are no longer being received.
The only other thing I did was I noticed that Sophos PureMessage was set to have the Router's IP and a bunch of other IP's as a trusted relay. I removed them.

Otherwise I'm happy to report that it seems the issue has been resolved. Thank you all for your contributions.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
SBS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.