At 13:02 2004-02-03 +1100, Marvin Pierce wrote:
Shown below is a header from spam that I have started getting. It does
not have my email address in the To:Cc:Bcc fields.
Bcc: isn't a field which should be present on received email. The MSA
supports it for defining recipients, but removes the header when the
message is actually processed.
How am I getting it and more importantly, how do I stop it?
It's being BCC'd to you. If your ISP normally inserts their own
X-Envelope-To: header or somesuch, the reason you're not seeing it is
because MTAs tend not to insert that when there are multiple local recipients.
Return-path: <Kiera_Gorby(_at_)telex(_dot_)com>
Is this consistent across the spams?
Envelope-to: mpierce(_at_)localhost
Received: from [127.0.0.1] (helo=localhost) by libranet with esmtp
(Exim 4.30) id 1AnchC-0003m8-8X for mpierce(_at_)localhost; Mon, 02 Feb 2004
22:56:54 +1100
Received: from mail.optusnet.com.au [211.29.132.250] by localhost with
IMAP (fetchmail-6.2.4) for mpierce(_at_)localhost (single-drop); Mon, 02 Feb
2004 22:56:54 +1100 (EST)
You're _fetching_ the message from your ISP mailbox. This would be
worthwhile to state in your request for assistance. Where is procmail
running - there or on your local host?
Received: from cpe-66-27-193-247.socal.rr.com
(cpe-66-27-193-247.socal.rr.com [66.27.193.247]) by
mail012.syd.optusnet.com.au (8.11.6p2/8.11.6) with SMTP id i12BpvS04539;
Mon, 2 Feb 2004 22:51:59 +1100
Received: from 136.106.206.71 by web237.mail.yahoo.com; Mon, 02 Feb
2004 10:48:53 -0100
This lower Received: header is bogus, and of course, the only reason yahoo
should be involved is if it's coming from a yahoo or related ISP. The
Received header above this is the actual origin - so I'd start by
forwarding the entire message to abuse(_at_)socal(_dot_)rr(_dot_)com (or @rr.com).
Content-Type: multipart/alternative; boundary="--0670296902789068"
X-CS-IP: 148.176.192.110
Is this common to them all, or is this something your ISP inserts? This
doesn't correlate to any of the addresses shown in the received headers.
You could help yourself by identifying which characteristics of the
multiple spams correlate to one another - the IP address, the supposed
sender address, etc. Whichever characteristics are consistent, use those
to filter on.
Obviously, someone is running SpamAssassin (you or your ISP), so perhaps
you could submit the messages to the SA-LEARN facility. That'd be a
SpamAssassin specific thing, so check the SA docs.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail