Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Qmail>
  3. users
Fake Delivered-To in header
eperea at walkereng
Oct 31, 2012, 9:40 AM
Post #1 of 12 (5739 views)
Permalink
The last couple of days I have been getting double bounces from spammers
who include a fake Deliver-To line in their header. At first I was
worried about the bounce messages going to innocent persons, but the
double bounces are from the same domains as the embedded URLs in the
messages themselves, which I assume belong to the spammers.

Would it be a good idea to limit delivery attempts for bounce messages
to one only? If so, what would be the proper way to do it?

----- Forwarded message from MAILER-DAEMON@frisco.perea.net -----

Date: 31 Oct 2012 14:11:18 -0000
From: MAILER-DAEMON@frisco.perea.net
To: postmaster@frisco.perea.net
Subject: failure notice

Hi. This is the qmail-send program at frisco.perea.net.
I tried to deliver a bounce message to this address, but the bounce bounced!

<FoodPoisoningInjuryCenter@strapcounty.info>:
209.105.246.195 does not like recipient.
Remote host said: 450 4.1.1 <FoodPoisoningInjuryCenter@strapcounty.info>: Recipient address rejected: unverified address: unknown user: "foodpoisoninginjurycenter@strapcounty.info"
Giving up on 209.105.246.195.
I'm not going to try again; this message has been in the queue too long.

--- Below this line is the original bounce.

Return-Path: <>
Received: (qmail 3869 invoked for bounce); 31 Oct 2012 13:24:36 -0000
Date: 31 Oct 2012 13:24:36 -0000
From: MAILER-DAEMON@frisco.perea.net
To: FoodPoisoningInjuryCenter@strapcounty.info
Subject: failure notice

