sendmail spam

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

References: <tnvyxbbagmdhnapbapbz.goy8hh0.pminews@news1.lig.bellsouth.net> 
From: rodsmith@speaker.rodsbooks.com (Rod Smith)
Subject: Re: Sendmail & SPAM?
Date: Wed, 26 Dec 2001 16:54:01 GMT

In article <tnvyxbbagmdhnapbapbz.goy8hh0.pminews@news1.lig.bellsouth.net>,
        "Gail Koontz" <gail.koontz@quancon.com> writes:
> The following quoted material came from my ISP. I confess to knowing nothing
> about sendmail. Is this sort of thing possible? Is it dangerous or just
> annoying?

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:<foo@nessus.rodsbooks.com>
250 Ok
RCPT TO:<rodsmith@rodsbooks.com>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From:<bogus@bogus.invalid>
To:<nobody@nowhere.invalid>

Message text.
.
250 Ok: queued as 02C492B8D6

The envelope specifies the RCPT TO address as rodsmith@rodsbooks.com (my
true address on the target system), but the header specifies the To:
address as nobody@nowhere.invalid. The message arrived OK. Here's the
header, as revealed by my mail reader:

From foo@nessus.rodsbooks.com  Wed Dec 26 11:16:57 2001
Return-Path: <foo@nessus.rodsbooks.com>
Delivered-To: rodsmith@rodsbooks.com
Received: from nessus.rodsbooks.com (nessus.rodsbooks.com [192.168.1.3])
    by speaker.rodsbooks.com (Postfix) with SMTP id 02C492B8D6
    for <rodsmith@rodsbooks.com>; Wed, 26 Dec 2001 11:16:08 -0500 (EST)
From: <bogus@bogus.invalid>
To: <nobody@nowhere.invalid>
Message-Id: <20011226161609.02C492B8D6@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, rodsmith@rodsbooks.com
http://www.rodsbooks.com
Author of books on Linux & multi-OS configuration
 

Looking for Mac OS X Help?
OS X PDF e-books
Inexpensive, instant download

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.