Microsoft Outlook email - Fake or spoofed email details

"barrowhill" wrote in message
...
A friend of mine has started to receive mail from himself ! i.e the
to and
from fields contain his details. This sound like spoofing to me.
He would
like to be able to stop these but my knowledge is limited. I've
looked and
the properties of received mail and copied below - friends email
details
changed to

Return-Path:
Received: from aamtain09-winn.ispmail.ntl.com ([81.103.221.35])
by mtain05-winn.ispmail.ntl.com with ESMTP
id

for ; Wed, 29 Aug 2007 12:05:25 +0100
Received: from cyc ([59.152.179.108]) by
aamtain09-winn.ispmail.ntl.com
with SMTP
id
20070829110525.UJUH6763.aamtain09-winn.ispmail.ntl.com@cyc
for ; Wed, 29 Aug 2007 12:05:25 +0100
Content-Return: allowed
X-Mailer: CME-V6.5.4.3; MSN
Return-Path:
Received: (qmail 13813 by uid 398); Wed, 29 Aug 2007 08:05:31 +0900
Message-Id: 20070829170531.13815.qmail@cyc
To:
Subject: - Sale
From:
MIME-Version: 1.0
Importance: High
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Date: Wed, 29 Aug 2007 12:05:25 +0100

Can anyone help and advise what could/should be done next. ?????

To To, Cc, and Bcc fields displaying in your e-mail client are just
that: fields. They are NOT the headers used in delivering e-mails.
The e-mail client compiles an aggregate of recipients from the To, Cc,
and Bcc fields and sends a RCPT-TO command for each one to the mail
server. That is followed by one DATA command to send the e-mail
message (which includes the header and body sections that are the
*data* composed by the user and his e-mail client). Fact is, no one
needs to be specified in the To, Cc, and Bcc fields in an e-mail
client to have the e-mail delivered. For bulk mailing programs, a
separate list of recipients is compiled which uses that list to send
out RCPT-TO command to the mail server followed by the DATA command
for the message that is stored in a separate file than the recipient
list. What are shown in the To, Cc, and From headers in the received
message are not necessarily what were used when the e-mail was sent.
E-mail was originally built on a trust model and why spammers can
abuse it.

You can't rely on the To, Cc, or From headers in a received message to
absolutely identify who were the sender and recipient(s). You'll need
to verify those against the Received headers that each mail server
prepends to the header section in the message (but beware of bogus
Received headers that spammers will insert to mislead those not
familiar with tracing through those headers).

Received: from aamtain09-winn.ispmail.ntl.com ([81.103.221.35])
by mtain05-winn.ispmail.ntl.com ...
Received: from cyc ([59.152.179.108])
by aamtain09-winn.ispmail.ntl.com ...

Your receiving mail server prepended the topmost Received header.
Every host knows the IP address of the host that connects to it, so
your mail server said 81.103.221.35 connected to it. The friendly
name of aamtain09... is what the sender claimed was their IP or
hostname. If the sender is lying, as does a spammer, then this
hostname is suspect. You just go by the IP address. A reverse DNS
lookup on 81.103.221.35 returns
host81-103-221-35.not-set-yet.ntli.net. Well, that's a customer's IP
address at NTL which is similar but not the same as the IP name the
sender said they were. A DNS lookup on aamtain09-winn.ispmail.ntl.com
returns no A pointer record (i.e., it is unknown). Sometimes more
than one IP name can equate to the same IP address. Not in this case.

Using dnsstuff.com, I did a lookup for MX records (mail exchange
hosts) for ntl.com, the domain claimed by the sender in the top
Received header (the one that your receiving mail host prepended to
the message). None of those listed by
http://www.dnsstuff.com/tools/lookup...com%20&type=MX
matches up with the claimed mail host; however, it is possible NTL was
using a standby mail host at the time or this is the name of an
internal mail host (used in hopping the mail through their domain) and
NTL doesn't show their boundary mail host. If it is an internal
routing host then that's why DNS lookup on
aamtain09-winn.ispmail.ntl.com fails to return an IP address (i.e., no
A record gets returned from a DNS query). If you are an NTL customer,
send yourself a test mail and see what mail host that NTL identifies
for themself. When I do a dig on aamtain09-winn.ispmail.ntl.com using
SamSpade, it gets as far as ispmail.ntl.com and that hostname does
have an nslookup that works to return an IP address; however, querying
for an MX record on ispmail.ntl.com shows their registered boundary
mail host of smtpin.ispmail.ntl.com so I still can't back to seeing if
aamtain09-winn.ispmail.ntl.com is an authorized mail host at NTL.

