[SpamCop-List] Re: Fake NDR contains false headers in "bounced" msg
John E. Malmberg
wb8tyw at qsl.network
Sun Aug 15 21:57:07 EDT 2004
Don Wannit wrote:
> John E. Malmberg wrote:
> I see that IP 188.8.131.52 (the supposed recipient of the spam
> being bounced) is listed in dynablock.njabl.org as a dynamic address.
> Our SMTP server would have rejected it. Note that the Received: headers
> above that one all show *.brainstorminternet.net with an IPS of
> 127.0.0.1 -- either starfish.brainstorminternet.net is misconfigured
> w.r.t. proper Received headers, or the payload is a set of forged
What it looks like is that 184.108.40.206 sent a spam or a virus to a
user and instead of it being rejected with SMTP codes, something on that
end generated an abusive bounce to the forged address.
The 127.0.0.1 look like internal hand offs between the mail server and a
content filter, not a misconfiguration.
> Full un-munged headers have been posted in a separate post.
> I have to say I'd readily believe that starfish.brainstorminternet.net
> is a compromised machine, and I would not believe that a powered-down
> machine can send any email. :-)
> Any other candidates, based on the full headers?
It looks to me that 220.127.116.11 is the compromised machine, and that
either starfish.brainstorminternet.net generated an abusive bounce, or
some user of that mail server is using the bogus bounce function of
their spam filter.
Apparently starfish.brainstorminternet.net does not understand how
DNSbls work, or why they should only be using SMTP reject codes for
It looks like a real NDR.
This looks exactly like the forgeries that were being discussed in the
web thingy a few months ago.
The same spammer was also registering I.P. space with the contact
information copied from other companies and putting servers on them. I
think they stopped that, as the company they picked on reacted very fast
to remove the allocation, and make the I.P. address not routable. It
took a few days for the spammer to figure that out.
For the headers of the bounced message to be correct, your mail server
would have needed to be configured to be deliberately relaying through
the dynamic address 18.104.22.168.
The date stamps can not be trusted as servers can have incorrectly set
clocks unless they are operated by the voluntary clock police.
This also appears to be the same spammer discussed in the thread "Still
not parsing correctly"
Reference the following Spamhuas cases, which all seemed to be linked now:
SBL18272, SBL17431, SBL16745, SBL18652, SBL17407, SBL16739, SBL18468
wb8tyw at qsl.network
Personal Opinion Only
More information about the SpamCop-List