Arvid Ephraim Picciani wrote:
On Tuesday 13 May 2008 22:45:43 mouss wrote:
That said, one possibility is this: Some soho have an MSA on a dsl line.
a ratwared box inside (or a web service running on the MSA box) sends
mail to an invalid recipient. the MSA gets rejected and then sends you
an NDR. the MSA is borked enough to helo with the recipient domain, and
generates an incomplet NDR.
interesting. and broken enough to use my hostname as From, in the body, helo
and message id? double backscatter? kindof weird, but if that works it would
at least just be some coincidence rather then intention.
- message-id was most probably generated by your own MTA because remote
ratware didn't include one
- the domain part of the From: header may also have been added by your
MTA because remote system uses a non fqdn address.
so that leaves us with helo and "Reporting-MTA". considering that old
mozilla stuff used to use the recipient domain in its helo, it is no
surprise that many ratware does so. I would say the same for the
Reporting-MTA.
at least, this is the most "logical" explanation I can see. As you, I
don't think a spammer intentionally wanted to send you a mostly empty
NDR...
PS. The link you posted is no more valid... (I mean
http://rafb.net/p/q3eZwd93.html)
sorry. i replaced the hostname with example.com and will keep it permanently
here.
http://exys.org/stuff/fakebounce.txt
On Tuesday 13 May 2008 22:58:52 Matus UHLAR - fantomas wrote:
To summarize, the original message was a bounce, and it was a backscatter.
are you saying that the definition of "bounceback" is: everything that
contains the subject line "Undelivered mail",
no. it's any DSN sent to a forged sender. in general, sender is empty,
but this is not always true.
not sure if "bounceback" is better than "bounce out". because there is
no "back" here... so outscatter is probably a better name.
or are you claming that my
server actually does backscatter.
if pool-151-204-219-7.pskn.east.verizon.net is one of your machines,
then the problem is in your system. but this IP is in the US and your
server in .de, so this doesn't look probable...
If you read closely again you will see that the message body claims to be
generated from me:
"Reporting-MTA: dns; mx1.example.com"
and the from is forged:
From: [EMAIL PROTECTED] (Mail Delivery Subsystem)
as said above, this proves nothing as it may have been "fixed" by your
MTA. you can test this by sending a message with a non fqdn From:
address and see if your MTA will append your domain.
and the helo:
Received: from pool-151-204-219-7.pskn.east.verizon.net ([151.204.219.7]
helo=example.com)
the helo is obviously fake. now, something weired here:
$ host pool-151-204-219-7.pskn.east.verizon.net
Host pool-151-204-219-7.pskn.east.verizon.net not found: 3(NXDOMAIN)
so your exim is "logging" an unverified rDNS. (no, I won't debate
received header formats...).
it's not a bounceback. It's 100% fake.
you can't tell. as I said, it may be a bounce from ratware. you can't
argue in a fictitious world...
Not containing any extra content. The
entire purpose of the message is to look like backscatter.
I think it is backscatter. I have many of these without forgery (I mean
with the right helo and reporting-mta). so I am tempted to believe that
a silly developper wrote a bogus mailer and couldn't get a domain name
(oh, that's hard, isn't it?) so used the final recipient domain...
I really see no point of speculating who did the spammer want to spam, it
would change nothing.
oh i do, becouse of exactly my above point. people WILL start claming that
this is real backscatter and block or score the IP or hostname.
I don't know what you want to do with that IP. it gets blocked here:
$ host 151.204.219.7
7.219.204.151.in-addr.arpa domain name pointer
pool-151-204-219-7.pskn.east.verizon.net.
$ host pool-151-204-219-7.pskn.east.verizon.net
Host pool-151-204-219-7.pskn.east.verizon.net not found: 3(NXDOMAIN)
that's generic rDNS + doesn't resolve back.
gets a
450 4.7.1 Client host rejected: cannot find your hostname
here because of (postfix) reject_unknown_client applied in case of
generic rDNS.
but for this particular transaction, a forged helo gets rejected with no
mercy...
