I have been asked to look into why a client is receiving failure
notices for e-mails they are not sending (at least knowingly). An
example failure notice is included at the end. They are running
Sendmail 8.12.10 on Red Hat Linux 9. In /var/log/maillog I see one or
two lines related to the failure e-mail that are:
Jan 20 20:28:44 mansell sendmail[3176]: i0L1Si8f003176: from=<>,
size=7128, class=0, nrcpts=1,
msgid=<200401210128...@merle.siteprotect.com>, proto=ESMTP,
daemon=MTA, relay=merle.siteprotect.com [64.41.120.7]
Jan 20 20:28:45 mansell sendmail[3177]: i0L1Si8f003176:
to=<PCau...@thecompany.net>, delay=00:00:01, xdelay=00:00:00,
mailer=local, pri=37343, dsn=2.0.0, stat=Sent
PCaudill is not a valid user for thecompany.net. I am trying to learn
sendmail so I would like some assistance understanding this log output
to try and determine if someone is using their server for
relaying/sending or if someone is simply spoofing their company in a
return address. It appeared sendmail was configured with relaying
enabled only for specific machines via an access file consisting of:
# Check the /usr/share/doc/sendmail/README.cf file for a description
# of the format of this file. (search for access_db in that file)
# The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc
# package.
#
# by default we allow relaying from localhost...
localhost.localdomain RELAY
localhost RELAY
# Other sites we host
company1.com RELAY
company2.com RELAY
company3.com RELAY
# User 1's machine
xxx.xxx.xxx.xxx RELAY
# User 2's machine
yyy.yyy.yyy.yyy RELAY
127.0.0.1 RELAY
Any help/hints are greatly appreciated!!!
Daryl
*** Failure Notice e-mail:
Date: Tue, 20 Jan 2004 19:28:44 -0600
From: Mail Delivery Subsystem <MAILER...@merle.siteprotect.com>
To: <PCau...@thecompany.net>
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
mansell.thecompany.net
X-Spam-Level: **
X-Spam-Status: No, hits=2.9 required=6.0 tests=BIZ_TLD,HTML_50_60,
HTML_FONTCOLOR_UNKNOWN,HTML_FONT_INVISIBLE,HTML_MESSAGE,NO_FORMS
autolearn=no version=2.60
The original message was received at Tue, 20 Jan 2004 19:28:42 -0600
from D8d4b.d.pppool.de [80.184.141.75]
----- The following addresses had permanent fatal errors -----
<ka...@chambec.com>
(reason: can't create (user) output file)
----- Transcript of session follows -----
procmail: Quota exceeded while writing "/var/spool/mail/chambec"
550 5.0.0 <ka...@chambec.com>... Can't create output
Reporting-MTA: dns; merle.siteprotect.com
Received-From-MTA: DNS; D8d4b.d.pppool.de
Arrival-Date: Tue, 20 Jan 2004 19:28:42 -0600
Final-Recipient: RFC822; ka...@chambec.com
Action: failed
Status: 5.3.0
Diagnostic-Code: X-Unix; 73
Last-Attempt-Date: Tue, 20 Jan 2004 19:28:44 -0600
Return-Path: <PCau...@thecompany.net>
Received: from d8d4b.d.pppool.de (D8d4b.d.pppool.de [80.184.141.75])
by merle.siteprotect.com (8.11.6/8.11.6) with SMTP id
i0L1Sfx05456
for <ka...@chambec.com>; Tue, 20 Jan 2004 19:28:42 -0600
Received: from 126.189.232.66 by 80.184.141.75; Tue, 20 Jan 2004
12:29:19 -0100
Message-ID: <JWNUUIEBQOD...@maestro.ne.jp>
From: "Orlando Beatty" <PCau...@thecompany.net>
Reply-To: "Orlando Beatty" <PCau...@thecompany.net>
To: ka...@chambec.com
Subject: Worldwide Shipping We Got Lots |XANAX| v|aGr@ :Soma: /V/alium
2C8HmuEK
Date: Tue, 20 Jan 2004 09:20:19 -0400
X-Mailer: Earthlink Web Access Mail version 3.0
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--82577701501108770"
X-Priority: 5
X-MSMail-Priority: Low
Content-Type: text/html;
inexpensive rotogravure welfare backplane also
You too can now enjoy the same deep discounts offered to US residents
by ordering your prescriptions directly from us.TZp
Weight Loss: 05wAdipex 5fJBontril cUlDidrex JgFIonamin LX7Phentermine
WtgTenuate DiFXenicalYhk
Muscle Relaxants: sNoCyclobenzaprine IxAFlexerilaUN
Men's Health: rQePropeciaECV
Sexual Health: 4sDViagra gUXViagra ST vnwSuper Viagra (Cialis)
G39Acyclovir XNfValtrexZ9y
Pain Relief: h2YUltram tLtTramadol 9NB
Anti-Depressants: CXaXanax LVZValium 66gProzac sbsBupropion HCL
OBYWellbutrin SRWK8
Sleeping Aids: IhYAmbien BAf
Migraine Relief: x3mFioricet0yk
Anxiety: 9pDBusparDCm
No lengthy forms. All orders filled. We ship worldwide.
Start enjoying discount meds here.UK9
Some simple and heartfelt lay,
Stoop o'er me from above;
A feeling of sadness and longing,
My spirit drank repose;
>I have been asked to look into why a client is receiving failure
>notices for e-mails they are not sending (at least knowingly). An
Somebody is forging sender addresses for spamming. If the spam
bounces, guess where the bounce goes.
> I have been asked to look into why a client is receiving failure
> notices for e-mails they are not sending (at least knowingly). An
> example failure notice is included at the end.
The example included is a common spam. The most likely explanation for
the failure notices is that a spammer has forged your client's email
address as the sender of the spam. This has become tediously common in
the last few months.
You have at least a couple options to deal with it: tell the user to "grin
and bear it," advise them on how to set up client filters so spurious
"failure notices" like this are automatically dumped, and/or set up spam
filtering on the incoming server to dump such messages before they are
delivered to the user.
In any case, it doesn't appear to be a sendmail issue AFAIK, but a spam
issue.
--
-John (JohnTh...@new.rr.com)
You cannot determine that from the above log entry. The thing to look at
is the original message, (hopefully - in this case it was) included in
full in the bounce:
>Return-Path: <PCau...@thecompany.net>
>Received: from d8d4b.d.pppool.de (D8d4b.d.pppool.de [80.184.141.75])
> by merle.siteprotect.com (8.11.6/8.11.6) with SMTP id
>i0L1Sfx05456
> for <ka...@chambec.com>; Tue, 20 Jan 2004 19:28:42 -0600
>Received: from 126.189.232.66 by 80.184.141.75; Tue, 20 Jan 2004
>12:29:19 -0100
Those Received headers are the first stop - if the message was relayed
through your system, it should have added a Received: header. If one is
there, you can further use the queue ID given after "SMTP id" to search
your logs. Doesn't seem like it was relayed through your system from
these.
>Message-ID: <JWNUUIEBQOD...@maestro.ne.jp>
And Message-ID is the next thing to look at - if the message was relayed
throuh your system, the Message-ID should be in your logs (in a msgid=
field). Only you can tell if the above is there.
Note that the Received: headers can be faked, including so as to make it
appear that the message *was* relayed through your system, further that
some systems will strip out Received: headers, and that the Message-ID
is basically arbitrary. The final verdict must always be given by your
logs - if the message was relayed through your system, it must have left
traces there, and above is how to find them.
After doing this investigation, you will probably arrive at the same
conclusion as other followup'ers did wihtout doing it:-) - that the
message just had a spoofed sender address in your domain.
--Per Hedeland
p...@hedeland.org
Thanks to all for taking the time to help shed some light on this subject for me.
Daryl