abuse complaint [aaronl@vitelus.com: [linux-elitists] X86 assembly as spam]

Dan Wilder dan@ssc.com
Tue Dec 19 08:08:49 PST 2000


Dear Abuse,

So where's the spam you complain of?  There's no commercial email 
attached below.  Only the keyword in the subject line, which might 
trip a crude spam filter, as pertaining to an offer for certain
medications.

The email below plainly contains a technical discussion of certain
computer programming topics.  No good or service is offered for 
sale, nor is any solicitation made.  The email in question originated 
from an opt-in mailing list, linux-elitists@zgp.org, which requires that 
its subscribers not only request to be signed up, but that they return 
a confirming email.

Did a recipient of this email complain, or is your spam filtering
simply defective, detecting spam where there is none, and creating a 
ruckus, to boot?

If a recipient of this email complained, please instruct him or
her to unsubscribe from linux-elitists@zgp.org, which they actively 
subscribed to.  

This may be accomplished by visiting

http://zgp.org/mailman/options/linux-elitists/


----- Forwarded message from Aaron Lehmann <aaronl@vitelus.com> -----

Date: Mon, 18 Dec 2000 20:31:03 -0800
From: Aaron Lehmann <aaronl@vitelus.com>
To: Star Track <linux-elitists@zgp.org>
User-Agent: Mutt/1.2.5i
Subject: [linux-elitists] X86 assembly as spam

----- Forwarded message from abuse@znet.com -----

From: abuse@znet.com
Date: Mon, 18 Dec 2000 20:20:06 -0800 (PST)
To: plex86@fastxs.net, kevoc@bellatlantic.net, abuse@fastxs.net,
	abuse@balpol.tudelft.nl, abuse@mandrakesoft.com, abuse@buffalo.edu,
	abuse@bellatlantic.net
Subject: SPAM: Re: [plex86] Performance enhancement: elminiating mode and co

Below is a SPAM received by a customer of zNET Internet Services.
It originated from your site, used an address referencing your
site, used your company for connectivity, or in some way involved
you.  Please deal with this person according to any AUP's you
have.  Thanks for your time and attention to this problem.

When Spam Burns You: Why Bulk E-mail is Bad Business
http://www.twowriters.net/pages/words_08.html

Spam Laws
http://www.spamlaws.com

Basic Mailing List Management Principles for Preventing Abuse
http://mail-abuse.org/rbl/manage.html

"The makers of our Constitution understood the need to secure
conditions favorable to the pursuit of happiness, and the
protections guaranteed by this are much broader in scope, and
include the right to life and an inviolate personality -- the
right to be left alone -- the most comprehensive of rights
and the right most valued by civilized men.  The principle
underlying the Fourth and Fifth Amendments is protection
against invasions of the sanctities of a man's home and
privacies of life.  This is a recognition of the significance
of man's spiritual nature, his feelings, and his intellect.
Every violation of the right to privacy must be deemed a
violation of the Fourth Amendment."

	- Justice Louis Brandeis


Network Information:

                    

BELL-ATLANTIC1
151.196.0.0     151.205.0.0          banetdc@bellatlantic.net