Hi. This is the qmail-send program at frisco.perea.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<emilio@perea.net>:
This message is looping: it already has my Delivered-To line. (#5.4.6)

--- Below this line is a copy of the message.

Return-Path: <FoodPoisoningInjuryCenter@strapcounty.info>
Received: (qmail 16954 invoked from network); 31 Oct 2012 13:24:36 -0000
Received: from hermes2.perea.net (HELO hermes.walkereng.com) (172.20.20.229)
by frisco.perea.net with SMTP; 31 Oct 2012 13:24:36 -0000
Received: (qmail 14897 invoked from network); 31 Oct 2012 13:24:36 -0000
Received: from strapcounty.info (HELO nordmodemnet.com) (176.223.177.2)
by hermes.walkereng.com with SMTP; 31 Oct 2012 13:24:36 -0000
Delivered-To: emilio@perea.net
Received: by 10.223.118.17 with SMTP id t17cs125410faq;
Wed, 31 Oct 2012 06:24:37 -0700
Received: by 10.216.220.142 with SMTP id o14mr2820421wep.61.1316443187605;
Wed, 31 Oct 2012 06:24:37 -0700
Return-Path: <FoodPoisoningInjuryCenter@strapcounty.info>
From: "FoodPoisoningInjuryCenter" <FoodPoisoningInjuryCenter@strapcounty.info>
Content-Type: multipart/alternative; boundary=Apple-Mail-3-544537804
Subject: Were you exposed to the Peanut Butter Salmonella Outbreak
Date: Wed, 31 Oct 2012 06:24:37 -0700
Message-Id: <62B5E3F4-5A93-E973-3171-AE5DFCF9A47A@strapcounty.info>
To: <emilio@perea.net>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - strapcounty.info
X-AntiAbuse: Original Domain - yahoo.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strapcounty.info


--Apple-Mail-3-544537804
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
...

--Apple-Mail-3-544537804
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=us-ascii

...
--Apple-Mail-3-544537804--

----- End forwarded message -----
Re: Fake Delivered-To in header [ In reply to ]
amb-sendok-1354421141.ekkidpbmggnboemggnbk at bradfo
Nov 1, 2012, 9:05 PM
Post #2 of 12 (5597 views)
Permalink
Thus said Emilio Perea on Wed, 31 Oct 2012 11:40:09 CDT:

> Would it be a good idea to limit delivery attempts for bounce messages
> to one only? If so, what would be the proper way to do it?

I don't believe this is possible without patching. You could limit the
junk that comes into the server, however, by using RBLs, spamd
(OpenBSD's) and other techniques.

This is the first time I've seen a spammer put a Delivered-to header in
a message.

Andy
Re: Fake Delivered-To in header [ In reply to ]
nicolai-qmail at chocolatine
Nov 1, 2012, 9:54 PM
Post #3 of 12 (5593 views)
Permalink
On Wed, Oct 31, 2012 at 11:40:09AM -0500, Emilio Perea wrote:

> At first I was worried about the bounce messages going to innocent
> persons, but the double bounces are from the same domains as the
> embedded URLs in the messages themselves, which I assume belong to the
> spammers.

For double bounces you can set /var/qmail/control/doublebounceto

> Would it be a good idea to limit delivery attempts for bounce messages
> to one only?

IMO it would be a good idea not to send bounce messages, in order to
eliminate backscatter spam. Instead, reject unwanted incoming messages
during the SMTP conversation or simply throw them away. There are a few
ways to stop sending bounce messages each with their pros and cons:

1. echo "#" > ~alias/.qmail-default

2. Use an "accepted receivers" type patch

3. Use the QMAILQUEUE patch, check the recipient, and reject with a 5xy
if the message is unwanted.

Here's a short and informative article on backscatter spam:

https://en.wikipedia.org/wiki/Backscatter_(email)

Nicolai
Re: Fake Delivered-To in header [ In reply to ]
eperea at walkereng
Nov 2, 2012, 7:30 PM
Post #4 of 12 (5593 views)
Permalink
On Thu, Nov 01, 2012 at 10:05:40PM -0600, Andy Bradford wrote:
> I don't believe this is possible without patching. You could limit the
> junk that comes into the server, however, by using RBLs, spamd
> (OpenBSD's) and other techniques.

I've been meaning to try spamd -- this may be a good time to start.

> This is the first time I've seen a spammer put a Delivered-to header in
> a message.

I don't really understand why they are doing that. I've got 72 double-
bounces so far which would have been delivered without the fake header.
Re: Fake Delivered-To in header [ In reply to ]
eperea at walkereng
Nov 2, 2012, 8:23 PM
Post #5 of 12 (5594 views)
Permalink
On Thu, Nov 01, 2012 at 11:54:23PM -0500, Nicolai wrote:
> On Wed, Oct 31, 2012 at 11:40:09AM -0500, Emilio Perea wrote:
> > At first I was worried about the bounce messages going to innocent
> > persons, but the double bounces are from the same domains as the
> > embedded URLs in the messages themselves, which I assume belong to the
> > spammers.
>
> For double bounces you can set /var/qmail/control/doublebounceto

I still have not got enough to be a real nuisance and I'd rather see
them if they occur.

> > Would it be a good idea to limit delivery attempts for bounce messages
> > to one only?
>
> IMO it would be a good idea not to send bounce messages, in order to
> eliminate backscatter spam. Instead, reject unwanted incoming messages
> during the SMTP conversation or simply throw them away. There are a few
> ways to stop sending bounce messages each with their pros and cons:

(At least so far) I'd rather keep the bounce messages to help in trouble
shooting. I do use the validrcptto patch which prevents most bounces by
rejecting all undeliverable messages at the SMTP level. The problem is
these weirdos that insert a fake header that makes qmail think the
messages are looping. These would not normally bounce since they are to
a valid recipient.

The sender address in all of these cases uses the same domain name as
the embedded URLs meant to deliver the actual payload of the spam. I
didn't check the MX records of all 72 domains (so far), but the first
dozen or so used the same records. All of the source addresses appear
to be in Bucharest and I think I have all of their networks blocked on
tcp.smtp, so I'm hoping this is taken care of.
Re: Fake Delivered-To in header [ In reply to ]
amb-sendok-1354506339.bcdphhnihdgemhcjimmo at bradfo
Nov 2, 2012, 8:45 PM
Post #6 of 12 (5587 views)
Permalink
Thus said Nicolai on Thu, 01 Nov 2012 23:54:23 CDT:

> IMO it would be a good idea not to send bounce messages, in order to
> eliminate backscatter spam. Instead, reject unwanted incoming messages
> during the SMTP conversation or simply throw them away. There are a
> few ways to stop sending bounce messages each with their pros and
> cons:

If I'm not mistaken, this won't help in this case. The email address was
delivered to a legitimate email address, but because it a fake
delivered-to header, the message bounced to the original sender. So,
while your suggestion is a good one, it is irrelevant to this particular
problem.

Andy
Re: Fake Delivered-To in header [ In reply to ]
amb-sendok-1354506740.mpfepcekdndiaklpeihc at bradfo
Nov 2, 2012, 8:52 PM
Post #7 of 12 (5588 views)
Permalink
Thus said Emilio Perea on Wed, 31 Oct 2012 11:40:09 CDT:

> Would it be a good idea to limit delivery attempts for bounce messages
> to one only? If so, what would be the proper way to do it?

I suppose the only proper way to do it would be to touch the
mess/xx/messnum with an old timestamp. This will limit the time that the
message is allowed to be in the queue and if you timestamp the file
older than your queuelifetime, then it will leave the queue on the next
delivery attempt.

See ``How do I rejuvenate a message?'' from:

http://cr.yp.to/qmail/faq/admin.html#rejuvenate

Using that technique you can cause a message to expire early by using a
timestamp in the past.

Andy
Re: Fake Delivered-To in header [ In reply to ]
kirk at icapsolutions
Nov 8, 2012, 9:12 AM
Post #8 of 12 (5561 views)
Permalink
I've been receiving the same exact messages for the past few weeks,
couldn't figure out how/why it was bouncing, so I traced it to these
specific IP's:

-A INPUT -s 31.0.0.0/8 -j DROP
-A INPUT -s 37.0.0.0/8 -j DROP
-A INPUT -s 89.0.0.0/8 -j DROP
-A INPUT -s 93.0.0.0/8 -j DROP
-A INPUT -s 176.0.0.0/8 -j DROP

I used the above in my iptables entry as I know these entire class A
subnets are coming from Romania, which of course i could care less
about. It stopped all the bounces and my servers are now humming along
quietly. Drastic I know, but problem solved.

Kirk


On 11/2/2012 8:52 PM, Andy Bradford wrote:
> Thus said Emilio Perea on Wed, 31 Oct 2012 11:40:09 CDT:
>
>> Would it be a good idea to limit delivery attempts for bounce messages
>> to one only? If so, what would be the proper way to do it?
> I suppose the only proper way to do it would be to touch the
> mess/xx/messnum with an old timestamp. This will limit the time that the
> message is allowed to be in the queue and if you timestamp the file
> older than your queuelifetime, then it will leave the queue on the next
> delivery attempt.
>
> See ``How do I rejuvenate a message?'' from:
>
> http://cr.yp.to/qmail/faq/admin.html#rejuvenate
>
> Using that technique you can cause a message to expire early by using a
> timestamp in the past.
>
> Andy
>
Re: Fake Delivered-To in header [ In reply to ]
nicolai-qmail at chocolatine
Nov 8, 2012, 11:28 AM
Post #9 of 12 (5560 views)
Permalink
On Thu, Nov 08, 2012 at 09:12:02AM -0800, Kirk Rogers wrote:
> I've been receiving the same exact messages for the past few weeks,
> couldn't figure out how/why it was bouncing, so I traced it to these
> specific IP's:
>
> -A INPUT -s 31.0.0.0/8 -j DROP
> -A INPUT -s 37.0.0.0/8 -j DROP
> -A INPUT -s 89.0.0.0/8 -j DROP
> -A INPUT -s 93.0.0.0/8 -j DROP
> -A INPUT -s 176.0.0.0/8 -j DROP
>
> I used the above in my iptables entry as I know these entire class A
> subnets are coming from Romania

Hi Kirk,

If Romania, with a population of 20 million, gets at least five /8
networks, then what does China get? India? USA? What's left? The
math doesn't justify these large blocks, and a quick look at the
networks you provided shows hosts all over Europe. France, Italy,
Germany, Finland, Netherlands... all over.

Nicolai
Re: Fake Delivered-To in header [ In reply to ]
marcus at synchromedia
Nov 8, 2012, 11:41 AM
Post #10 of 12 (5564 views)
Permalink
On 8 Nov 2012, at 20:28, Nicolai <nicolai-qmail@chocolatine.org> wrote:

> If Romania, with a population of 20 million, gets at least five /8
> networks, then what does China get? India? USA? What's left? The
> math doesn't justify these large blocks, and a quick look at the
> networks you provided shows hosts all over Europe. France, Italy,
> Germany, Finland, Netherlands... all over.

Quite right - I've got a bunch of servers in London with 93.* addresses.

Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK info@hand CRM solutions
marcus@synchromedia.co.uk | http://www.synchromedia.co.uk/
Re: Fake Delivered-To in header [ In reply to ]
kirk at icapsolutions
Nov 8, 2012, 1:36 PM
Post #11 of 12 (5564 views)
Permalink
My solution, like I said, was drastic, and definitely out of anger and
frustration. All of the bogus mail was coming from Romania as I traced
the originating IP's. Here's an IP breakdown, based on my findings,
from the bogus mail I am seeing (which BTW just started a few weeks
ago). I'm not blocking all of these, this is just the Class A range
broken down and filtered by the country code for Romania, then I look
for ranges that match the bogus mail and added that to my iptables firewall:


[root@primary ~]# cat ips-ascii.txt | grep -s " 31." | grep RO
RO: 31.2.128.0 31.2.255.255
RO: 31.11.40.0 31.11.47.255
RO: 31.14.0.0 31.14.255.255 ====> this range was especially offensive,
about 1K bogus email per day
RO: 31.42.128.0 31.42.159.255
RO: 31.47.208.0 31.47.215.255
RO: 31.130.240.0 31.130.247.255
RO: 31.131.8.0 31.131.15.255
RO: 31.131.40.0 31.131.47.255
RO: 31.131.160.0 31.131.167.255
RO: 31.132.8.0 31.132.15.255
RO: 31.132.32.0 31.132.63.255
RO: 31.132.80.0 31.132.95.255
RO: 31.132.192.0 31.132.199.255
RO: 31.133.24.0 31.133.31.255
RO: 31.133.192.0 31.133.199.255
RO: 31.135.0.0 31.135.7.255
RO: 31.173.0.0 31.173.255.255
RO: 31.215.0.0 31.215.255.255
RO: 31.220.128.0 31.220.135.255

[root@primary ~]# cat ips-ascii.txt | grep -s " 37." | grep RO
RO: 37.18.128.0 37.18.135.255
RO: 37.25.128.0 37.25.255.255
RO: 37.35.32.0 37.35.63.255
RO: 37.35.128.0 37.35.255.255
RO: 37.42.0.0 37.43.255.255
RO: 37.56.0.0 37.56.255.255
RO: 37.60.224.0 37.60.255.255
RO: 37.97.0.0 37.97.255.255
RO: 37.120.0.0 37.120.255.255
RO: 37.128.224.0 37.128.239.255
RO: 37.129.0.0 37.129.255.255
RO: 37.143.160.0 37.143.175.255
RO: 37.148.0.0 37.148.127.255
RO: 37.153.128.0 37.153.191.255
RO: 37.156.0.0 37.156.255.255
RO: 37.202.128.0 37.202.255.255
RO: 37.216.0.0 37.217.255.255
RO: 37.221.160.0 37.221.175.255
RO: 37.224.0.0 37.224.255.255
RO: 37.251.128.0 37.251.255.255

[root@primary ~]# cat ips-ascii.txt | grep -s " 89." | grep RO
RO: 89.18.0.0 89.18.31.255
RO: 89.21.96.0 89.21.127.255
RO: 89.22.49.0 89.22.49.255
RO: 89.32.0.0 89.47.255.255
RO: 89.114.0.0 89.115.255.255
RO: 89.120.0.0 89.123.255.255
RO: 89.136.0.0 89.137.255.255
RO: 89.149.0.0 89.149.63.255
RO: 89.165.128.0 89.165.255.255
RO: 89.200.240.0 89.200.247.255
RO: 89.238.192.0 89.238.255.255

[root@primary ~]# cat ips-ascii.txt | grep -s " 93." | grep RO
RO: 93.112.0.0 93.119.255.255
RO: 93.120.0.0 93.120.127.255
RO: 93.122.128.0 93.122.255.255
RO: 93.168.0.0 93.169.255.255
RO: 93.174.160.0 93.174.167.255
RO: 93.187.136.0 93.187.143.255
RO: 93.190.144.0 93.190.151.255

[root@primary ~]# cat ips-ascii.txt | grep -s " 176." | grep RO
RO: 176.96.48.0 176.96.63.255
RO: 176.96.88.0 176.96.95.255
RO: 176.96.176.0 176.96.183.255
RO: 176.97.144.0 176.97.151.255
RO: 176.97.224.0 176.97.239.255
RO: 176.98.32.0 176.98.47.255
RO: 176.98.56.0 176.98.63.255
RO: 176.99.16.0 176.99.31.255
RO: 176.99.32.0 176.99.47.255
RO: 176.100.48.0 176.100.55.255
RO: 176.102.120.0 176.102.127.255
RO: 176.103.120.0 176.103.127.255
RO: 176.103.240.0 176.103.247.255
RO: 176.105.224.0 176.105.255.255
RO: 176.107.64.0 176.107.71.255
RO: 176.107.72.0 176.107.79.255
RO: 176.108.224.0 176.108.231.255
RO: 176.110.106.0 176.110.107.255
RO: 176.110.112.0 176.110.115.255
RO: 176.110.216.0 176.110.223.255
RO: 176.111.0.0 176.111.7.255
RO: 176.111.160.0 176.111.167.255
RO: 176.111.168.0 176.111.175.255
RO: 176.112.80.0 176.112.87.255
RO: 176.113.40.0 176.113.47.255
RO: 176.113.64.0 176.113.95.255
RO: 176.113.96.0 176.113.103.255
RO: 176.113.104.0 176.113.111.255
RO: 176.113.176.0 176.113.183.255
RO: 176.113.184.0 176.113.191.255
RO: 176.114.56.0 176.114.63.255
RO: 176.114.96.0 176.114.111.255
RO: 176.115.224.0 176.115.239.255
RO: 176.116.32.0 176.116.47.255
RO: 176.116.128.0 176.116.135.255
RO: 176.116.224.0 176.116.239.255
RO: 176.118.32.0 176.118.39.255
RO: 176.118.56.0 176.118.63.255
RO: 176.118.80.0 176.118.87.255
RO: 176.118.88.0 176.118.95.255
RO: 176.118.160.0 176.118.191.255
RO: 176.118.192.0 176.118.199.255
RO: 176.118.200.0 176.118.207.255
RO: 176.121.24.0 176.121.31.255
RO: 176.121.32.0 176.121.47.255
RO: 176.121.96.0 176.121.111.255
RO: 176.123.32.0 176.123.47.255
RO: 176.124.72.0 176.124.79.255
RO: 176.124.80.0 176.124.95.255
RO: 176.124.104.0 176.124.111.255
RO: 176.124.172.0 176.124.175.255
RO: 176.124.176.0 176.124.183.255
RO: 176.125.0.0 176.125.31.255
RO: 176.126.168.0 176.126.175.255 => this range 176.126. was bad as
well, about 750 per day
RO: 176.126.176.0 176.126.191.255
RO: 176.126.192.0 176.126.255.255
RO: 176.222.64.0 176.222.127.255
RO: 176.223.0.0 176.223.255.255


It's not the best way to do it, but it's effective for me. I'm going to
assume at some point soon, the IP blocks that are being used will
eventually end up in the various blacklist's, then I can remove the
filter and rely on the RBL's and spamassassin (spamd).

Kirk


On 11/8/2012 11:41 AM, Marcus Bointon wrote:
> On 8 Nov 2012, at 20:28, Nicolai <nicolai-qmail@chocolatine.org> wrote:
>
>> If Romania, with a population of 20 million, gets at least five /8
>> networks, then what does China get? India? USA? What's left? The
>> math doesn't justify these large blocks, and a quick look at the
>> networks you provided shows hosts all over Europe. France, Italy,
>> Germany, Finland, Netherlands... all over.
> Quite right - I've got a bunch of servers in London with 93.* addresses.
>
> Marcus
Re: Fake Delivered-To in header [ In reply to ]
eperea at walkereng
Nov 8, 2012, 2:44 PM
Post #12 of 12 (5559 views)
Permalink
On Thu, Nov 08, 2012 at 01:36:04PM -0800, Kirk Rogers wrote:
> My solution, like I said, was drastic, and definitely out of anger
> and frustration. All of the bogus mail was coming from Romania as I
> traced the originating IP's. Here's an IP breakdown, based on my
> findings, from the bogus mail I am seeing (which BTW just started a
> few weeks ago). I'm not blocking all of these, this is just the
> Class A range broken down and filtered by the country code for
> Romania, then I look for ranges that match the bogus mail and added
> that to my iptables firewall:

FWIW, these are the ranges from which I've received these nuisances:

31.14.
37.153.128-191.
37.156.
89.32-47.
93.112-119.
176.126.128-255.
176.223.

These are the whole ranges that include the relevant spam. They could
be narrowed considerably. E.g. all the 93.112-119. junk I've got come
from 93.115, so that's the range I blocked.

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal