I have a really wierd scenario that I ran into today that I didn't think was possible. I got a report from a user that they got a Spam message, and I tracked it back (I will save you the story of how) to having been originated through another user's mailbox. The thing is the FROM address was not the sending user's address but rather an outside address (listed below), which is really perplexing to me because when I try to use an outside FROM address Exchange NDR's it back to me saying I don't have permissions to send on behalf of that user. I also inspected the user's mailbox and found no evidence of such a message in their sent items or any other folders (or deleted item cache), so if a message was in fact sent through the user's mailbox it was done so w/o leaving a copy in the sent items. A little about our enviornment - fully Exchange 2007 SP3 RU2, with CCR mailbox servers and dedicated Hub Transport Servers (HTSs). Everything runs on Windows 2008 SP2. Here is the message tracking log entry indicating the message originated from the user's mailbox: Timestamp : 1/14/2011 8:12:55 AM ClientIp : 169.254.1.250 (this type of address seems to be used when messages are submitted to a clustered mailbox server as it is consistent). ClientHostname : CCRMBX5 ServerIp : ServerHostname : HTS1 SourceContext : MDB:c260c314-bb0a-42d8-b1e8-c02d5a0ee480, Mailbox:37a2b443-d5d8-4445-b897-d206719e97a4, Event:16239192, MessageClass:IPM.Note, CreationTime:2011-01-14T13:12:54.708Z, ClientType:Transport ConnectorId : Source : STOREDRIVER EventId : SUBMIT InternalMessageId : MessageId : 6DD43DAB38A96942ACC1D13CEAC2F8500FB040CEC7@CCRMBX5@company.com Recipients : {} RecipientStatus : {} TotalBytes : RecipientCount : RelatedRecipientAddress : Reference : MessageSubject : Come in and Save! WINTER SALE @ Eneslow. Keep Yourself Warm for Less! Sender : newsletter@eneslow.com ReturnPath : MessageInfo : I had two separate incidents involving to separate mailbox GUIDs, and I was able to track both mailboxs GUID back a user accounts using the ADFIND syntax: adfind -sc adguid:37a2b443-d5d8-4445-b897-d206719e97a4 ObjectGUID CN SN Does anyone have any ideas of how or why Exchange would have accepted this message when the sender/from address was not one the user's AD account was authorized to send as? I am really confused as to how this was even possible given the fact that Exchange NDR's my attempts to do this. We have engaged our security team to figure out if their machines are infected or not,

How are you sure it came from the other user’s mailbox in the first place? Is it possible it came from the user’s computer but not via MAPI? Mike Crowley Check out My Blog!

The only thing I have to go on are the Exchange tracking logs that so the message was submitted on the Mailbox server, and that the HTSs distributed it. To my knowledge the only way to submit a message through to the store driver is through MAPI access. I could be totally wrong though. All I have to go one is this: SourceContext : MDB:c260c314-bb0a-42d8-b1e8-c02d5a0ee480, Mailbox:37a2b443-d5d8-4445-b897-d206719e97a4, Event:16239192, MessageClass:IPM.Note, CreationTime:2011-01-14T13:12:54.708Z, ClientType:Transport It was a submited IPM.Note through the Mailbox with the associated GUID. At least I think I am reading that correctly, but feel free to correct me.

Hello HotFix, It seams spoofing is happening. In E2K7 server :-- If you are alredy using Antispam feature then Uninstall the Antispam from the server and again Reinstalled it . Install the Anti Spam on the E2K7 server and configure it:- Content Filter, IP block list providers, Recipient Filtering & Sender filtering (Add the Self Domain) How to install Microsoft Anti Spam Agents on Exchange 2007 http://support.microsoft.com/kb/555924 Managing Anti-Spam and Antivirus Features http://technet.microsoft.com/en-us/library/aa996604.aspx => And updated the AntispamUpdates Enable-AntispamUpdates -Identity <SERVERNAME> -IPReputationUpdatesEnabled $True -MicrosoftUpdate RequestNotifyDownload -UpdateMode Automatic -SpamSignatureUpdatesEnabled $True How to Configure Anti-Spam Automatic Updates http://technet.microsoft.com/en-us/library/bb125199(EXCHG.80).aspx => Restart the Transport service on E2K7 server It will fix the issue.EXCHANGE2010, MCSE, MCTS, MCSA MESSAGING, CCNA & GNIIT

I don't have Exchange 2007 anti-Spam filtering installed, nor am I leveraging that aspect of Forefront Protection 2010 for Exchange. I already have a border level protection in place that is working quite well, and I really don't want to add another layer of anti-Spam services to the mix just for this unique instance. The issue as I see it is that normally Exchange doesn't allow someone to fake a FROM address through a normal mailbox submission. In this case the sumbissions would have had to occured through MAPI or ActiveSync, because there is only the mailbox role installed on that server, and to my knowledge those are the only two protocols that would allow a STOREDRIVER submission. So how is it that this malware (I'm guessing that's what originated this message) managed to send a message through the person's mailbox (which is again how I read what happened in the transport logs but I could be wrong), and fake the FROM address? Every time I try to put an outside address on the FROM line, Exchange (not Outlook) rejects the message saying I don't have permissions. So why didn't this permission restriction rejection occur in the case I ran into? I have seen 2 other cases where someone gets infected and starts spewing forth Spam internally, but their own FROM address is always used and their Sent Items reflects the messages sent in these cases so it's easy to track what happened. In this one unique scenario both the FROM address and Sent Items do not indicate that the Spam came from an internal person, which is what is making me question the 2 entries in my transport logs. So please can anyone absolutely confirm that the message tracking log entry I posted 100% means the message came through the user's credentials on the mailbox server in the form of a STOREDRIVER submission, and if that is the case does anyone know why Exchange allowed it to occur when it seems to have restrictions in place every time I try to test it? Thanks

Can you check the source's mailbox to ensure there aren't permissions where they shouldn't be? (Including groups and nested groups) Mike Crowley Check out My Blog!

Hi, I suspected that the client computer infected the virus which simulates the email was sent from the MAPI Client. I suggest you temporary remove this computer and create that profile in another computer, then check this issue. Thanks AllenAllen Song

@Mike - I double checked both mailboxes in question and they had no unusual permissions on them. Also I am pretty sure this was either MAPI or ActiveSync because the message originated on a CCR mailbox server with no other roles installed. I.E. It couldn't have been through the SMTP service as I don't think we would get the SourceContent data nor would it have originated on the mailbox server as a submission. Again I could be reading this all wrong and making bad assumptions, I just don't know how else to read what I am seeing. @Allen - We have asked our security team to investigate the desktops and report back to us what they found. As soon as they report back I will share what we found. I am dumfounded how this suspected Spam/Virus program was able to use a different FROM address. I didn't think that was possible. Thanks all!

I feel like a moron. After digging around a little in a user's mailbox a little more I came accross this rule: Apply this rule after the message arrives, where my name is in the To box, redirect it to outsideemail@outsideemailsystem.com except if it is an Out of Office message. In hindsight the re-direct method was the only way the FROM address would be allowed to be "faked" like this, as normally Exchange would prevent it. I feel really dumb for not checking the rules of the user, but users are told not to forward email to an outside email system so why on earth would they (insert sarcasm here). At the very least I was reading the transport logs correctly. So chalk this one up to users being inventive in a way we didn't anticipate (considering they were told not to do this).

lol, it got the best of all of us. :) Mike Crowley Check out My Blog!