±Forensic Focus Partners
New Today: 3
New Yesterday: 11
±Forensic Focus Partner Links
· SQLite Database Forensics – ‘Sleep Cycle’ Case Study
· Data Recovery As A Medium For Email Forensics
· Carving out the Difference between Computer Forensics and E-Discovery
· Forensic Analysis of SQLite Databases: Free Lists, Write Ahead Log, Unallocated Space and Carving
· How Secure Is Your Password? A Friendly Advice from a Company That Breaks Passwords
· Using SQL as a date/time conversion tool
· Forensics and Bitcoin
· Investigation and Intelligence Framework (IIF) – an evidence extraction model for investigation
· Extracting data from dump of mobile devices running Android operating system
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