±Partners and Sponsors
New Today: 0
New Yesterday: 2
· Understanding Cyber Bullying – Notes for Digital Forensics Examiners
· Investigating the Dark Web – The Challenges of Online Anonymity for Digital Forensics Examiners
· The Complete Workflow of Forensic Image and Video Analysis
· Browser Anti Forensics
· Coming apart at the SIEMs …
· WeChat Forensics
· DFRWS Europe 2014 Annual Conference – Recap
· Considering A Career in Audio-Video Forensics? Enhance Your Prospects With Continuing Education
· Forensics Europe Expo 2014 – Recap
±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: [220.127.116.11, 18.104.22.168] <-- 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