Re: Decoding Internet headers in email
From: Alun Jones [MSFT] (alunj_at_online.microsoft.com)
Date: 01/28/05
- Next message: Alun Jones [MSFT]: "Re: Security hole in file sharing (bug?)"
- Previous message: Seeker: "Re: Missing Firewall in XP"
- In reply to: N. Miller: "Re: Decoding Internet headers in email"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 28 Jan 2005 11:59:33 -0800
"N. Miller" <anonymous@discussions.microsoft.com> wrote in message
news:MPG.1c622dda561b414098a5f2@msnews.microsoft.com...
> In article <#rIN7rS4EHA.936@TK2MSFTNGP12.phx.gbl>, Alun Jones [MSFT]
> says...
>
>> "N. Miller" <anonymous@discussions.microsoft.com> wrote in message
>> news:MPG.1c26e46621de82ec98a540@msnews.microsoft.com...
>
>> > No. The only line that can't be spoofed is the one written by your
>> > server
>> > when it identifies the IP address of the sending server. Everything
>> > else
>> > is trivially faked or forged.
>
>> Even some of that information is spoofable.
>
> But not, as I mentioned, the IP address.
What you said was that this _line_ can't be spoofed. Some of the
information in that line can be spoofed, at least in terms of trying to fool
the neophyte header reader. Stupid tricks like including underscore
characters in the SMTP name to make it look like part of the name is an IP
address, that can make a "Received" header that confuses many readers. As
you mention, the IP address that is output by the SMTP server into the
Received header is not spoofable, but may be ignored by someone looking at
what he thinks is an IP address.
I gave an example of how such a Received header might look like - the IP
address is not spoofed, but the user might pick something that he thinks is
the IP address, instead of the actual IP address.
>> ...and the receiver's name is configured in your SMTP server.
>
> Not that I am aware of. The SMTP server may run a DNS lookup to determine
> the name of the incoming connection. It can't know the name of the
> incoming
> connection otherwise. Well, unless it builds a huge database, which would
> need constant updates to keep up with DNS changes. But why do that when
> the
> server can just query the DNS system?
I should say "might be" configured. Certainly, everything in that Received
header is generated by the SMTP server, and _usually_ includes the IP
address of the incoming connection, and the name of the receiver.
Note that when I say the "receiver's name", I mean the name of the SMTP
server that received the connection. This doesn't require a DNS lookup (and
certainly not a huge database), and might not even be a name that DNS
recognises - it could very well be a locally known nickname for the server -
"The SMTP server on the South Wall of Building 17", say. Okay, that's a
little long-winded and unnecessary, but when the Received header says
"Received: From client.example.com ([10.1.2.3]) by foobar with generic-MTA;
Fri, 28 Jan 2005 01:02:03 GMT for <fred@genericom.invalid>", the string
"foobar" represents the receiver's name.
I think you may have been confused into thinking that I was talking about
the sending MTA, not the receiving MTA.
> None of which I dispute; but I did mention that only the IP address is not
> spoofable. Well, there would be no point in trying to spoof the IP address
> because the MX would try to complete the TCP handshake with the spoofed IP
> address, and the spoofer would never see the results of the SMTP
> transaction.
... There have been examples of connection spoofing. You need a few things
to be in place - predictable ISNs and response lengths, a spoofed IP address
that won't return RSTs until after your spoofing is done, etc, etc. SMTP is
one protocol where an MUA / MTA could potentially prepare the entire
transaction offline and force-feed it into a TCP pipe whose responses the
MUA / MTA can't see.
But yes, practically speaking, the IP is not spoofed.
>> Reading email headers is an art, and you should use email headers as
>> information to determine who to complain to, never to launch a
>> retributive
>> attack.
>
> I don't recall saying anything about retribution. I do agree that reading
> headers can be tricky. It helps to know your own mail hosts; otherwise you
> can't be sure of anything about the headers that you see. The only reasons
> to even bother learning to interpret headers is to set up client filters,
> if
> your client is more capable than MS Outlook Express, and find out where to
> lodge complaints.
I was anticipating that some unhappy recipients of spam might consider
retribution against the spammers, or where they are perceived to be from.
This has happened on numerous occasions in the past, and I was hoping to
reduce the chance that it would happen as a result of this thread.
Alun.
~~~~
- Next message: Alun Jones [MSFT]: "Re: Security hole in file sharing (bug?)"
- Previous message: Seeker: "Re: Missing Firewall in XP"
- In reply to: N. Miller: "Re: Decoding Internet headers in email"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
