Currently QCIS is working on investigating the possibility of an e-mail
program, which uses the "sendmail" platform (UNIX-based listservers) to send
SPAM-type e-mail messages, which - once accepted by our UNIX- based e-mail
servers, have the ability to erase our subscriber's e-mail address from the
"To:" field of the message. With never-seen-before virii recently being
unleashed on the Internet, we are now beginning to see computer programs,
written for financial gain or to be financially crippling....
---------------------------------------------------------------
Gail Koontz Retired in my home state
836 Mallard Rd. . . . and loving it!
Cocoa, FL 32926 gail....@quancon.com
What precisely do you mean by "this sort of thing?" There are several
"things" mentioned in this message. Perhaps the context of the
paragraphs you've quoted would help, but from what you've quoted, it's
unclear to me why they sent this message, or even if they have a clue
what they're talking about....
> ---------------------------------------------------------------------
> QCIS has received, over the past several months, reports from some of our
> subscribers whereby the subscriber has received a SPAM-type e-mail message
> and the subscriber's e-mail address does NOT appear in the "To:" section of
> the offending message. Our early investigation of this unusual event
This is very easy to do and not at all unusual in spam. It's important
to distinguish between the message envelope and the message headers,
though. The envelope is something that's processed by the mail server,
and it normally contains the true recipient address, but it's stripped
from the message by the time it's received. (The mail server often
pushes this information into headers, though.) The headers are easily
forged, but appear in mail messages. For instance, here's a simple
transaction I performed on my local network:
$ telnet speaker 25
Trying 192.168.1.1...
Connected to speaker.rodsbooks.com (192.168.1.1).
Escape character is '^]'.
220 speaker.rodsbooks.com ESMTP Postfix
HELO nessus.rodsbooks.com
250 speaker.rodsbooks.com
MAIL FROM:<f...@nessus.rodsbooks.com>
250 Ok
RCPT TO:<rods...@rodsbooks.com>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From:<bo...@bogus.invalid>
To:<nob...@nowhere.invalid>
Message text.
.
250 Ok: queued as 02C492B8D6
The envelope specifies the RCPT TO address as rods...@rodsbooks.com (my
true address on the target system), but the header specifies the To:
address as nob...@nowhere.invalid. The message arrived OK. Here's the
header, as revealed by my mail reader:
From f...@nessus.rodsbooks.com Wed Dec 26 11:16:57 2001
Return-Path: <f...@nessus.rodsbooks.com>
Delivered-To: rods...@rodsbooks.com
Received: from nessus.rodsbooks.com (nessus.rodsbooks.com [192.168.1.3])
by speaker.rodsbooks.com (Postfix) with SMTP id 02C492B8D6
for <rods...@rodsbooks.com>; Wed, 26 Dec 2001 11:16:08 -0500 (EST)
From: <bo...@bogus.invalid>
To: <nob...@nowhere.invalid>
Message-Id: <200112261616...@speaker.rodsbooks.com>
Date: Wed, 26 Dec 2001 11:16:09 -0500 (EST)
The MAIL FROM and RCPT TO envelope entries got shoved into the
Return-Path: and Delivered-To: headers, but the From: and To: headers
mirror the bogus From: and To: headers I typed in the test. (In fact,
even the MAIL FROM/Return-Path: header is bogus, although the hostname
is valid on my local network, although not on the Internet at large.)
In sum, the To: header is 100% unreliable in determining the true
recipient(s) of the message. Your ISP should know this, but the comment
that the To: header not matching the true recipient is "unusual"
suggests that they don't.
> lead us
> to believe that these types of messages were distributed by a listserver,
> which collected (by either buying and/or copying our subscriber's e-mail
> addresses from one or ore sources) our subscriber's e-mail address.
Using listservers and hijacking mailing lists are both common tactics
used by spammers, but the fact that the To: header was bogus doesn't
lead logically to this conclusion. I used Telnet to generate the bogus
To: header in the preceding example, for instance. There's plenty of
specialized spam software (often called "spamware") that'll do this, as
well.
> Currently QCIS is working on investigating the possibility of an e-mail
> program, which uses the "sendmail" platform (UNIX-based listservers) to send
> SPAM-type e-mail messages, which - once accepted by our UNIX- based e-mail
> servers, have the ability to erase our subscriber's e-mail address from the
> "To:" field of the message.
It's possible that a spammer is using sendmail or a modified version of
sendmail to do this, and it's even possible that the ISP has evidence
of this. If so, it's certainly not cause for concern about your own
local copy of sendmail, though; it's the SPAMMER'S copy of sendmail
that's sending the spam -- or at least, you've presented no evidence
that your own sendmail has been in any way compromised. (Spammers do
sometimes hijack misconfigured mail servers, known as "open relays," to
send their spam, but the message you've quoted doesn't explicitly
mention this possibility.)
> With never-seen-before virii recently being
> unleashed on the Internet, we are now beginning to see computer programs,
> written for financial gain or to be financially crippling....
True, but this has been true for a long time, and I'm not sure how it
fits in with the previous statements.
In sum, this message from your ISP is at best confusing for lack of
context. At worst, it reveals a serious misunderstanding of how SMTP
e-mail works on the part of the writer. In neither case does it mean
that you need to modify your Linux configuration.
That said, though, e-mail server configuration *IS* a real concern for
anybody who runs one. You should keep up with security updates (I don't
know of any recent ones for sendmail, but I've not been following it
all that closely), and if your server is accessible from the outside
world, ensure that it's not configured as an open relay. (See
http://mail-abuse.org/tsi/ for more on this issue. AFAIK, all recent
Linux distributions ship with mail servers that are configured to NOT
function as open relays.)
--
Rod Smith, rods...@rodsbooks.com
http://www.rodsbooks.com
Author of books on Linux & multi-OS configuration