• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 347
  • Last Modified:

Mystery email delivery

We have an Exchange 2010 (SBS) server which is delivering small amounts of spam to a particular address that doesn't (or shouldn't) exist. The email appears to be being sent to nonexistantuser@domain.com and it's being delivered to user1@domain.com, user2@domain.com and user3@domain.com - This suggests it might be an address on an internal distribution list but we can't find anything to support this theory. It's only a small company so we've been through the Exchange mailboxes looking for this address but can't find it anywhere.

In short, it's being received on an address that shouldn't exist and it's arriving in several people's (but not eveyone's) mailboxes.

Looking at the header of the email, there's no evidence to suggest that it's being received on a BCC - the only email addresses mentioned are the sender and the unknown address on our client's domain.

The server is generally well configured and not set to receive 'catch all' emails.

The email also shows that it has been scanned for malware prior to delivery which suggests that it doesn't originate from within the local network since the scanning is outsourced and only scans external emails.

Any ideas?
  • 8
  • 5
  • 2
  • +1
1 Solution
David AtkinTechnical DirectorCommented:

Have you tried running a query in active directory for the unknown email address? It may be setup as an alias for a group.

edz_pgtAuthor Commented:
Thanks - some interesting ways to find addresses there. However, this PowerShell command returns nothing (I entered the actual email address in the search string!):

get-recipient | where {$_.emailaddresses -match “foo@domain.com”} | select name,emailaddresses

Looks like the server isn't aware of this address?
David AtkinTechnical DirectorCommented:
Interesting.  Have you tried emailing the address yourself to see if it actually delivers?

Also, in your Anti-Spam settings do you have 'Black Messages sent to recipients that do not existing in the directory' ticked?    (Org Conf>Hub Transport> Anti-Spam> Recipient filtering>Blocked Recipients)
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

What kind of SPAM filter are you using? I'm guessing your server may be the source of the SPAM and I'd investigate that. At DNS stuff there's a load of tools that can help you.

Here is the SPF record for domain.com it lists all the IP addresses in use for sending mail. Now you can try blocking those IP's using your Exchange tools or your firewall.

"v=spf1 mx ip4: ip4: ip4: ip4: ip4: include:rnmk.com include:custhelp.com include:salesforce.com include:emailbrain.com -all"

If you block mail from those IP's and you are still getting the spam make sure your SPAM filter is doing reverse lookups on domains and checking their SPF records.
edz_pgtAuthor Commented:
Good thinking.

Yes, there's a tick in that box.

Sending an email to that address from outside actually bounces back as undeliverable so this must be being sent some other way.

I'd like to have someone send an email internally but they've all gone home now.

Am I correct in thinking that the header code in an email message will always display the receiving email address even if it's received on a BCC address?
I've done a test using a couple of unrelated email addresses and and I can see the BCC'd address in my received test message. I would just like to rule this out though.
David AtkinTechnical DirectorCommented:
You could log into OWA as the admin and send the message.  If you don't get a bounce back then check the tracking logs to see where its gone.
Simon Butler (Sembee)ConsultantCommented:
Sounds like standard spoofed sender spam.
Looking in the headers for evidence of BCC isn't going to help, because there will be none - otherwise it wouldn't be a blind copy.

Standard spammers technique is to put an email address in the target domain in the To line, BCC all other recipients, in the hope that the email admin has whitelisted their own domain.

If there are headers then it is coming from outside, so you need to look at the whitelisting to see if the domain has been whitelisted.

David AtkinTechnical DirectorCommented:
The price of on line email filtering is relatively low now. It would be worth considering it.

I can recommend Spambrella.
edz_pgtAuthor Commented:
Hi Simon,

I'm not sure why you'd say that. I tested the BCC theory before I suggested it. I agree that showing all BCC addresses in the header as it goes to each recipient doesn't happen and would be stupid. However, each recipient does see their own address in the header as in the following header. This header was taken from the email received by the BCC recipient in my test:

Delivered-To: bcc-address@recipient2.com
Received: by with SMTP id 3csp144600pah;
        Mon, 3 Feb 2014 07:48:36 -0800 (PST)
X-Received: by with SMTP id r1mr634812eep.113.1391442516299;
        Mon, 03 Feb 2014 07:48:36 -0800 (PST)
Return-Path: <sender@sender.com>
Received: from psmtp.com (eu1sys200amx136.postini.com [])
        by mx.google.com with SMTP id h44si20604870eew.59.2014.
        for <bcc-address@recipient2.com>
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Mon, 03 Feb 2014 07:48:36 -0800 (PST)
Received-SPF: pass (google.com: domain of sender@sender.com designates as permitted sender) client-ip=;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of sender@sender.com designates as permitted sender) smtp.mail=sender@sender.com
Received: from emea01-am1-obe.outbound.protection.outlook.com ([]) (using TLSv1) by eu1sys200amx136.postini.com ([]) with SMTP;
	Mon, 03 Feb 2014 15:48:28 GMT