The "by" host in the 2nd Received header matches the "from" host in
the first Received header, so the chaining appears intact. If you
presume host81-103-221-35.not-set-yet.ntli.net is the same as
aamtain09-winn.ispmail.ntl.com then that mail server said the sender
was 59.152.179.108. A reverse DNS lookup on that IP address also has
no matching IP name for that host. An IP-whois lookup on
59.152.179.108 shows it is allocated to a Korean registrant
(http://www.dnsstuff.com/tools/whois....9.152.179.108). Have a
lots of friends, coworkers, or customers in Korea sending you e-mails?

I'm not sure that I'd trust the "from" in the first Received header.
The 2nd Received header does looked chained okay and points to a
Korean registrant for the sender's IP address.

So, does your "friend" own a [lease to a] domain? The Subject header
makes it appear that someone is trying to sell him a domain name,
perhaps luring him into some cheaper deal to reregister your friend's
domain because it is a month, or so, away from expiring. When you
provide an e-mail address during registration of a domain, it only
needs to be a valid e-mail address to the registrar, not to anyone
else. So use a special e-mail address which whitelists e-mails from
the registrar and immediately deletes e-mails from anyone else. Some
registrars let the registrant hide their personal info; however, ICANN
requires such providers to release the personal contact info upon
demand, usually as part of legal action or sometimes just a legal
threat (or by convinving the hiding registrar about the ICANN
guidelines which could result in losing ICANN accredidation as a
registrar if the registrar doesn't follow them).

Does your friend actually send a lot of e-mails to himself? If not,
use a rule to move/delete any e-mails through an account which have
his e-mail address for that account in the From header. I rarely send
myself e-mails but do sometimes when I test changes. I create a
"global passcode" rule where I look for a unique and unusual string in
the Subject header that no one is likely to include. If the Subject
header has that passcode string then their e-mail stays in my Inbox;
if not, then other anti-spam rules are exercised against that message,
like the "Sent from me" auto-delete rule. To send myself test
e-mails, I include the passcode string in the Subject header.
Everyone else has their e-mails processed through the rest of the
anti-spam rules. For a passcode, pick a string that is not likely to
show up in the header, like "!!BRHL.829#". Be as imaginative as you
like. You can even give out this passcode if you want to ensure you
want to receive someone's e-mail. If I have a recruiter wanting to
show me the description of a contract, I give them the passcode to
ensure their e-mail skips all anti-spam processing. If the passcode
ever gets abused because someone gave it out to abusers (or you did
accidentally or unknowingly) then just simply change the passcode in
the rule to look for the new passcode. Easy to change, give it out
when absolutely needed for one-time critical e-mails, use it yourself
for test e-mails.

Wow! going to take a lot of (re)reading to get my head round this
information. Thanks for a very detailed reply.

To answer your questions.

1) lots of friends, coworkers, or customers in Korea sending you e-mails?
Answer is No
2) does your "friend" own a [lease to a] domain? Answer is No
3) Does your friend actually send a lot of e-mails to himself? he does
send test messages to himself

Once again, Thanks for your reply

"Vanguard" wrote:

"barrowhill" wrote in message
...
A friend of mine has started to receive mail from himself ! i.e the
to and
from fields contain his details. This sound like spoofing to me.
He would
like to be able to stop these but my knowledge is limited. I've
looked and
the properties of received mail and copied below - friends email
details
changed to

Return-Path:
Received: from aamtain09-winn.ispmail.ntl.com ([81.103.221.35])
by mtain05-winn.ispmail.ntl.com with ESMTP
id

for ; Wed, 29 Aug 2007 12:05:25 +0100
Received: from cyc ([59.152.179.108]) by
aamtain09-winn.ispmail.ntl.com
with SMTP
id
20070829110525.UJUH6763.aamtain09-winn.ispmail.ntl.com@cyc
for ; Wed, 29 Aug 2007 12:05:25 +0100
Content-Return: allowed
X-Mailer: CME-V6.5.4.3; MSN
Return-Path:
Received: (qmail 13813 by uid 398); Wed, 29 Aug 2007 08:05:31 +0900
Message-Id: 20070829170531.13815.qmail@cyc
To:
Subject: - Sale
From:
MIME-Version: 1.0
Importance: High
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Date: Wed, 29 Aug 2007 12:05:25 +0100

Can anyone help and advise what could/should be done next. ?????

To To, Cc, and Bcc fields displaying in your e-mail client are just
that: fields. They are NOT the headers used in delivering e-mails.
The e-mail client compiles an aggregate of recipients from the To, Cc,
and Bcc fields and sends a RCPT-TO command for each one to the mail
server. That is followed by one DATA command to send the e-mail
message (which includes the header and body sections that are the
*data* composed by the user and his e-mail client). Fact is, no one
needs to be specified in the To, Cc, and Bcc fields in an e-mail
client to have the e-mail delivered. For bulk mailing programs, a
separate list of recipients is compiled which uses that list to send
out RCPT-TO command to the mail server followed by the DATA command
for the message that is stored in a separate file than the recipient
list. What are shown in the To, Cc, and From headers in the received
message are not necessarily what were used when the e-mail was sent.
E-mail was originally built on a trust model and why spammers can
abuse it.

