±Forensic Focus Partners
New Today: 0
New Yesterday: 0
· Extracting data from dump of mobile devices running Android operating system
· Development of Digital Forensic Tools on Mobile Device, a Potential Area to Consider?
· Can You Get That License Plate?
· How To Decrypt WeChat EnMicroMsg.db Database?
· A guide to RegRipper and the art of timeline building
· Recovering Evidence from SSD Drives in 2014: Understanding TRIM, Garbage Collection and Exclusions
· FT Cyber Security Summit 2014 – Recap
· Why Offender Profiling is Changing Thanks to Mobile Forensics and Increasingly ‘Social’ Criminal Activity
· Understanding Cyber Bullying – Notes for Digital Forensics Examiners
±Follow Forensic Focus
X-Originating-IP with two IPs ?!?
A Mail Header shows after X-Originating-IP two IPs. What does this mean?
X-Originating-IP: [126.96.36.199, 188.8.131.52] <-- What does this mean?
Date: Tue, 8 Apr 2014 15:29:04 +0800
- Senior Member
- wechselbergerA Mail Header shows after X-Originating-IP two IPs. What does this mean?
Whatever the MTA (or MUA or firewall or application proxy or ...) that created it means. (It needn't come from an MTA: it could theoretically have come from the mail client or any other point of network transmission that the message passed through. MTAs that don't recognize that particular header will probably just pass it on.)
RFC 822 (which is now obsolete) allowed 'extension fields', following the format of 'X-...' in mail messages. The current specification RFC 2822 does not so, and RFC 6648 / BCP 178 deprecates the use of 'X-...' type headers. Thus, it's nonstandard today.
As far as RFC 822 goes, extensions field may have been registered, but as it now is obsolete, I suspect any such registrations may have become obsolete as well. You may want to check with the registrar, mentioned in RFC822 (SRI International) for any records.
Apart from that, as it is a nonstandard header, you can't trust it to mean anything in general. If you are able to identify the source of it, you might be able to attach a meaning to it.
You could start by examining any X-Mailer: or similar headers -- do those programs add this kind of header? And what semantics to they associate with it, i.e. what assertations can safely be made on the basis of that particular header?
The reason BCP 178 depractes the use of extension fields is that they usually cause more problems than they solve. Which is more or less what you have discovered.
Added: In highly configurable and scriptable mail environments, the contents of extension fields could also be misconfigurations. For example, if Exchange allows the mail admin to add this field to outgoing messages, it could be that the mail admin added information useful for his own environment, but which may not make sense elsewhere. In such cases, you clearly need to find that mail admin to interpret the header...
- Senior Member