John Lee writes:
>Below is a copy of an email I received this morning, and I did not send it
>to myself. Note how it was sent by me to me. I haven't altered it a
>bit...there are no other identifying marks. Does anybody have any idea
>what has happened?
>
>>Delivered-To: [log in to unmask]
>>Date: Tue, Jan 2002 19:38:37
>>From: [log in to unmask]
>...
Of all the Internet protocols, SMTP -- simple mail transfer protocol --
is perhaps the simplest. It's positively ancient, and was designed for a
much simpler time. Like many Internet protocols, it's entirely a
line-oriented text protocol. This means that you can play with it by
using Telnet. If you telnet to port 25 on any machine running an SMTP
server, you're talking directly to the Internet's post office.
The protocol itself is exceedingly simple, with most of what you see
displayed -- the From, To and Subject lines -- coming from the message
body, NOT the protocol. Here's a conversation between me and my email
server (lines I typed are shown preceded by "-->"):
[btoback@landru cris]$ -->telnet landru.optc.com 25
Trying 192.25.138.96...
Connected to landru.optc.com.
Escape character is '^]'.
220 landru.optc.com ESMTP Sendmail 8.10.2/8.10.2;
Tue, 29 Jan 2002 08:37:46 -0700
-->HELO landru.optc.com
250 landru.optc.com Hello
IDENT:[log in to unmask] [192.25.138.96], pleased to meet you
-->MAIL FROM: [log in to unmask]
250 2.1.0 btoback@optc.com... Sender ok
-->RCPT TO: [log in to unmask]
250 2.1.5 info@optc.com... Recipient ok
-->DATA
354 Enter mail, end with "." on a line by itself
-->From: [log in to unmask]
-->To: [log in to unmask]
-->Subject: to no particular scrutiny
-->
-->This is a test message.
-->
-->.
250 2.0.0 g0TFc0O05678 Message accepted for delivery
-->QUIT
221 2.0.0 landru.optc.com closing connection
At this point, the message is transmitted to my inbox.
Let's look at the commands I sent to the server.
1. HELO landru.optc.com
This command begins the conversation with the email server and identifies
me. The hostname that I type isn't checked in any way; it's just as happy
to accept my typing HELO mail.hp.com, for example.
2. MAIL FROM: [log in to unmask]
This command initiates a mail message. This FROM identifier isn't checked
either, except (optionally) to verify that the domain exists. This is a
pretty weak check, since it can easily be forged. Note that this is NOT
the "From:" address you see in the mail message; that comes later.
3. RCPT TO: [log in to unmask]
Now, this is the only thing that matters, because this is the only thing
that the mail server actually has to DO something with. It's the address
to which the message should be routed. If the domain name is something
other than the server's domain, the server will route the mail to the
requested domain (if it's allowed; see below). If the domain name is
local and the recipient name is known to the mail server, the server will
deliver the mail to the recipient's mailbox. But note, this is *not* the
"To:" address you see in an email message; that comes later. There can be
multiple RCPT TO: commands for a single message.
4. DATA
This signifies that I'm about to start sending the message itself. The
message begins with some headers:
-->From: [log in to unmask]
This becomes the user-visible "From:" field in the received message.
Notice that it's not checked in any way. It can be absolutely
anything,
and it can even be omitted.
-->To: [log in to unmask]
This becomes the user-visible "To:" field in the received message.
Again, it has nothing to do with any actual recipient. This is how
BCC messages work: the recipient of the blind copy is given in the
protocol with the RCPT TO: command, and the original recipient
is given in the To: header of the message itself. The mail *server*
does nothing with this line; it's for the user only.
-->Subject: to no scrutiny in particular
This becomes the user-visible "Subject:" field in the received
message.
-->
A blank line ends the headers and begins the message body
What follows is the message body, then a single period on a line by
itself to end the body, and then the command QUIT. You could also enter
another MAIL FROM: command if you had another message to send.
Here's what appeared in my inbox as a result of the above conversation:
>Return-Path: <[log in to unmask]>
>Received: from landru.optc.com (IDENT:[log in to unmask]
>[192.25.138.96])
> by landru.optc.com (8.10.2/8.10.2) with SMTP id g0TFYEO05647
> for [log in to unmask]; Tue, 29 Jan 2002 08:34:38 -0700
>Date: Tue, 29 Jan 2002 08:34:38 -0700
>Message-Id: <[log in to unmask]>
>From: [log in to unmask]
>To: [log in to unmask]
>Subject: to no particular scrutiny
>
>This is a test message.
Notice that the MAIL FROM: address isn't even used, and the only place
the RCPT TO: address shows up is in the server-generated header
("Received:"). Everything that's visible to the user came from the body
of the message.
One other thing: I said earlier that the RCPT TO: address *is* checked.
The answer is that it should be, but sometimes isn't. It should be
checked to make sure that the computer sending the message through the
server is authorized to do so. If your server accepts mail from anywhere
and is willing to route it to anywhere, that's called an "open relay",
and it's what spammers look for in order to send their messages. They do
that because it then appears that their mail came from your site. That's
the reason for the existence of services like ordb.org
(http://www.ordb.org): they let mail administrators reject mail from open
relays, since there's a good chance that it'll be spam.
Here's what happens if I try to send mail through a mail server that's
not my own:
[btoback@landru cris]$ -->telnet utc.edu 25
Trying 192.239.44.6...
Connected to utc.edu.
Escape character is '^]'.
220 cecasun.utc.edu ESMTP Sendmail 8.8.8+Sun/8.8.8;
Tue, 29 Jan 2002 11:09:12 -0500 (EST)
-->HELO www.optc.com
250 cecasun.utc.edu Hello landru.optc.com [192.25.138.96],
pleased to meet you
-->MAIL FROM: [log in to unmask] [I'm lying, but it's not checked]
250 webmaster@utc.edu... Sender ok
-->RCPT TO: [log in to unmask]
551 Relaying denied
-->QUIT
221 cecasun.utc.edu closing connection
Connection closed by foreign host.
Notice that this mail server saw that I was offsite and rejected my
attempt to send mail through it to an offsite host (whitehouse.gov). It's
configured to do that even if I pretend to be part of its domain,
because it checks the IP address from which I've connected. This is a
properly-configured mail server. An improperly-configured mail server
would simply have sent my message -- that's the way it worked in the
pre-Spamford Wallace days.
-- Bruce
--------------------------------------------------------------------------
Bruce Toback Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc. (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142 | But ah, my foes, and oh, my friends -
Phoenix AZ 85028 | It gives a lovely light.
btoback AT optc.com | -- Edna St. Vincent Millay
Mail sent to [log in to unmask] will be inspected for a
fee of US$250. Mailing to said address constitutes agreement to
pay, including collection costs.
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
