Spam with "port=" and "helo=" in header Received line
Spam Guy
address has a header construction as in this example:
=================
Return-Path: <iffy...@research.telcordia.com>
Received:
from 173.193.223.134-static.reverse.softlayer.com ([81.216.156.117])
by (my server) with ESMTP id AAA214 for <sales@my-domain>;
Wed, 22 Sep 2010 18:47:12 -0400
Return-path: <sales@my-domain>
Received:
from [173.193.223.134] (port=7650 helo=xaca6cmw2vvqk9) by
mx4.telcordia.com with asmtp id 0639EF-0007B6-73 for
<sales@my-domain>;
Thu, 23 Sep 2010 00:45:07+0100
Message-ID:
<AE15A78C1B7C48EDB1080BC85E0BF4FE@xaca6cmw2vvqk9>
=================
Basically, you have:
Return path:
Received:
Return path:
Received: (...) (port= helo=)
Having a second Return-path line is unusual. In these examples, this
second Return-path is always the same as the destination address, and
it's sandwitched between two Received lines, where the second received
line always contains "port=" and "helo=".
I've received 74 spams with this particular header construction which
started abruptly on May 28.
The first Received line in this example is interesting for another
reason:
=========
Received:
from 173.193.223.134-static.reverse.softlayer.com ([81.216.156.117])
=========
I believe that the sending machine identified itself during the HELO as
"173.193.223.134-static.reverse.softlayer.com", and the
"([81.216.156.117])" part of that line was crafted by my mail server to
indicate the actual IP address of the connecting machine.
It's been my experience that when the HELO string actually looks like a
real rDNS or FQDN, it usually turns out to be the correct rDNS of the
connecting IP address.
In this case, the rDNS of 173.193.223.134-static.reverse.softlayer.com
is (obviously or not) 173.193.223.134. Which happens to be the IP
address found in the second Received line.
So I'm not sure what's happening here (intentional or otherwise) that's
leading to this particular header construction.
D. Stussy
news:4C9AD2EE...@Guy.com...
Careful: Unusual, but permitted within the syntax of RFC 5321. Some
legitimate servers are now adding the port number into the trace header.
> I've received 74 spams with this particular header construction which
> started abruptly on May 28.
>
> The first Received line in this example is interesting for another
> reason:
>
> =========
> Received:
> from 173.193.223.134-static.reverse.softlayer.com ([81.216.156.117])
> =========
>
> I believe that the sending machine identified itself during the HELO as
> "173.193.223.134-static.reverse.softlayer.com", and the
> "([81.216.156.117])" part of that line was crafted by my mail server to
> indicate the actual IP address of the connecting machine.
That is the correct general interpretation of the information.
> It's been my experience that when the HELO string actually looks like a
> real rDNS or FQDN, it usually turns out to be the correct rDNS of the
> connecting IP address.
>
> In this case, the rDNS of 173.193.223.134-static.reverse.softlayer.com
> is (obviously or not) 173.193.223.134. Which happens to be the IP
> address found in the second Received line.
>
> So I'm not sure what's happening here (intentional or otherwise) that's
> leading to this particular header construction.
My suggestion to you is to do nothing as far as constructing any specific
rules to deal with this. I suggest that you are better off letting a
bayesian filter figure out which constructs are spammy and which are not.
Thor Kottelin
news:4C9AD2EE...@Guy.com...
> address has a header construction as in this example:
>
> =================
> Return-Path: <iffy...@research.telcordia.com>
>
> Received:
> from 173.193.223.134-static.reverse.softlayer.com ([81.216.156.117])
> by (my server) with ESMTP id AAA214 for <sales@my-domain>;
> Wed, 22 Sep 2010 18:47:12 -0400
>
> Return-path: <sales@my-domain>
>
> Received:
> from [173.193.223.134] (port=7650 helo=xaca6cmw2vvqk9) by
> mx4.telcordia.com with asmtp id 0639EF-0007B6-73 for
> <sales@my-domain>;
> Thu, 23 Sep 2010 00:45:07+0100
>
> Message-ID:
> <AE15A78C1B7C48EDB1080BC85E0BF4FE@xaca6cmw2vvqk9>
> =================
> Having a second Return-path line is unusual.
The (temporally) first "Return-Path" line should not have been written, as
final delivery did not occur at that time. Your server would have been
within its rights to remove it. My initial guess is that the line was
added by broken spamware.
The line written by your server indicates, of course, the parameter of the
MAIL command issued by the SMTP client contacting your server.
> The first Received line in this example is interesting for another
> reason:
> I believe that the sending machine identified itself during the HELO as
> "173.193.223.134-static.reverse.softlayer.com", and the
> "([81.216.156.117])" part of that line was crafted by my mail server to
> indicate the actual IP address of the connecting machine.
This often occurs with spam.
--
Thor Kottelin
Every computer on the net needs an up-to-date antivirus program and a
firewall. Both are available here: http://turvasana.com/antivirus/
Spam Guy
> > I believe that the sending machine identified itself during the
> > HELO as "173.193.223.134-static.reverse.softlayer.com"
>
> Presumably you actually *know* how your mailserver software
> constructs Received headers. You've been using it for over a
> decade. I'd normally expect to see something like
I don't believe I've ever seen these exact details explained in it's
documentation.
> Received: from <helo> (<rDNS hostname> [<real ip-address>]) by
> <SMTP-server-hostname> with <transport> for <envelope-recipient>
> <date>
I have not enabled the option to resolve <rDNS hosthame> so that is why
it does not appear in my headers, which means that the string that I see
as <helo> is most likely the actual HELO string used by the connecting
machine.
For most direct-to-MX spam that I get, that string is usually a 6 to 12
character string of random upper-case letters. Sometimes its a simple
word, like "server". In some rare cases, it's completely absent.
And as I've said before, in cases where <helo> actually looks like the
result of an rDNS lookup, then it basically does agree with the DNS
lookup of [<real ip-address>].
In this example, it does not agree. So I'm not sure why that helo used
in this case.
The reason why that issue is concerning me is because when I add <real
ip-address> to my server's black list, I look first at the <helo> just
to verify that it doesn't contain "gmail" or "yahoo" or "hotmail"
because I don't want to block those servers from sending me mail. So if
a spammer starts fabricating their <helo> such that it duplicates what
google or hotmail or yahoo uses, then I've got to resort to other ways
to identify mail from those servers so I don't block them.
I have not yet seen any spam where the <helo> was an attempt to
duplicate a large commercial mail server (such as gmail, hotmail or
yahoo).
> But only you know how your server does things - it's effectively
> a one-off. As a matter of fact, which address did the message
> arrive from?
In my headers, the first line is always "Return Path:".
The second line is always what I call the "first" Received: line, which
in this case was
=======
Received:
from 173.193.223.134-static.reverse.softlayer.com ([81.216.156.117])
by (my server) with ESMTP id AAA214 for <sales@my-domain>;
Wed, 22 Sep 2010 18:47:12 -0400
=======
According to that line, the message was received from ([ip-address]).
Anything that appears between "from" and "([" is (or seems to be)
generated or supplied by the connecting machine, which if I understand
this correctly can only be the <helo> used by the connecting machine.
> It's unlikely that 81.216.156.117 actually relayed spam to you
> from 173.193.223.134.
I agree that the authenticity of the second received line is always
suspect.
> I prefer to suppose the spam originated from spamware
> on 81.216.156.117 that used a bogus helo, and stuck
> in a bogus Received: line to match the bogus helo.
If the second received line was forged (and even if it wasn't) the spam
software took the IP address used on that line (173.193.223.134),
determined it's rDNS, and used that rDNS as the <helo> for the SMTP
connection to me. Why it did that, who knows. I don't think I've ever
seen that before.
Spam Guy
> My suggestion to you is to do nothing as far as constructing any
> specific rules to deal with this. I suggest that you are better
> off letting a bayesian filter figure out which constructs are
> spammy and which are not.
Well, since e-mail received by this account (sales@my-domain) is
automatically forwarded by my server to a gmail account where it is
configured to forward back to me on another account, this arrangement
utilizes Google's spam filtering mechanisms such that it simply won't be
forwarded back to me (and hence distributed to my local users) if google
determines that it's spam.
But if I were to impliment a local spam-filtering rule, it would be that
if "sales@my-domain" appeared on any Return-path line, then it would
automatically be considered as spam since that is not a valid out-going
mail address (we never send mail using that as the "from" or "reply-to"
address).