[prev in list] [next in list] [prev in thread] [next in thread] 

List:       list-managers
Subject:    Re: Problem with annoyance attacks
From:       "Ronald F. Guilmette" <rfg () monkeys ! com>
Date:       1998-06-20 18:21:29
Message-ID: 20526.898366889 () monkeys ! com
[Download RAW message or body]


In message <199806200919290740.000D79FD@mail.salemcarriers.com>, 
"Spencer Yost" <Spencer_Yost@salemcarriers.com> wrote:

>I have a user who has found a way to pester and annoy everyone on one of my
>lists.  Basically, he simply takes every message and forwards the message
>to a bogus user at another site (sites and names hidden to protect the
>innocent).  The remote site bounces the message with "No such user" ,
>ordinarily no problem, but the site incorrectly routes the error to the
>sender of a message rather than the address in the errors-to header of the
>message.
>
>The consequence is, every time a subscriber posts to my list, they get this
>error message sent to their email address.  As you can imagine, this upsets
>the subscribers immensely.   I currently am trying to isolate the address
>doing this forwarding, by trying to sync maillog times and the times the
>error message returns, but have not had any luck(over a thousand
>subscribers and this method only narrows it down to two hundred or so).
>
>I have band-aided the problem by having the remote system admin add the
>user so it is no longer bogus, but obviously it is only a matter of time
>before he picks a new address and does the same thing again.  Does anyone
>have a suggestion or war story that help me isolate the weasel?  Some ideas
>come to mind, like sending sequenced mail that impersonates list mail to
>each of the two hundred possible subscribers mentioned above and then
>watching to see which sequence number returns.   I don't know how to go
>about doing that (or how ethical it is) though.

[META COMMENT:  The art and skill of E-mail header reading may be useful to
list managers in many contexts, not just really unusual ones like what is
described above.  For example, tracking down the root cause of ordinary
bounces is something that list managers may often need to do, and I hope
therefore that the following material will be of general usefulness, not
just as advice aimed to helping with the specific problem posed above.]

I have a suggestion, but you probably already thought of this.  Please don't
be insulted if you did.  I have to throw it out just in case you didn't.

You may be able to pin down the identity of the specific subscriber who is
doing this rogue/malicious forwarding just by looking really carefully at
the headers of the ORIGINAL MESSAGES which should appear somewhere in
the bodies of the BOUNCE MESSAGES that your other subscribers are receiving.

Specifically, some/many types of SMTP mail servers will, put what I call a
`for clause' into the Received: headers that they generate as they are
handling/fondling/relaying/delivering various E-mail messages.  In many
cases, if the topmost Received: header or the one right below that contains
such a clause, then the E-mail address in that clause will show who it was
being delivered to on the local (receiving) system.

For example, your message to the List-Managers mailing list got routed thru
_several_ (6) different mail servers on its way from you to me.  The last
one that handled it however was _my_ local mail server here on my machine
(called monkeys.com) which got the message from the mail server operated by
my MX site (eagle.ns.net).  So here is the topmost Received: header that I
see on the mail that I got (via the mailing list) from you:

-------------------------------------------------------------------------
Received: from eagle.ns.net (smtp@eagle.ns.net [204.75.146.20])
        by monkeys.com (8.8.8/8.8.5) with ESMTP id KAA18352
        for <rfg@MONKEYS.COM>; Sat, 20 Jun 1998 10:00:06 -0700
-------------------------------------------------------------------------

Pay particular attention to that `for' clause at the start of the third
physical line of this Received: header.  That is indeed MY ADDRESS.

