[EMAIL PROTECTED] wrote:
> Glenn!
>
< With forged headers claiming to be [EMAIL PROTECTED], Glenn wrote:
> >
> > Mafud,
> >
> > I'm not you. Careful examination of the headers will probably
> > identify me, [...]
Mea culpa. If there were more than one PDML subscriber using
my ISP, the headers[*] wouldn't have pinpointed me (but you probably
still would have guessed). There are ways I could have obfuscated
the trail so that you couldn't tell where it came from but would
still be able to tell it was a forgery _if_you_looked_closely_,
but I didn't think I needed to remember how to do that to
demonstrate the point. All I did was telnet to port 25 of
one of my ISP's machines and hand-enter the commands that a mail
program would usually submit to send a message. (If I looked up
the MX record for pdml.net and telnetted to that host directly,
the clues would at least have not been repeated over and over in
the headers.)
I'm pretty sure (though I haven't tried it and probably won't
do so, since I have no particular reason to learn to be good
at forging mail) that I could have actually made the message look
as though it really had come from aol.com, by reconfiguring one
of my home machines to think it was named aol.com.
The thing is, most people don't examine the received-by headers
unless they already have a reason to suspect a message is a
forgery _and_ they know enough about the mail protocols to look
there.
A mail transfer agent (MTA)[**] can be set to try a DNS lookup
on the machine that's handing it a message, which will make
what I did a little harder: it means I'd have to find a machine
not configured that way that's willing to accept the message.
And since I have complete control over the configuration of my
own machines....
I'm not sure exactly how we got onto this tangent. Fortunately
mail forgery is much less common than it was during the flurry
of it on Usenet in the 1980s, so _usually_ a message really did
come from the name on the "From:" line. Other than the occasional
(usually well-labelled) joke posting or examples like mine, all
the forged headers I've seen personally in the past few years
have been from spammers. (Before that, I did see some spam from
a forged address intended not to sell anything, but to get lots
of people mad at the person whose address was shown.)
Is there a way to prevent something this simple? Sort of. If
you use public-key encryption to "sign" *EVERY* message you
send, then you can disavow any message purporting to be from
you that wasn't signed with your private key. (If you only sign
some of your messages, other folks have no way to know whether
an unsigned message is legitimate or not.) Note that you don't
have to send the whole message encrypted; folks not using
compatible encryption tools will still be able to read the
message, just not verify for themselves that it was from you.
Folks who _do_ use such a tool can quickly check the signature.
Would-be forgers would then have to, crack your private key,
break the encryption algorithm (assuming it has a flaw), or
find a way to get access to the machine on which your private
key is stored and copy it from there.
The problem with _that_ approach, is that until you can count
on most people to know about public-key encryption and notice
that every legitimate message from you is signed, there'll be
plenty of people out there who will still believe a forged message
was from you based only on the "From:". (OTOH, you'll be
protected if it comes to proving you didn't send the message
once you find out the message exists.)
Note that despite public key encryption having been easily
available for end-users for quite some time now, most contracts
and such are still signed with a pen and snail-mailed or
faxed because corporate lawyers are uncertain how well a
digital signature will hold up in court. To answer this
problem, some countries are working on legislation to set
standards for digital signatures and explicitly accept them
as valid proof of a sender's identity. (Have any actually
enacted such laws yet? I may be a bit out of date here.)
But I digress.
-- Glenn
[*] I normally don't even see the headers in question. To save
space on my screen, I've set my mail-reading program to only
show me the headers I usually care about: From, Subject, Date,
To, and Cc. (A few others I'm not interested in sneak through,
and I haven't bothered to tweak the configuration to change that,
but you get the idea.) Here are the headers where Tom figured
out it was me:
> Received: (from majordomo@localhost)
> by noc002.aitg.com (8.9.2/8.9.2) id XAA19778
> for pentax-discuss-pdml-list; Tue, 31 Jul 2001 23:49:34 -0400 (EDT)
> Received: from mail1.radix.net (mail1.radix.net [207.192.128.31])
> by noc002.aitg.com (8.9.2/8.9.2) with ESMTP id XAA19774
> for <[EMAIL PROTECTED]>; Tue, 31 Jul 2001 23:49:33 -0400 (EDT)
> Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40])
> by mail1.radix.net (8.9.3/8.9.3) with ESMTP id XAA15882
> for <[EMAIL PROTECTED]>; Tue, 31 Jul 2001 23:49:32 -0400 (EDT)
> Received: from aol.com (ip51.columbia.du.radix.net [207.192.144.51])
> by saltmine.radix.net (8.8.7/8.8.7) with SMTP id XAA02356
> for [EMAIL PROTECTED]; Tue, 31 Jul 2001 23:45:06 -0400 (EDT)
> Message-Id: <[EMAIL PROTECTED]>
With two keystrokes, I can see the full headers on any message.
Disturbingly, there appear to be mail readers out there which
absolutely refuse to show the user most headers at all. Ick.
I believe most mail readers either display the full headers or
have some way to display them on request.
[**] Basically, "mail programs" are thought of as falling into
two categories: a Mail User Agent (MUA) is what most users
think of as a mail program -- a program for reading and sending
mail with a convenient user interface. This can be a real
mail-reader program, or it can be any program that deals with
mail as an extra feature, such as a web browser. A Mail Transfer
Agent is a program used for shuffling mail around the net and
making sure it gets delivered (eventually delivered to a mailbox
where the recipient's MUA can find it). "Sendmail" is the one
that immediately jumps to mind. While a human can interact with
a MTA, as I did to post that forgery, they're really not designed
to be human-friendly. The expectation is that in normal use, what
talks to an MTA is another program -- an MUA or another MTA.
-
This message is from the Pentax-Discuss Mail List. To unsubscribe,
go to http://www.pdml.net and follow the directions. Don't forget to
visit the Pentax Users' Gallery at http://pug.komkon.org .