Received: from DB3PR05MB025.eurprd05.prod.outlook.com ( by
 DB3PR05MB027.eurprd05.prod.outlook.com ( with Microsoft SMTP
 Server (TLS) id 15.0.868.8; Mon, 3 Feb 2014 15:48:26 +0000
Received: from DB3PR05MB025.eurprd05.prod.outlook.com ([]) by
 DB3PR05MB025.eurprd05.prod.outlook.com ([]) with mapi id
 15.00.0868.013; Mon, 3 Feb 2014 15:48:25 +0000
From: Joe Soap <sender@sender.com>
To: "to-address@recipient1.com" <to-address@recipient1.com>
Subject: RE: Message1545
Thread-Topic: Message1545
Thread-Index: AQHPIPb+pMsdheql6UiMIvVckYdT7pqjrLLF
Date: Mon, 3 Feb 2014 15:48:25 +0000
Message-ID: <5b8ff4d33d754d8097592a8d5339f8f8@DB3PR05MB025.eurprd05.prod.outlook.com>
References: <CAOWh5tQ8zVEGiCQQA1MyvJ6mWcmi8bGwTyVv1w_=70J9tDaQCw@mail.gmail.com>
In-Reply-To: <CAOWh5tQ8zVEGiCQQA1MyvJ6mWcmi8bGwTyVv1w_=70J9tDaQCw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
x-originating-ip: []
x-forefront-prvs: 01110342A5
x-forefront-antispam-report: SFV:NSPM;SFS:(10009001)(71364002)(189002)(199002)(74316001)(53806001)(76482001)(85306002)(83322001)(51856001)(80022001)(66066001)(65816001)(19580395003)(87936001)(54356001)(16236675002)(63696002)(54316002)(76576001)(47446002)(74502001)(56776001)(74662001)(31966008)(74706001)(76796001)(19580405001)(76786001)(80976001)(46102001)(79102001)(33646001)(85806002)(2656002)(74876001)(15202345003)(92566001)(89136003)(77096001)(19617315010)(64872005)(15975445006)(94946001)(83072002)(18206015023)(86442001)(94316002)(81342001)(81816001)(81686001)(81542001)(87266001)(93136001)(85852003)(77982001)(59766001)(74366001)(56816005)(90146001)(93516002)(86362001)(1411001)(4396001)(50986001)(69226001)(47976001)(47736001)(49866001)(146863001)(24736002)(83022001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB3PR05MB027;H:DB3PR05MB025.eurprd05.prod.outlook.com;CLIP:;FPR:F4CC45AC.AC25DF59.1BD353A4.44E1E84C.2024C;InfoNoRecordsMX:1;A:0;LANG:en;
Content-Type: multipart/alternative;
MIME-Version: 1.0
X-OriginatorOrg: lindaven.onmicrosoft.com
X-pstn-neptune: 0/0/0.00/0
X-pstn-levels: (S:96.66745/99.90000 CV:99.9000 FC:95.5390 LC:95.5390 R:95.9108 P:95.9108 M:97.0282 C:98.6951 )
X-pstn-dkim: 0 skipped:not-enabled
X-pstn-settings: 3 (1.0000:1.0000) s cv gt4 gt3 gt2 gt1 r p m c
X-pstn-addresses: from <sender@sender.com> [2647/102]
X-pstn-nxpr: disp=neutral, envrcpt=bcc-address@recipient2.com
X-pstn-nxp: bodyHash=1a0f69c71150adbee4143727f4424f3567feba13, headerHash=b3f7fa74e98e3ea4f24b337bfa509ac5d7be8a63, keyName=4, rcptHash=8f59433f85a37ca384160df276de5819f18f00a1, sourceip=, version=1

Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Open in new window

edz_pgtAuthor Commented:
Thanks David but the mail is filtered externally. As I say, the mail bounces back if you try to email in to that address from outside.

I will hopefully try the OWA test you suggested shortly though - thanks.
Simon Butler (Sembee)ConsultantCommented:
Its spam - therefore the header information cannot be trusted. Nothing in the header is worth looking at because it is usually all faked.

edz_pgtAuthor Commented:
Would whatever lies the spam had in it not be appended by the Exchange server as it passed through it?
edz_pgtAuthor Commented:
The internal email failed to send. So, it must be received on a different address. I am puzzled as to how it arrives without headers being added by the server though.
David AtkinTechnical DirectorCommented:
As Simon said, it will be BCC'ing various other addresses as well.  So although it says its sending to an unknown email address its probably bcc'd their actual addresses.

You could try blocking the source IP address but they will likely change it in the future.
edz_pgtAuthor Commented:
This was actually received in tact by the spam filtering service (3rd party) but the headers we needed to see were stripped before it was forwarded to us.

We were receiving the BCC as we'd originally suspected but the headers were tampered with and this threw us off. It wasn't spoofed by the spammer though. When we got the full message from the filtering company it all made sense.
edz_pgtAuthor Commented:
Thanks for your hints guys.
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.

Join & Write a Comment

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

  • 8
  • 5
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now