For the past week our company's IDS has been blocking 100-200 meeting invite emails per day from a specific client that are loaded with buffer overflows targeted at Exchange 2003. The payloads are harmless to us, but the flood of logs is annoying to say the least. I have been in contact with the IT manager at the client company and have been assured there's no record of these emails originating from their mail server, yet the attacks are only picking up speed and coming from more addresses on their domain every day. It looks pretty clear to us that there's an infection spreading through their domain, but they maintain that their system is clean. We're reasonably certain it's not coming from any of our machines because the emails are getting blocked before they even enter our network. If the attacks truly are not originating from them, how can we track down their source? Or what kinds of evidence can we gather to prove it really is from the client?

1 Answer 1


The email headers should suffice (see "email header ip address for an example of how to read them."). Perhaps post them here as well.

I want to emphasize that while only the most recent header line is absolutely reliable, header information is really the only information about email origin that you can obtain.

You could email a copy of the headers to the "sender", and they should then have enough information to confirm or deny - but it is up to them to have the desire, expertise and diligence to do something about it. As the old saying goes, "You can lead a horse to water, but you can't make him participate in synchronized swimming."

If you suspect the headers are not reliable, then the only recourse is to slowly work backwards through each intermediate MTA, each time confirming that the header line matches their logs. This would allow you to prove who the sending MTA was with absolute certainty, but:

  • It's a HUGE amount of work. Several hours at least.
  • You'd have to be quick, as many large mail systems can't store log data for long due to the volume of storage required
  • You'd have to be lucky, and hope that every intermediate MTA co-operates with you

Even if you succeed, the sender can still choose to ignore you (it's their mail server after all), in which case your only remaining recourse is to report the spam to blacklist providers.

  • Good info, thanks for the tip. I'll dig through the headers and see what turns up. I would really hate to blacklist this client because we do a lot of business with them and that would make a lot of people very upset, so it's worth a little extra effort to be absolutely sure before we point the finger at anyone.
    – thanby
    Commented Dec 26, 2013 at 17:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .