Possible to remove peter at gizmoman.net from users list Was: The "peter at gizmoman.net" dilemma
David Hart
ubuntu at tonix.org
Fri Jan 5 10:06:14 UTC 2007
On Thu 2007-01-04 21:16:15 -0500, Scott Kitterman wrote:
> On Thursday 04 January 2007 21:08, David Hart wrote:
> >
> > So the message is actually coming from the IP address of gizmoman.net.
> > That doesn't mean that the owner of gizoman.net is responsible for the
> > spam - many domains could be pointing at 202.87.14.34 - but _someone_
> > who is able to send smtp from that IP address _is_ responsible.
>
> Which says nothing about if it's forged or not. There is no requirement for
> mail to be sent from the same IP address as their web server.
[...]
If you look further down this message you'll see that www.gizoman.net is
a CNAME for vhost1.conxion.com.au which has a different IP address to
gizoman.net. But web servers have nothing to do with what I'm talking
about - I'm talking about smtp.
If you think that what I said in my previous post says nothing about
whether the messages were forged or not then I think you didn't
understand what I wrote and I'll try to make things clearer.
People on this list have been asking to have peter at gizmoman.net
removed from this list because they think he's got a misconfigured
autoresponder. I believe the messages are forged and most probably
coming from someone else using the IP address that gizmoman.net resolves
to. Here are the relevant domains and IP addresses again with the
addition of the mx for gizmoman.net and the IP for www.gizmoman.net.
# david at mutt:~$ dig +short beachbum-server.beach-bum-solutions.com
# 64.15.205.242
# david at mutt:~$ dig +short gizmoman.net
# 202.87.14.34
# david at mutt:~$ dig +short www.gizmoman.net
# vhost1.conxion.com.au.
# 203.26.135.125
# david at mutt:~$ dig +short gizmoman.net mx
# 10 mx1.conxion.com.au.
To demonstrate that mx1.conxion.com.au does in fact handle
the mail for peter at gizmoman.net and to explain better the
headers from my mail server, I'll telnet to it from my server
which has two addresses; jynn.tonix.org[82.69.92.65] (reverse
lookup 82-69-92-65.dsl.in-addr.zen.co.uk) on the outside and
mutt.jynn.tonix.org[192.168.98.25] on the inside of my home network.
# david at mutt:~$ telnet mx1.conxion.com.au 25
# Trying 203.26.135.98...
# Connected to mx1.conxion.com.au.
# Escape character is '^]'.
# 220 mx1.conxion.com.au ESMTP Sendmail 8.13.1/8.13.1; Fri, 5 Jan 2007
# 14:54:48 +1100. By connecting to this server, you agree to be open relay
# tested.
# HELO jynn.tonix.org
# 250 mx1.conxion.com.au Hello 82-69-92-65.dsl.in-addr.zen.co.uk
# [82.69.92.65], pleased to meet you
# MAIL FROM:<david at jynn.tonix.org>
# 250 2.1.0 <david at jynn.tonix.org>... Sender ok
# RCPT TO:<peter at gizmoman.net>
# 250 2.1.5 <peter at gizmoman.net>... Recipient ok
# DATA
# 354 Enter mail, end with "." on a line by itself
# Subject: a test
# From: David Hart <david at tonix.org>
# To: Peter <peter at gizmoman.net>
#
# Hello, this is a test message
# ^]
# telnet> quit
# Connection closed.
In the above exchange, the first message from mx1.conxion.com.au is the
220 where it identifies itself and kindly says I must agree to be open
relay tested :) I reply with a HELO to identify myself.
mx1.conxion.com.au replies with a 250 to tell me to go ahead.
I send a MAIL FROM: and my return address, the reply is 250 Sender
ok.
I send a RCPT TO:<peter at gizmoman.net>, the reply is 250 Recipient ok.
At this point I have not yet sent any headers, only the HELO and the
envelope sender and recipient, but, from the responses from the remote
server, I can be reasonably confident that the message will ultimately
be accepted.
MTAs (such as Postfix or Exim) generally don't pay any attention to
anything other than the envelope sender and recipient when deciding
where to route messages (the forward address given by the RCPT TO: and
the return address given by the MAIL FROM:). The receiving MTA now has
the information it needs to route the message and any bounces that may
arise.
Now it's time to send the headers.
I send DATA to say I want to send the message and the other end replies
with 354 ...
I send a Subject:, From: and To: header followed by a blank line and my
messsage. Because I'm only testing and I don't actually want to send a
message I send the escape character ^] which returns me to the telnet
prompt where a quit closes the connection to the remote server.
Typing a single "." (a single period or full stop on a line by itself)
would've sent the message and the remote server would reply with a 250
and the ID of the queued message (if everything went ok).
Now, seeing as I've come this far I might as well quote the full headers
from one of the "bounce" messages that I received:
# From MAILER-DAEMON Thu Jan 4 07:29:17 2007
# Return-Path: <>
# X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mutt.jynn.tonix.org
# X-Spam-Level:
# X-Spam-Status: No, score=-3.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00
# autolearn=ham version=3.1.0
# X-Original-To: ubuntu at tonix.org
# Delivered-To: david+ubuntu at jynn.tonix.org
# Received: from beachbum-server.beach-bum-solutions.com (unknown [202.87.14.34])
# by mutt.jynn.tonix.org (Postfix) with ESMTP id DBD906E89
# for <ubuntu at tonix.org>; Thu, 4 Jan 2007 07:29:08 +0000 (GMT)
# Received: from mail pickup service by beachbum-server.beach-bum-solutions.com
# +with Microsoft SMTPSVC;
# Thu, 4 Jan 2007 18:28:58 +1100
# Thread-Topic: Undeliverable: Re: after command line install
# thread-index: Accv0f+IpBo4PJM2TgeJarYeSDgKng==
# From: System Administrator <administrator at beach-bum-solutions.com>
# Sender: System Administrator <postmaster at beach-bum-solutions.com>
# To: ubuntu at tonix.org
# Subject: Undeliverable: Re: after command line install
# MIME-Version: 1.0
# Content-Type: multipart/report;
# report-type=delivery-status;
# boundary="----=_NextPart_000_0863_01C7302E.33001220"
# Content-Class: urn:content-classes:dsn
# Importance: normal
# Priority: normal
# X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
# Message-ID:
# +<BEACHBUM-SERVERnD870000003f at beachbum-server.beach-bum-solutions.com>
# X-OriginalArrivalTime: 04 Jan 2007 07:28:58.0921 (UTC)
# +FILETIME=[FFC66190:01C72FD1]
# Date: 4 Jan 2007 18:28:58 +1100
Working from the bottom, everything from the Date: header up to and
including the first Received: header is what was received by my MTA from
the sending MTA. My MTA simply copied them. They should not be
trusted without further knowledge about the sending MTA.
Everything from the second Received: header up to the top From was
written by my MTA (and SpamAssassin running on the same box) and the
information is trustworthy. The machine is under my control alone. It's
here under my desk and I'm typing this email now, sitting at its console.
In the Received: header that my MTA wrote is says 'from
beachbum-server.beach-bum-solutions.com'. That, is what the sending MTA
said in the initial HELO to my machine. It doesn't mean that that is the
name of the machine that sent the message but it _is_ what my machine
received in the HELO.
Next, in the same header, it says in parenthesis 'unknown'. That
means that when my machine did a reverse dns lookup on the sending MTA's
IP address it didn't get a domain name.
Following that, still in the same Received: header, is the IP address of
the sending MTA. That information is _very_ reliable as it's part of
the underlying TCP connection between the sending MTA and my MTA.
Still in the same Received: header is the FQDN of my MTA, the name of
the MTA (Postfix), the protocol variant (ESMTP) and the ID of of the
message received in my MTA's queue which my MTA will have reported back
to the sending MTA.
#####################################################################
If you check the relevant RFC for the HELO command you'll find it says
something along the lines that the domain name given should resolve to the
IP of the sending MTA but, that the receiving MTA should still accept
the message even if it doesn't. (Anyone who wants to check this for
themselves knows where google.com is :)
The sending MTA's HELO was beachbum-server.beach-bum-solutions.com which
resolves to 64.15.205.242. The sending MTA's IP was 202.87.14.34. This
doesn't, by itself, _prove_ it's a forgery but it's a strong indicator.
The mx for the address peter at gizmoman.net is mx1.conxion.com.au. There
is no good reason for any MTA to try to send mail for peter at gizmoman.net
via beachbum-server.beach-bum-solutions.com. This is another strong
indicator that the messages are forged.
Look at the From: header administrator at beach-bum-solutions.com. To
check whether we can send a message to it:
# david at mutt:~$ dig +short beach-bum-solutions.com
# 64.15.205.242
# david at mutt:~$ dig +short beach-bum-solutions.com mx
# david at mutt:~$
There's no mx for the domain so the only option left is to send to the
IP address of the domain.
# david at mutt:~$ tcptraceroute beach-bum-solutions.com 25
# Selected device eth1, address 82.69.92.65, port 46627 for outgoing packets
# Tracing the path to beach-bum-solutions.com (64.15.205.242) on TCP port
# 25 (smtp), 30 hops max
# 1 gauthier-dsl1.hq.zen.net.uk (62.3.82.17) 24.031 ms 24.258 ms 22.896 ms
# [...]
# [...]
# 21 64.15.205.242 [closed] 185.757 ms 185.295 ms 184.515 ms
There isn't even an MTA listening at the end. This all looks _very_
suspicious.
Now consider that nobody is likely to accidentally send out a vacation
message that looks at first glance like a bounce message.
Does anyone who's read this far still think those "bounce" messages are
genuine?
This still leaves the question as to why anyone would deliberately forge
these messages. I'm not a mind reader but a couple of possible reasons
spring to mind.
There hasn't been an MTA listening at beach-bum-solutions.com since I
first checked about 24 hours ago but there may have been before that.
The perpetrators intention may have been, if not to DOS the domain, to
severely inconvenience it. (Who knows how many lists subscribers these
"bounces" are going to.)
The perpetrator may simply be a kiddie who gets a kick out of reading us
discussing them - who knows?
I'm interested in any serious comments anyone may have. I'm particularly
interested in any comments that point out any serious flaws in what I've
said. I do not consider myself to be a real expert at this - just
reasonably knowledgable with a few years small scale experience ;-)
[...]
> By your logic
> this message I'm typing now is forged.
Please explain how or why.
> You are correct though about 202.87.14.34.
I don't understand what you mean. How or in what way am I correct about
202.87.14.34?
> The simple solution is for people who get these delivered to their inbox to
> report them to Spamcop. This kind of backscatter is considered reportable
> spam. If your mail provider uses the Spamcop RBL, once it's one the RBL you
> won't see it any more. Also, that will likely affect enough mail to get the
> attention of the admins of that server.
I've recently buckled under and started using RBLs on my MTAs and
also tightened up some of the conditions under which they will accept
messages - particularly on the backup mx. I've long been reluctant to
use RBLs as, in a very real way, you are giving partial control of
your MTA to a third party. But, I got tired of the increasing amount of
processor time that spamassassin was using.
So far it looks very good. It seems I've cut out over 90% of the spam
getting into my system and I've still got a few more tweaks I might
make.
When I'm happy with my own setup I'll look into reporting spam that I
find.
--
David Hart <ubuntu at tonix.org>
More information about the ubuntu-users
mailing list