The final destination recipient address was also present and visible in
the `for' clause of the next lower Received: header which was attached to
your message as it made its way from you to me (via those 6 different mail
servers):

-------------------------------------------------------------------------
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8])
        by eagle.ns.net (8.8.5/8.8.5) with ESMTP id GAA05362
        for <rfg@monkeys.com>; Sat, 20 Jun 1998 06:43:28 -0700 (PDT)
-------------------------------------------------------------------------

This Received: line shows that the message was sent from relay3.UU.NET to
my MX site, eagle.ns.net.  Note that already at this point, the final
recipient address was known and can be seen in the `for' clause.  (It
appears that outgoing mail for the `greatcircle.com' domain... which
hosts the List-Managers mailing list... may perhaps always be sent out
via the mail servers at UUnet, and that explains why the mail came me
my MX site via relay3.UU.NET.)

Now for the bad news.  Not all mail servers put a `for' clause into the
Received: headers that they generate.  For example, the next Received:
header that I see attached to *my personal copy* of your message to the
List-Managers mailing list looks like:

--------------------------------------------------------------------------
Received: from honor.greatcircle.com by relay3.UU.NET with ESMTP 
        (peer crosschecked as: honor.greatcircle.com [198.102.244.44])
        id QQeupa08291; Sat, 20 Jun 1998 09:40:50 -0400 (EDT)
--------------------------------------------------------------------------

This shows the step where relay3.UU.NET got the message from the machine
that is actually hosting the List-Managers mailing list, i.e. the machine
called honor.greatcircle.com.  Note that this one DOESN'T have any `for'
clause. :-(

So you can't always make use of the information in the `for' clauses for
the simple reason that they are not always present.  But if they are
present, then they can perhaps be helpful to you in tracking down the
specific subscriber address that is giving you grief.  Note however that
the `for' clauses, even when present, only show what is called the ``envelope
recipient address'' for the message as it exists at the specific stage of
the mail forwarding associated with the specific Received: header which
contains the given `for' clause, and unless you are looking at a `for'
clause in the very topmost Received: header on a given (delivered) message,
the value you see if the `for' clause may perhaps NOT represent the
addres of the real and final recipient, and may therefore be misleading.

For example, on my copy of your message to the List-Managers mailing list,
the very LOWEST (i.e. earliest) Received: header shows the mail message
traveling from the specific machine/IP address that _you_ were using at
the time you sent your message to your own local mail server:

-----------------------------------------------------------------------------
Received: from yost (Janeway-25.netunlimited.net [208.128.132.74])
        by cat.salemcarriers.com (8.8.8/8.8.8) with SMTP id JAA04932
        for <list-managers@GreatCircle.COM>; Sat, 20 Jun 1998 09:13:47 -0400
-----------------------------------------------------------------------------

Note that during _that_ transfer of the message, the envelope recipient
address had not yet been expanded out to the many different and separate
subscriber address for the List-Managers mailing list, because the message
had not yet been received by the machine `honor.greatcircle.com' where such
expansion occurs.  Thus, what you see here in _this_ Received: header is
a `for' clause that specifies the posting address of the mailing list
itself, rather than my personal address.

These sorts of translations of an envelope recipient address can happen
anywhere in the pipeline (due to mailing list expansion, mail aliases,
and .forward files) and this is why the most reliable indicator of the
_true_ final recipient address of any given mail message is always the
`for' clause of the *topmost* (i.e. latest) Received: header on any given
message.

Sendmail, which is the mail server still used on over 80% of all Internet
mail hosts, puts these `for' clauses into the Received: headers that it
generates PROVIDED THAT the message in question is being delivered to ONE
AND ONLY ONE address on the final destination machine.  Thus, unfortunately,
if there had been TWO OR MORE subscribers to the List-Managers mailing
list in the monkeys.com domain, then the first Received: header I showed
you above probably would not have contained any `for' clause, but that is
highly dependent on the exact mechanisms that the List-Manager mailing
list uses to distribute its messages.  If it tries to economize bandwidth
by sending only one copy of each message to each domain where there are one
or more subscribers (ie. one copy of the message but with multiple envelope
recipient addresses specified), then any Sendmail server in any of the sub-
scriber domains where there are two or more subscribers will generate a
Received: header which _does not_ contain a `for' clause.  (What that
should tell you is that the more efficient your MLM software is, the less
able you will be to track down the final recipient address for various
bounces, etc.)

Good luck with your unusual problem!


-- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc.
-- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/
-- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/


[prev in list] [next in list] [prev in thread] [next in thread]