[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]


..[ Phrack Magazine ]..
.:: Network Miscellany ::.

Issues: [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ] [ 51 ] [ 52 ] [ 53 ] [ 54 ] [ 55 ] [ 56 ] [ 57 ] [ 58 ] [ 59 ] [ 60 ] [ 61 ] [ 62 ] [ 63 ] [ 64 ] [ 65 ] [ 66 ] [ 67 ] [ 68 ] [ 69 ] [ 70 ]
Current issue : #41 | Release date : 1992-12-31 | Editor : Dispater
IntroductionDispater
Phrack LoopbackMind Mage & Dispater
Phrack Pro-Phile on SuperniggerSupernigger
Network MiscellanyThe Racketeer
Pirates CoveRambone
Hacking AT&T System 75Scott Simpson
How To Build a DMS-10 Switchcavalier
TTY SpoofingVaxBuster
Security Shortcomings of AppleShare NetworksBobby Zero
Mall Cop FrequenciesCaligula XXI
PWN/Part 1Datastream Cowboy
PWN/Part 2Datastream Cowboy
PWN/Part 3Datastream Cowboy
Title : Network Miscellany
Author : The Racketeer
                                ==Phrack Inc.==

                   Volume Four, Issue Forty-One, File 4 of 13

                               Network Miscellany
            *******************************************************
           <              The POWER of Electronic Mail             >
            *******************************************************
                         Compiled from Internet Sources

                                by The Racketeer
                              of The Hellfire Club

                    Network Miscellany created by Taran King


     First of all, this guide is more than using fakemail.  It literally