You can't rely on the To, Cc, or From headers in a received message to
absolutely identify who were the sender and recipient(s). You'll need
to verify those against the Received headers that each mail server
prepends to the header section in the message (but beware of bogus
Received headers that spammers will insert to mislead those not
familiar with tracing through those headers).

Received: from aamtain09-winn.ispmail.ntl.com ([81.103.221.35])
by mtain05-winn.ispmail.ntl.com ...
Received: from cyc ([59.152.179.108])
by aamtain09-winn.ispmail.ntl.com ...

Your receiving mail server prepended the topmost Received header.
Every host knows the IP address of the host that connects to it, so
your mail server said 81.103.221.35 connected to it. The friendly
name of aamtain09... is what the sender claimed was their IP or
hostname. If the sender is lying, as does a spammer, then this
hostname is suspect. You just go by the IP address. A reverse DNS
lookup on 81.103.221.35 returns
host81-103-221-35.not-set-yet.ntli.net. Well, that's a customer's IP
address at NTL which is similar but not the same as the IP name the
sender said they were. A DNS lookup on aamtain09-winn.ispmail.ntl.com
returns no A pointer record (i.e., it is unknown). Sometimes more
than one IP name can equate to the same IP address. Not in this case.

Using dnsstuff.com, I did a lookup for MX records (mail exchange
hosts) for ntl.com, the domain claimed by the sender in the top
Received header (the one that your receiving mail host prepended to
the message). None of those listed by
http://www.dnsstuff.com/tools/lookup...com%20&type=MX
matches up with the claimed mail host; however, it is possible NTL was
using a standby mail host at the time or this is the name of an
internal mail host (used in hopping the mail through their domain) and
NTL doesn't show their boundary mail host. If it is an internal
routing host then that's why DNS lookup on
aamtain09-winn.ispmail.ntl.com fails to return an IP address (i.e., no
A record gets returned from a DNS query). If you are an NTL customer,
send yourself a test mail and see what mail host that NTL identifies
for themself. When I do a dig on aamtain09-winn.ispmail.ntl.com using
SamSpade, it gets as far as ispmail.ntl.com and that hostname does
have an nslookup that works to return an IP address; however, querying
for an MX record on ispmail.ntl.com shows their registered boundary
mail host of smtpin.ispmail.ntl.com so I still can't back to seeing if
aamtain09-winn.ispmail.ntl.com is an authorized mail host at NTL.

The "by" host in the 2nd Received header matches the "from" host in
the first Received header, so the chaining appears intact. If you
presume host81-103-221-35.not-set-yet.ntli.net is the same as
aamtain09-winn.ispmail.ntl.com then that mail server said the sender
was 59.152.179.108. A reverse DNS lookup on that IP address also has
no matching IP name for that host. An IP-whois lookup on
59.152.179.108 shows it is allocated to a Korean registrant
(http://www.dnsstuff.com/tools/whois....9.152.179.108). Have a
lots of friends, coworkers, or customers in Korea sending you e-mails?

I'm not sure that I'd trust the "from" in the first Received header.
The 2nd Received header does looked chained okay and points to a
Korean registrant for the sender's IP address.

So, does your "friend" own a [lease to a] domain? The Subject header
makes it appear that someone is trying to sell him a domain name,
perhaps luring him into some cheaper deal to reregister your friend's
domain because it is a month, or so, away from expiring. When you
provide an e-mail address during registration of a domain, it only
needs to be a valid e-mail address to the registrar, not to anyone
else. So use a special e-mail address which whitelists e-mails from
the registrar and immediately deletes e-mails from anyone else. Some
registrars let the registrant hide their personal info; however, ICANN
requires such providers to release the personal contact info upon
demand, usually as part of legal action or sometimes just a legal
threat (or by convinving the hiding registrar about the ICANN
guidelines which could result in losing ICANN accredidation as a
registrar if the registrar doesn't follow them).

Does your friend actually send a lot of e-mails to himself? If not,
use a rule to move/delete any e-mails through an account which have
his e-mail address for that account in the From header. I rarely send
myself e-mails but do sometimes when I test changes. I create a
"global passcode" rule where I look for a unique and unusual string in
the Subject header that no one is likely to include. If the Subject
header has that passcode string then their e-mail stays in my Inbox;
if not, then other anti-spam rules are exercised against that message,
like the "Sent from me" auto-delete rule. To send myself test
e-mails, I include the passcode string in the Subject header.
Everyone else has their e-mails processed through the rest of the
anti-spam rules. For a passcode, pick a string that is not likely to
show up in the header, like "!!BRHL.829#". Be as imaginative as you
like. You can even give out this passcode if you want to ensure you
want to receive someone's e-mail. If I have a recruiter wanting to
show me the description of a contract, I give them the passcode to
ensure their e-mail skips all anti-spam processing. If the passcode
ever gets abused because someone gave it out to abusers (or you did
accidentally or unknowingly) then just simply change the passcode in
the rule to look for the new passcode. Easy to change, give it out
when absolutely needed for one-time critical e-mails, use it yourself
for test e-mails.