Alright, this is the first time I have seen the following
Received from unknown (HELO ppp-71-133-221-247.dsl.irvnca.pacbell.net) (xxx@xxxx.com@71.123.121.247 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP;
I am interested in what exaxtly the double @ signs are in the received by line. On first glance, it looked like user@host1@host2 ip. Can anyone give me a short run down on what would cause this? Is this the results of e-mail forwarding, or some type of login creditials for some type of dial in?
Thanks for your help!
rmac
BTW does anyone have a good forum dedicated to header analysis? Thanks!
Full header below, IP information has been modified.
From xxxxx <xxx.xxx.net>
Reply-To xxxx <xxx@xxx.net>
To xxx <xxxxxxx@xxxx.com>
Subject xxxx
Date Fri, 16 Dec 2005 095031 +0300
MIME-Version 1.0
Received from smtp101.biz.mail.mud.yahoo.com ([68.140.210.236]) by bay0-mc3-f7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Dec 2005 122837 -0800
Received (qmail 59872 invoked from network); 16 Dec 2005 202836 -0000
Received from unknown (HELO ppp-71-133-221-247.dsl.irvnca.pacbell.net) (xxx@xxxx.com@71.123.121.247 with plain) by smtp101.biz.mail.mud.yahoo.com with SMTP; 16 Dec 2005 202823 -0000
According to the Standard for the Format of ARPA Internet Text Messages, RFC 822, http//
RFC #733's use of multiple at-signs ("@") was intended as a general syntax for indicating routing and/or hierarchical addressing. The current standard separates these specifications and only one at-sign is permitted.
While this is not supposed to be allowed, it is possible that no everybody conforms to the standards, and allows it to slip through.
I've seen this before and believe that is a used as part of a phishing attack. You get addresses like customerservice@paypal.com@phishingattack.xxx. I believe that the various servers may parse from right to left (looking for the last @). The phishers are hoping that the email client only shows the start of the address (due to limited screen real-estate).
This appears in the first Received header which may not be forged by the sender to conceal the origin of that emails.
Thi is a known technique used by spammers. traversing the Received header up the tree should gives you the right picture of the emails origin.
regards
youcef
This appears in the first Received header which may not be forged by the sender to conceal the origin of that emails.
sorry for the typo above. I meant it may be forged by the sender. The received headers should be read in reverse order to get the true picutre of how the SMTP hosts were traversed.