Possible to remove peter at gizmoman.net from users list Was: The "peter at gizmoman.net" dilemma

[Scott Kitterman]

On Friday 05 January 2007 05:06, David Hart wrote:
> 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.

But regardless of the IP address assigned to  www.gizoman.net or gizoman.net 
there is no requirement that outbound mail servers be tied to the domains 
that they send mail from.

> 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.

OK.  I appreciate that.

> 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.

snipped the SMTP exchange.

> 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).

Right.  What your example doesn't show is that the MTA would have accepted the 
message at the end of DATA.  There are MTAs out there that accept everything 
and then reject on the final '.' at the end.  I don' t know why.  There are 
also MTAs out there that send bounce messages to the the message body (RFC 
2822) From rather than rejecting duringing SMTP (note to do this they have to 
accept the message first).  There are some (I believe, but am not sure that 
Mdaemon is one of them) that do both these things.

So, at this point if may well be just an MTA that is, at least in my view, 
broken in an unfortunately not extremely unusual way.

> 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;

I believe that this is another program that tends to bounce to 2822.From.

> #          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.

Agreed.  

> 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.

OK.

> 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.

Agreed.  That's also what dig -x 202.87.14.34 tells me.

> 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.

Yes.

> 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.

I would say it's an indicator.  A made up HELO name is not at all unusual in 
poorly run MTA, which this definitely is. 

> 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.

I'd note that both IP addresses are in Australia.  If this is forgery, it's 
probably not random.  Another possibility is that gizmoman.net uses 
conxion.com.au as a border relay and the final MTA is elsewhere.  This is not 
at all an unsual practice.

> 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.

Yes, but all the references to beach-bum-solutions.com are in the body of the 
message and nothing to do with SMTP.

> 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?

I don't think you've proven anything beyond the bounce is being sent by a 
poorly configured piece of Windows software.  If you take a look at the 
conxion.com.au web site:

http://www.conxion.com.au/

I think you'll find that it's not unlikely that they would be involved in 
poorly configured Windows software.

>
> 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.)

Ask yourself this...  How do they know who to send it to if it's forged?  If 
they just send it so people who've posted previously, then in theory they 
could have scraped the archives for e-mail addresses, but it seems odd.

> The perpetrator may simply be a kiddie who gets a kick out of reading us
> discussing them - who knows?

Motive seems to be lacking.
>
> 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 ;-)
>
Your theory is well thought out, I just think you make a few leaps toward 
forgery where there are alternative explanations avaiable.

> [...]
>
> > By your logic
> > this message I'm typing now is forged.
>
> Please explain how or why.

Your previous message sounded to me like you thought there had to be some 
relationship between the domain name of the MTA and the domain name in 
From/Mail From.  If you look at the header of this (or the previous) message, 
you'll find no obvious link.

> > 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?

I was agreeing that that was the IP the message came from.

> > 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.

I think it's a useful complement to other methods.  I would never reject soley 
based on an RBL like Spamcop, I think it's useful for scoring in 
SpamAssassin.

> 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.

Back to the original point of mine, if people continue to get these and report 
them to Spamcop, the admin of the sending server is likely to notice/get 
complaints once they are blacklisted.

Scott K