explains the interfaces used with SMTP in detail enough that you should gain a
stronger awareness of what is going on across the multitude of networks which
make up the worldwide e-mail connections.  It also contains my usual crude
remarks and grim hacker humor (assuming it hasn't again been edited out, but
I'm somewhat proud of the fact that Phrack heavily edited my "language" in last
issue's article.  Oh well.).

     There are two objectives in this file:  first, I will attempt to show that
by using fakemail and SMTP, you can cause an amazing number of useful, hacker
related stunts; second, I shall attempt to be the first hacker to ever send a
piece of electronic mail completely around the world, ushering in a new age of
computerdom!

     I suggest that, unless you don't want everyone lynching you, don't try to
fuck up anything that can't be repaired offhand.  I've experimented with
fakemail beyond this article and the results were both impressive and
disastrous.  Therefore, let's examine risks first, and then go onto the good
stuff.  Basic philosophy -- use your brain if you've got one.


RISKS:

     Getting caught doing this can be labeled as computer vandalism; it may
violate trespassing laws; it probably violates hundreds of NFS, Bitnet and
private company guidelines and ethics policies; and finally, it will no doubt
piss someone off to the point of intended revenge.

     Networks have fairly good tracing abilities.  If you are logged, your host
may be disconnected due to disciplinary referral by network authorities (I
don't think this has happened yet).  Your account will almost definitely be
taken away, and if you are a member of the source or target computer's
company/organization, you can expect to face some sort of political shit that
could result in suspension, expulsion, firing, or otherwise getting the short
end of the stick for awhile.

     Finally, if the government catches you attempting to vandalize another
computer system, you will probably get some sort of heavy fine, community
service, or both.

     Odds of any of this happening if you are smart:  < 1%.


PRECAUTIONS SUGGESTED:

     If you have a bogus computer account (standard issue hacker necessity)
then for crissake use that.  Don't let "them" know who really is hacking
around.  (Point of clarification, I refer to "them" an awful lot in RL and in
philes.  "They" are the boneheadded "do-gooders" who try to blame their own
lack of productivity or creativity on your committing of pseudo-crimes with a
computer.  FBI, SS, administrators, accountants, SPA "Don't Copy that Floppy"
fucks, religious quacks, stupid rednecks, right wing conservative Republican
activists, pigs, NSA, politicians who still THINK they can control us, city
officials, judges, lame jurors that think a "hacker" only gets
slap-in-the-wrist punishments, lobbyists who want to blame their own failed
software on kids, bankers, investors, and probably every last appalled person
in Stifino's Italian Restaurant when the Colorado 2600 meeting was held there
last month.  Enough of the paranoid Illuminati shit, back to the phile.)

     Make sure that you delete history files, logs, etc. if you have
access to them.  Try using computers that don't keep logs.  Check /usr/adm,
/etc/logs to see what logs are kept.

     If you can avoid using your local host (since you value network
connections in general), do so.  It can avert suspicion that your host contains
"hackers."


IF YOU EVER ARE CONFRONTED:

     "They must have broken into that account from some other site!"

     "Hackers?  Around here?  I never check 'who' when I log in."

     "They could have been super-user -- keep an eye out to see if the scum
      comes back."

     "Come on, they are probably making a big deal out of nothing.  What could
      be in e-mail that would be so bad?"

     "Just delete the account and the culprit will be in your office tomorrow
      morning."   (Of course, you used a bogus account.)


PART ONE:  ELECTRONIC MAIL

     Basically, electronic mail has become the new medium of choice for
delivering thoughts in a hurry.  It is faster than the post office, cheaper
than the post office, doesn't take vacations all the time like the post office,
and is completely free so it doesn't have unions.

     Of course, you know all that and would rather spend this time making damn
sure you know what SMTP is.

     To my knowledge, a completely accurate SMTP set of protocols hasn't been
published in any hacker journal.  The original (at least, the first I've seen)
was published in the Legion of Doom Technical Journals and covered the minimum
SMTP steps necessary for the program "sendmail," found in a typical Unix
software package.

     When you connect a raw socket to a remote SMTP compatible host, your
computer is expected to give a set of commands which will result in having the
sender, receiver, and message being transferred.  However, unlike people who
prefer the speed of compression and security of raw integer data, the folks at
DARPA decided that SMTP would be pretty close to English.

     If you are on the Internet, and you wanted to connect to the SMTP server,
type:

       telnet <hostname> 25

     Port 25 is the standard port for SMTP.  I doubt it would be too cool to
change this, since many mail servers connect to the target hosts directly.

[Editor's Note:  All mail and SMTP commands have been offset by a ">" at the
 beginning of each line in order not to confuse Internet mailers when sending
 this article through e-mail.]

     When you connect, you will get a small hostname identifier for whatever
SMTP server revision you've got.

220 huggies.colorado.edu Sendmail 2.2/2.5 8/01/88 ready at Tue, 25 Aug 91
03:14:55 edt

     Now that you are connected, the computer is waiting for commands.  First
of all, you are expected to explain which computer you are calling in from.
This is done with the HELO <host> command.  This can be anything at all, but if
you fail to give the exact host that you are connecting from, it causes the
following line to appear on the e-mail message the recipient gets from you:

> Apparently-to:  The Racketeer <rack@lycaeum.hfc.com>

     Instead of the classic:

> To:  The Racketeer <rack@lycaeum.hfc.com>

     This is the secret to great fakemail -- the ability to avoid the
"apparently-to" flag.  Although it is subtle, it is a pain to avoid.  In fact,
in some places, there are so many "protections" to SMTP that every outside
e-mail is marked with "Apparently-to."  Hey, their problem.

     So, go ahead and type the HELO command:

> HELO LYCAEUM.HFC.COM

The computer replies:

250 huggies.colorado.edu Hello LYCAEUM.HFC.COM, pleased to meet you

    Oh, a warm reception.  Older sendmail software explains with the HELP
command that the computer doesn't care about HELO commands.  You can check it
upon login with the command "HELP HELO."

    Now what you will need to do is tell the computer who is supposed to get
the letter.  From this point, there are all sorts of possibilities.  First of
all, the format for the recipient would be:

> RCPT TO: <name@host>

    And *NOTE*, the "<" and ">" symbols should be present!  Some computers,
especially sticklers like Prime, won't even accept the letters unless they
adhere specifically to the protocol!  Now, if you give a local address name,
such as:

> RCPT TO: <smith>

    ...then it will treat the mail as if it were sent locally, even though it
was sent through the Internet.  Giving a computer its own host name is valid,
although there is a chance that it will claim that the machine you are calling
from had something to do with it.

> RCPT TO: <smith@thishost>

    ...will check to see if there is a "smith" at this particular computer.  If
the computer finds "smith," then it will tell you there is no problem.  If you
decide to use this computer as a forwarding host (between two other points),
you can type:

> RCPT TO: <smith@someotherhost>

     This will cause the mail to be forwarded to someotherhost's SMTP port and
the letter will no longer be a problem for you.  I'll be using this trick to
send my letter around the world.

     Now, after you have given the name of the person who is to receive the
letter, you have to tell the computer who is sending it.

> MAIL FROM: <rack@lycaeum.hfc.com>      ; Really from
> MAIL FROM: <rack>                      ; Localhost
> MAIL FROM: <rack@osi.mil>              ; Fake -- "3rd party host"
> MAIL FROM: <lycaeum.hfc.com|rack>      ; UUCP Path

     Essentially, if you claim the letter is from a "3rd party," then the other
machine will accept it due to UUCP style routing.  This will be explained later
on.

     The next step is actually entering the e-mail message.  The first few
lines of each message consists of the message title, X-Messages, headers,
Forwarding Lines, etc.  These are completely up to the individual mail program,
but a few simple standards will be printed later, but first let's run through
the step-by-step way to send fakemail.  You type anything that isn't preceded
by a number.

220 hal.gnu.ai.mit.edu Sendmail AIX 3.2/UCB 5.64/4.0 ready at Tue, 21 Jul 1992
22:15:03 -0400
> helo lycaeum.hfc.com
250 hal.gnu.ai.mit.edu Hello lycaeum.hfc.com, pleased to meet you
> mail from: <rack@lycaeum.hfc.com>
250 <rack@lycaeum.hfc.com>... Sender ok
> rcpt to: <phrack@gnu.ai.mit.edu>
250 <phrack@gnu.ai.mit.edu>... Recipient ok
> data
354 Enter mail, end with "." on a line by itself
> Yo, C.D. -- mind letting me use this account?
> .
250 Ok
> quit

     Now, here are a few more advanced ways of using sendmail.  First of all,
there is the VRFY command.  You can use this for two basic things:  checking up
on a single user or checking up on a list of users.  Anyone with basic
knowledge of ANY of the major computer networks knows that there are mailing
lists which allow several people to share mail.  You can use the VRFY command
to view every member on the entire list.

> vrfy phrack
250 Phrack Classic <phrack>

     Or, to see everyone on a mailing list:

> vrfy phrack-staff-list
250 Knight Lightning <kl@stormking.com>
250 Dispater <dispater@stormking.com>

     Note - this isn't the same thing as a LISTSERV -- like the one that
distributes Phrack.  LISTSERVs themselves are quite powerful tools because they
allow people to sign on and off of lists without human moderation.  Alias lists
are a serious problem to moderate effectively.

     This can be useful to just check to see if an account exists.  It can be
helpful if you suspect a machine has a hacked finger daemon or something to
hide the user's identity.  Getting a list of users from mailing lists doesn't
have a great deal of uses, but if you are trying very hard to learn someone's
real identity, and you suspect they are signed up to a list, just check for all
users from that particular host site and see if there are any matches.

     Finally, there is one last section to e-mail -- the actual message itself.
In fact, this is the most important area to concentrate on in order to avoid
the infamous "Apparently-to:" line.  Basically, the data consists of a few
lines of title information and then the actual message follows.

     There is a set of guidelines you must follow in order for the quotes to
appear in correct order.  You won't want to have a space separate your titles
from your name, for example.  Here is an example of a real e-mail message:

> From: rack@lycaeum.hfc.com
> Received: by dockmaster.ncsc.mil (5.12/3.7) id AA10000; Thu, 6 Feb 92
> 12:00:00
> Message-Id: <666.AA10000@dockmaster.ncsc.mil>
> To: RMorris@dockmaster.ncsc.mil
> Date: Thu, 06 Feb 92 12:00:00
> Title: *wave* Hello, No Such Agency dude!
>
> NIST sucks.  Say "hi" to your kid for me from all of us at Phrack!

    Likewise, if you try to create a message without an information line, your
message would look something like this:

> From: rack@lycaeum.hfc.com
> Received: by dockmaster.ncsc.mil (5.12/3.7) id AA10000; Thu, 6 Feb 92
> 12:00:00 -0500
> Message-Id: <666.AA10000@dockmaster.ncsc.mil>
> Date: Thu, 06 Feb 92 12:00:00
> Apparently-to: RMorris@dockmaster.ncsc.mil

> NIST sucks.  Say "hi" to your kid for me from all of us at Phrack!

     Basically, this looks pretty obvious that it's fakemail, not because I
altered the numbers necessarily, but because it doesn't have a title line, it
doesn't have the "Date:" in the right place, and because the "Apparently-to:"
designation was on.

    To create the "realistic" e-mail, you would enter:

> helo lycaeum.hfc.com
> mail from: <rack@lycaeum.hfc.com>
> rcpt to: <RMorris@docmaster.ncsc.mil>
> data
> To:  RMorris@dockmaster.ncsc.mil>
> Date: Thu, 06 Feb 92 12:00:00
> Title: *wave* Hello, No Such Agency dude!
>
> NIST sucks.  Say "hi" to your kid for me from all of us at Phrack!
> .

     Notice that, even though you are in "data" mode, you are still giving
commands to sendmail.  All of the lines can (even if only partially) be altered
through the data command.  This is perfect for sending good fakemail.  For
example:

> helo lycaeum.hfc.com
> mail from: <dale@opus.tymnet.com>
> rcpt to: <listserv@brownvm.brown.edu>
> data
> Received: by lycaeum.hfc.com (5.12/3.7) id AA11891; Thu 6 Feb 92 12:00:00
> Message-Id: <230.AA11891@lycaeum.hfc.com>
> To: <listserv@brownvm.brown.edu>
> Date: Thu, 06 Feb 92 12:00:00
> Title:  Ohh, sign me up Puuuleeeze.
>
> subscribe BISEXU-L Dale "Fist Me" Drew
> .

     Now, according to this e-mail path, you are telling the other computer
that you received this letter from OPUS.TYMNET.COM, and it is being forwarded
by your machine to BROWNVM.BROWN.EDU.  Basically, you are stepping into the
middle of the line and claiming you've been waiting there all this time.  This
is a legit method of sending e-mail!

     Originally, when sendmail was less automated, you had to list every
computer that your mail had to move between in order for it to arrive.  If you
were computer ALPHA, you'd have to send e-mail to account "joe" on computer
GAMMA by this address:

> mail to: <beta!ceti!delta!epsilon!freddy!gamma!joe>

     Notice that the account name goes last and the host names "lead" up to
that account.  The e-mail will be routed directly to each machine until it
finally reaches GAMMA.  This is still required today, especially between
networks like Internet and Bitnet -- where certain hosts are capable of sending
mail between networks.  This particular style of sending e-mail is called "UUCP
Style" routing.

     Sometimes, hosts will use the forwarding UUCP style mail addresses in case
the host has no concept of how to deal with a name address.  Your machine
simply routes the e-mail to a second host which is capable of resolving the
rest of the name.  Although these machines are going out of style, they still
exist.

     The third reasonable case of where e-mail will be routed between hosts is
when, instead of having each computer waste individual time dealing with each
piece of e-mail that comes about, the computer gives the mail to a dedicated
mailserver which will then deliver the mail.  This is quite common all over the
network -- especially due to the fact that the Internet is only a few T1 lines
in comparison to the multitude of 9600 and 14.4K baud modems that everyone is
so protective of people over-using.  Of course, this doesn't cause the address
to be in UUCP format, but when it reaches the other end of the network, it'll
be impossible to tell what method the letter used to get sent.

     Okay, now we can send fairly reasonable electronic fakemail.  This stuff
can't easily be distinguished between regular e-mail unless you either really
botched it up (say, sending fakemail between two people on the same machine by
way of 4 national hosts or something) or really had bad timing.

     Let's now discuss the POWER of fakemail.  Fakemail itself is basically a
great way to fool people into thinking you are someone else.  You could try to
social engineer information out of people on a machine by fakemail, but at the
same time, why not just hack the root password and use "root" to do it?  This
way you can get the reply to the mail as well.  It doesn't seem reasonable to
social engineer anything while you are root either.  Who knows.  Maybe a really
great opportunity will pop up some day -- but until then, let's forget about
dealing person-to-person with fakemail, and instead deal with
person-to-machine.

     There are many places on the Internet that respond to received electronic
mail automatically.  You have all of the Archie sites that will respond, all of
the Internet/Bitnet LISTSERVs, and Bitmail FTP servers.  Actually, there are
several other servers, too, such as the diplomacy adjudicator.  Unfortunately,
this isn't anywhere nearly as annoying as what you can do with other servers.

     First, let's cover LISTSERVs.  As you saw above, I created a fakemail
message that would sign up Mr. Dale Drew to the BISEXU-L LISTSERV.  This means
that any of the "netnews" regarding bisexual behavior on the Internet would be
sent directly to his mailbox.  He would be on this list (which is public and
accessible by anyone) and likewise be assumed to be a member of the network
bisexual community.

     This fakemail message would go all the way to the LISTSERV, it would
register Mr. Dictator for the BISEXU-L list, >DISCARD< my message, and, because
it thinks that Dale Drew sent the message, it will go ahead and sign him up to
receive all the bisexual information on the network.

     And people wonder why I don't even give out my e-mail address.

     The complete list of all groups on the Internet is available in the file
"list_of_lists" which is available almost everywhere so poke around
wuarchive.wustl.edu or ftp.uu.net until you find it.  You'll notice that there
are several groups that are quite fanatic and would freak out nearly anybody
who was suddenly signed up to one.

     Ever notice how big mega-companies like IBM squelch little people who try
to make copies of their ideas?  Even though you cannot "patent" an "idea,"
folks like IBM want you to believe they can.  They send their "brute" squad of
cheap lawyers to "legal-fee-to-death" small firms.  If you wanted to
"nickel-and-dime" someone out of existence, try considering the following:

     CompuServe is now taking electronic mail from the Internet.  This is good.
CompuServe charges for wasting too much of their drive space with stored
e-mail.  This is bad.  You can really freak out someone you don't like on
CompuServe by signing them up to the Dungeons and Dragons list, complete with
several megabytes of fluff per day.  This is cool.  They will then get charged
hefty fines by CompuServe.  That is fucked up.  How the hell could they know?

    CompuServe e-mail addresses are userid@compuserve.com, but as the Internet
users realize, they can't send commas (",") as e-mail paths.  Therefore, use a
period in place of every comma.  If your e-mail address was 767,04821 on
CompuServe then it would be 767.04821 for the Internet. CompuServe tends to
"chop" most of the message headers that Internet creates out of the mail before
it reaches the end user.  This makes them particularly vulnerable to fakemail.

     You'll have to check with your individual pay services, but I believe such
groups as MCI Mail also have time limitations.  Your typical non-Internet-
knowing schmuck would never figure out how to sign off of some God-awful fluff
contained LISTSERV such as the Advanced Dungeons & Dragons list.  The amount of
damage you could cause in monetary value alone to an account would be
horrendous.

     Some groups charge for connection time to the Internet -- admittedly, the
fees are reasonable -- I've seen the price at about $2 per hour for
communications.  However, late at night, you could cause massive e-mail traffic
on some poor sap's line that they might not catch.  They don't have a way to
shut this off, so they are basically screwed.  Be WARY, though -- this sabotage
could land you in deep shit.  It isn't actually fraud, but it could be
considered "unauthorized usage of equipment" and could get you a serious fine.
However, if you are good enough, you won't get caught and the poor fucks will
have to pay the fees themselves!

     Now let's investigate short-term VOLUME damage to an e-mail address.
There are several anonymous FTP sites that exist out there with a service known
as BIT FTP.  This means that a user from Bitnet, or one who just has e-mail and
no other network services, can still download files off of an FTP site.  The
"help" file on this is stored in Appendix C, regarding the usage of Digital's
FTP mail server.

     Basically, if you wanted to fool the FTP Mail Server into bombarding some
poor slob with an ungodly huge amount of mail, try doing a regular "fakemail"
on the guy, with the enclosed message packet:

> helo lycaeum.hfc.com
> mail from: <dale@opus.tymnet.com>
> rcpt to: <ftpmail@decwrl.dec.com>
> data
> Received: by lycaeum.hfc.com (5.12/3.7) id AA10992; Fri 9 Oct 92 12:00:00
> Message-Id: <230.AA11891@lycaeum.hfc.com>
> To: <listserv@brownvm.brown.edu>
> Date: Fri, 09 Oct 92 12:00:00
> Title:  Hey, I don't have THAT nifty program!
>
> reply dale@opus.tymnet.com
> connect wuarchive.wustl.edu anonymous fistme@opus.tymnet.com
> binary
> get mirrors/gnu/gcc-2.3.2.tar.Z
> quit
> .

        What is particularly nasty about this is that somewhere between 15 and
20 megabytes of messages are going to be dumped into this poor guy's account.
All of the files will be uuencoded and broken down into separate messages!
Instead of deleting just one file, there will be literally hundreds of messages
to delete!  Obnoxious!  Nearly impossible to trace, too!


Part 2:  E-MAIL AROUND THE WORLD

     Captain Crunch happened to make a telephone call around the world, which
could have ushered in the age of phreak enlightenment -- after all, he proved
that, through the telephone, you could "touch someone" anywhere you wanted
around the world!  Billions of people could be contacted.

     I undoubtedly pissed off a great number of people trying to do this e-mail
trick -- having gotten automated complaints from many hosts.  Apparently, every
country has some form of NSA.  This doesn't surprise me at all, I'm just
somewhat amazed that entire HOSTS were disconnected during the times I used
them for routers.  Fortunately, I was able to switch computers faster than they
were able to disconnect them.

     In order to send the e-mail, I couldn't send it through a direct path.
What I had to do was execute UUCP style routing, meaning I told each host in
the path to send the e-mail to the next host in the path, etc., until the last
machine was done.  Unfortunately, the first machine I used for sending the
e-mail had a remarkably efficient router and resolved the fact that the target
was indeed the destination.  Therefore, I re-altered the path to a machine
sitting about, oh, two feet away from it.  Those two feet are meaningless in
this epic journey.

      The originating host names have been altered as to conceal my identity.
However, if we ever meet at a Con, I'll probably have the real print-out of the
results somewhere and you can verify its authenticity.  Regardless, most of
this same shit will work from just about any typical college campus Internet
(and even Bitnet) connected machines.

     In APPENDIX A, I've compiled a list of every foreign country that I could
locate on the Internet.  I figured it was relatively important to keep with the
global program and pick a series of hosts to route through that would
presumably require relatively short hops.  I did this by using this list and
trial and error (most of this information was procured from the Network
Information Center, even though they deliberately went way the hell out of
their way to make it difficult to get computers associated with foreign
countries).

     My ultimate choice of a path was:

     lycaeum.hfc.com           -- Origin, "middle" America.
     albert.gnu.ai.mit.edu     -- Massachusetts, USA.
     isgate.is                 -- Iceland
     chenas.inria.fr           -- France
     icnucevx.cnuce.cn.it      -- Italy
     sangram.ncst.ernet.in     -- India
     waseda-mail.waseda.ac.jp  -- Japan
     seattleu.edu              -- Seattle
     inferno.hfc.com           -- Ultimate Destination

     The e-mail address came out to be:

isgate.is!chenas.inria.fr!icnucevx.cnuce.cn.it!sangram.ncst.ernet.in!
waseda-mail.waseda.ac.jp!seattleu.edu!inferno.hfc.com!
rack@albert.gnu.ai.mit.edu

     ...meaning, first e-mail albert.gnu.ai.mit.edu, and let it parse the name
down a line, going to Iceland, then to France, etc. until it finally reaches
the last host on the list before the name, which is the Inferno, and deposits
the e-mail at rack@inferno.hfc.com.

     This takes a LONG time, folks.  Every failure toward the end took on
average of 8-10 hours before the e-mail was returned to me with the failure
message. In one case, in fact, the e-mail made it shore to shore and then came
all the way back because it couldn't resolve the last hostname!  That one made
it (distance-wise) all the way around the world and half again.

     Here is the final e-mail that I received (with dates, times, and numbers
     altered to squelch any attempt to track me):

> Return-Path: <rack@lycaeum.hfc.com>
> Received: from sumax.seattleu.edu [192.48.211.120] by Lyceaum.HFC.Com ; 19
        Dec 92 16:23:21 MST
> Received: from waseda-mail.waseda.ac.jp by sumax.seattleu.edu with SMTP id
>         AA28431 (5.65a/IDA-1.4.2 for rack@inferno.hfc.com); Sat, 19 Dec 92
>         14:26:01 -0800
> Received: from relay2.UU.NET by waseda-mail.waseda.ac.jp (5.67+1.6W/2.8Wb)
>         id AA28431; Sun, 20 Dec 92 07:24:04 JST
> Return-Path: <rack@lycaeum.hfc.com>
> Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
>         (5.61/UUNET-internet-primary) id AA28431; Sat, 19 Dec 92 17:24:08 -
>         0500
> Received: from sangam.UUCP by uunet.uu.net with UUCP/RMAIL
>         (queueing-rmail) id 182330.3000; Sat, 19 Dec 1992 17:23:30 EST
> Received: by sangam.ncst.ernet.in (4.1/SMI-4.1-MHS-7.0)
>         id AA28431; Sun, 20 Dec 92 03:50:19 IST
> From: rack@lycaeum.hfc.com
> Received: from shakti.ncst.ernet.in by saathi.ncst.ernet.in
>         (5.61/Ultrix3.0-C)
>         id AA28431; Sun, 20 Dec 92 03:52:12 +0530
> Received: from saathi.ncst.ernet.in by shakti.ncst.ernet.in with SMTP
>         (16.6/16.2) id AA09700; Sun, 20 Dec 92 03:51:37 +0530
> Received: by saathi.ncst.ernet.in (5.61/Ultrix3.0-C)
>         id AA28431; Sun, 20 Dec 92 03:52:09 +0530
> Received: by sangam.ncst.ernet.in (4.1/SMI-4.1-MHS-7.0)
>         id AA28431; Sun, 20 Dec 92 03:48:24 IST
> Received: from ICNUCEVX.CNUCE.CNR.IT by relay1.UU.NET with SMTP
>         (5.61/UUNET-internet-primary) id AA28431; Sat, 19 Dec 92 17:20:23
>         -0500
> Received: from chenas.inria.fr by ICNUCEVX.CNUCE.CNR.IT (PMDF #2961 ) id
>  <01GSIP122UOW000FBT@ICNUCEVX.CNUCE.CNR.IT>; Sun, 19 Dec 1992 23:14:29 MET
> Received: from isgate.is by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet
>  id AA28431; Sun, 19 Dec 1992 23:19:58 +0100 (MET)
> Received: from albert.gnu.ai.mit.edu by isgate.is (5.65c8/ISnet/14-10-91);
> Sat, 19 Dec 1992 22:19:50 GMT
> Received: from lycaeum.hfc.com by albert.gnu.ai.mit.edu (5.65/4.0) with
>  SMTP id <AA28431@albert.gnu.ai.mit.edu>; Sat, 19 Dec 92 17:19:36 -0500
> Received: by lycaeum.hfc.com (5.65/4.0) id <AA11368@lycaeum.hfc.com>;
>  Sat, 19 Dec 92 17:19:51 -0501
> Date: 19 Dec 1992 17:19:50 -0500 (EST)
> Subject: Global E-Mail
> To:   rack@inferno.hfc.com
> Message-id: <9212192666.AA11368@lycaeum.hfc.com>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> X-Mailer: ELM [version 2.4 PL5]
> Content-Length: 94
> X-Charset: ASCII
> X-Char-Esc: 29
>
> This Electronic Mail has been completely around the world!
>
> (and isn't even a chain letter.)

===============================================================================

APPENDIX A:

List of Countries on the Internet by Root Domain

(I tried to get a single mail router in each domain.  The domains that don't
 have them are unavailable at my security clearance.  The computer is your
 friend.)

.AQ        New Zealand
.AR        Argentina        atina.ar
.AT        Austria          pythia.eduz.univie.ac.at
.BB        Barbados
.BE        Belgium          ub4b.buug.be
.BG        Bulgaria
.BO        Bolivia          unbol.bo
.BR        Brazil           fpsp.fapesp.br
.BS        Bahamas
.BZ        Belize
.CA        Canada           cs.ucb.ca
.CH        Switzerland      switch.ch
.CL        Chile            uchdcc.uchile.cl
.CN        China            ica.beijing.canet.cn
.CR        Costa Rica       huracan.cr
.CU        Cuba
.DE        Germany          deins.informatik.uni-dortmund.de
.DK        Denmark          dkuug.dk
.EC        Ecuador          ecuanex.ec
.EE        Estonia          kbfi.ee
.EG        Egypt
.FI        Finland          funet.fi
.FJ        Fiji
.FR        France           inria.inria.fr
.GB        England
.GR        Greece           csi.forth.gr
.HK        Hong Kong        hp9000.csc.cuhk.hk
.HU        Hungary          sztaki.hu
.IE        Ireland          nova.ucd.ie
.IL        Israel           relay.huji.ac.il
.IN        India            shakti.ernet.in
.IS        Iceland          isgate.is
.IT        Italy            deccnaf.infn.it
.JM        Jamaica
.JP        Japan            jp-gate.wide.ad.jp
.KR        South Korea      kum.kaist.ac.kr
.LK        Sri Lanka        cse.mrt.ac.lk
.LT        Lithuania        ma-mii.lt.su
.LV        Latvia
.MX        Mexico           mtec1.mty.itesm.mx
.MY        Malaysia         rangkom.my
.NA        Namibia
.NI        Nicaragua        uni.ni
.NL        Netherlands      sering.cwi.nl
.NO        Norway           ifi.uio.no
.NZ        New Zealand      waikato.ac.nz
.PE        Peru             desco.pe
.PG        New Guinea       ee.unitech.ac.pg
.PH        Philippines
.PK        Pakistan
.PL        Poland
.PR        Puerto Rico      sun386-gauss.pr
.PT        Portugal         ptifm2.ifm.rccn.pt
.PY        Paraguay         ledip.py
.SE        Sweden           sunic.sunet.se
.SG        Singapore        nuscc.nus.sg
.TH        Thailand
.TN        Tunisia          spiky.rsinet.tn
.TR        Turkey
.TT        Trinidad & Tobago
.TW        Taiwan           twnmoe10.edu.tw
.UK        United Kingdom   ess.cs.ucl.ac.uk
.US        United States    isi.edu
.UY        Uruguay          seciu.uy
.VE        Venezuela
.ZA        South Africa     hippo.ru.ac.za
.ZW        Zimbabwe         zimbix.uz.zw

===============================================================================

APPENDIX B:

Basic SMTP Commands

> HELO <hostname>           Tells mail daemon what machine is calling.  This
                            will be determined anyway, so omission doesn't mean
                            anonymity.

> MAIL FROM: <path>         Tells where the mail came from.

> RCPT TO: <path>           Tells where the mail is going.

> DATA                      Command to start transmitting message.

> QUIT                      Quit mail daemon, disconnects socket.

> NOOP                      No Operation -- used for delays.

> HELP                      Gives list of commands -- sometimes disabled.

> VRFY                      Verifies if a path is valid on that machine.

> TICK                      Number of "ticks" from connection to present
                            ("0001" is a typical straight connection).

===============================================================================

APPENDIX C:

BIT-FTP Help File

   ftpmail@decwrl.dec.com (Digital FTP mail server)

   Commands are:
    reply <MAILADDR>              Set reply address since headers are usually
                                  wrong.
    connect [HOST [USER [PASS]]]  Defaults to gatekeeper.dec.com, anonymous.
    ascii                         Files grabbed are printable ASCII.
    binary                        Files grabbed are compressed or tar or both.
    compress                      Compress binaries using Lempel-Ziv encoding.
    compact                       Compress binaries using Huffman encoding.
    uuencode                      Binary files will be mailed in uuencoded
                                  format.
    btoa                          Binary files will be mailed in btoa format.
    ls (or dir) PLACE             Short (long) directory listing.
    get FILE                      Get a file and have it mailed to you.
    quit                          Terminate script, ignore rest of mail message
                                  (use if you have a .signature or are a
                                   VMSMAIL user).

   Notes:
   -> You must give a "connect" command (default host is gatekeeper.dec.com,
      default user is anonymous, default password is your mail address).
   -> Binary files will not be compressed unless "compress" or "compact"
      command is given; use this if at all possible, it helps a lot.
   -> Binary files will always be formatted into printable ASCII with "btoa" or
      "uuencode" (default is "btoa").
   -> All retrieved files will be split into 60KB chunks and mailed.
   -> VMS/DOS/Mac versions of uudecode, atob, compress and compact are
      available, ask your LOCAL wizard about them.
   -> It will take ~1-1/2 day for a request to be processed.  Once the jobs has
      been accepted by the FTP daemon, you'll get a mail stating the fact that
      your job has been accepted and that the result will be mailed to you.
[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]
© Copyleft 1985-2021, Phrack Magazine.