SPAM Follows:

 From root@sd.znet.com Mon Dec 18 20:16:07 2000
 Received: from sd04.znet.com (sd04.znet.com [207.167.69.1])
 	by mx3.znet.com (8.11.1/8.11.1/jjb-mx3) with ESMTP id eBJ4G5220038
 	for <spam@mx3.znet.com>; Mon, 18 Dec 2000 20:16:05 -0800 (PST)
 Received: from sd.znet.com (sd.znet.com [207.167.64.5])
 	by sd04.znet.com (8.11.1/8.11.1/jjb-sd04) with ESMTP id eBJ4G4526952
 	for <spam@mx3.znet.com>; Mon, 18 Dec 2000 20:16:04 -0800 (PST)
 Received: (from root@localhost)
 	by sd.znet.com (8.11.1/8.11.1/jjb-sd) id eBJ4G2m13872
 	for spam@mx3.znet.com; Mon, 18 Dec 2000 20:16:03 -0800 (PST)
 Received: from lightning.fastxs.net (ns1.fastxs.net [212.204.201.31])
 	by sd.znet.com (8.11.1/8.11.1/jjb-sd) with ESMTP id eBJ4G0g13861
 	for <pdaffy@sd.znet.com>; Mon, 18 Dec 2000 20:16:01 -0800 (PST)
 X-Envelope-From: owner-plex86@fastxs.net
 X-Envelope-To: <pdaffy@sd.znet.com>
 Received: by lightning.fastxs.net (Postfix)
 	id 9080BE8097; Tue, 19 Dec 2000 05:15:05 +0100 (CET)
 Delivered-To: plex86-list@fastxs.net
 Received: by lightning.fastxs.net (Postfix, from userid 522)
 	id 3B41CE808A; Tue, 19 Dec 2000 05:15:05 +0100 (CET)
 Delivered-To: maillist@fastxs.net
 Received: from arizona.localdomain (adsl-151-202-119-56.nyc.adsl.bellatlantic.net [151.202.119.56])
 	by lightning.fastxs.net (Postfix) with ESMTP id E78D4E808A
 	for <plex86@fastxs.net>; Tue, 19 Dec 2000 05:15:02 +0100 (CET)
 Received: (from kevin@localhost)
 	by arizona.localdomain (8.11.0/8.11.0) id eBJ4F0V32201
 	for plex86@fastxs.net; Mon, 18 Dec 2000 23:15:00 -0500
 Date: Mon, 18 Dec 2000 23:14:59 -0500
 From: kevoc@bellatlantic.net
 To: plex86@fastxs.net
 Subject: Re: [plex86] Performance enhancement: elminiating mode and contextswitches
 Message-ID: <20001218231459.A32134@arizona.localdomain>
 References: <Pine.LNX.4.21.0012161146210.6687-100000@server.balpol.tudelft.nl> <3A3E226E.422D1B73@mandrakesoft.com>
 Mime-Version: 1.0
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 User-Agent: Mutt/1.2.5i
 In-Reply-To: <3A3E226E.422D1B73@mandrakesoft.com>; from kevin@mandrakesoft.com on Mon, Dec 18, 2000 at 09:42:54AM -0500
 Sender: owner-plex86@fastxs.net
 Precedence: bulk
 Reply-To: plex86@fastxs.net
 
 On Mon, Dec 18, 2000 at 09:42:54AM -0500, Kevin Lawton wrote:
 > Ramon van Handel wrote:
 > 
 > > > Once you modify the instructions in a page by extending the size
 > > > of an instruction (changing an IO to a call), as opposed to
 > > > inserting an INT3 (always 1 byte), we have to move from our notion
 > > > of simple modified cache pages to a more dynamic translation like
 > > > scheme.  The branch offsets change etc.
 > > 
 > > No, not necessarily.  What you do is overwrite the next instruction and
 > > keep the original in a branch table.  You use a call to go to the
 > > emulation routine; in stead of using ret, however, the emulation routine
 > > will look in the branch table, which contains (1) the next instructions to
 > > be executed, and (2) the address of the first instruction that was not
 > > overwritten.
 > 
 > Sounds good.  I think this has good potential for virtualizing branch
 > instructions.  I see what you mean about virtualizing other instructions
 > which are less than 5 bytes.  Stepping on downstream instructions
 > means either generating dynamic code for arbitrary instructions, or
 > accessing emulation code.  The first option is much work.  The
 > second option is not so good from a run-it-in-ring3 perspective.
 
 I'm not an expert on any of this, but consider the following:
 
 	jmp foo
 	[...]
 	inst1
 foo:	inst2
 	inst3
 
 Let's say 'inst1' is a four byte instruction that we wish to emulate,
 so we replace it, along with part of 'inst2', with a five byte 'call
 xyz' instruction -- what happens to the foo branch?
 
 Note, it wouldn't be possible to scan for all 'jmp foo' instructions
 because the jmp branch offset could be dynamically setup.
 
 Am I missing something?  (I'm by no means an expert in assembler or
 emulation, but I'm curious if this becomes an issue.)
 
 -Kevin
 
 -- 
  ------------------------------------------------------------------------
  | Kevin O'Connor                     "BTW, IMHO we need a FAQ for      |
  | koconnor@cse.buffalo.edu            'IMHO', 'FAQ', 'BTW', etc. !"    |
  ------------------------------------------------------------------------
 



----- End forwarded message -----



----- End forwarded message -----

-- 
Dan Wilder
Happy Subscriber
linux-elitists@zgp.org



More information about the linux-elitists mailing list