So Christopher,On 01/15/03 at 16:00, Chris Wagner opined:OK, I know that this is perhaps one of the most or the most talked about subject on this list as far as I've been able to tell at times, but I need some better clarification.1. When someone sends a spam mail, their mail server inserts a time-date stamp (with source IP, etc) in the header and relays the message, yes? (of course, that's obviously able to be forged, but theoretically speaking).Yes, this is true for all messages, not just spam. Each server through which a message passes writes a 'Received' line in the header that includes a time-date stamp, the server's hostname and the hostname/IP address of the host that sent it the message. As you've noted, 'Received' header lines can be forged.2. If that's the case (question #1), and the message gets passed through several hosts before connecting to our SIMS box, can it be that our SIMS box is having trouble identifying what to route to error? (which I see as highly unlikely, since I assume that SIMS routes only what you tell it to). I guess my reason for this question (#2) is I need to know EXACTLY what SIMS does when it receives mail via SMTP and checks the router. Does it do string compares against the router entries to make sure that there's nothing in the header, in particular, the return-path, that is identical?SIMS _only_ checks the Return-Path against the router, and _only_ if 'Verify Return-Paths' is turned on. SIMS does not check anything from the message's SMTP headers. The Return-Path is not part of the headers, it is the sender address from the message's 'envelope'. I.e., it is the address as given in the SMTP 'MAIL FROM' command given by the sending host. It's like the return address on the outside of a snail-mail envelope.3. That said, and if the verify return-path is checked, if others can forge that return-path, then what is the benefit of routing this to error?Return-Path checking is not in and of itself a complete protection against spam, it's simply one more tool for the toolkit. In practice, it may not even be all that effective, since Return-Paths can be arbitrary and/or forged, and do not necessarily have anything to do with the actual sender of a message. However, if you notice a pattern in the Return-Paths of spam that you receive, or for some other reason you're fairly confident that a particular Return-Path will always indicate spam, then by all means route it to error. > 4. How do the spammers forge the source IPs/domains and the return-paths? A message's headers are technically part of the message data, so they can be written at any point in the life of the message. Header lines can be added to a message before the message is ever sent. IP addresses and host names in 'Received' header lines are included in that, so they're trivially easy to forge. Return-Paths are not part of the message headers, but they are equally trivial to forge. They represent the envelope sender (see above) and do not necessarily have anything to do with the 'From' header.5. Anything else anyone can tell me to shed some more light on this subject?-- Christopher Bort | [EMAIL PROTECTED] Webmaster, Global Homes | [EMAIL PROTECTED] <http://www.globalhomes.com/> ############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
That said, is there ANY part of the message header that CAN'T be forged?
I mean, here's a couple of examples of offending spam that I still can't figure out why I'm not able to block them out with the router.
Return-Path: <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
Delivered-To: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Received: from psmtp.com (exprod5mx29.postini.com [64.75.1.184])
by pop.journey.com (Postfix) with SMTP id 8472414FBA
for <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>; Wed, 8 Jan 2003 12:16:10 -0500 (EST)
Received: from source ([209.119.0.109]) by exprod5mx29.postini.com ([64.75.1.245]) with SMTP;
Wed, 08 Jan 2003 09:16:07 PST
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>; Wed, 8 Jan 2003 12:15:25 -0500
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP
release 1.8e) with spool id 32427133 for
<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]; Wed, 8 Jan 2003 12:15:21
-0500
Approved-By: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Received: from 132.200.32.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
TCP; Wed, 8 Jan 2003 12:14:20 -0500
Received: by fed.frb.gov; id MAA29049; Wed, 8 Jan 2003 12:14:19 -0500
Received: from nodnsquery(192.168.3.39) by fed.frb.gov via smap (V5.5) id
xma028394; Wed, 8 Jan 03 12:13:50 -0500
Received: (from uucp@localhost) by ibastion.frb.gov (8.10.2+Sun/8.10.2) id
h08HDoo10516 for <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>; Wed, 8
Jan 2003 12:13:50 -0500 (EST)
Received: from primary(198.35.131.208) by ibastion.frb.gov via csmap (V6.0) id
srcAAAxiayIu; Wed, 8 Jan 03 12:13:50 -0500
Received: from m1pmal01.frb.gov (m1pmal01.frb.gov [172.31.129.146]) by
primary.frb.gov (8.8.8/8.8.8) with ESMTP id MAA24731 for
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>; Wed, 8 Jan 2003 12:13:50
-0500 (EST) (envelope-from <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED])
X-MIMETrack: Serialize by Router on M1PMAL01/BOARD/FRS(Release 5.0.8 |June 18,
2001) at 01/08/2003 12:13:54 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID: <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
Date: Wed, 8 Jan 2003 12:14:02 -0500
Reply-To: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Sender: "F.R. Board Press Releases" <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
From: Federal Reserve Board Notification Mailbox <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
Subject: FR Board: Interagency guidance on credit card account management and loss allowance
To: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Precedence: list
X-pstn-levels: (C:90.6865 M:99.4056 P:95.9108 R:95.9108 S:50.5221 )
X-pstn-settings: 1 (0.1500:0.1500) X-pstn-addresses: from <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
AND:
Return-Path: <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
Delivered-To: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Received: from psmtp.com (exprod5mx57.postini.com [64.75.1.237])
by pop.journey.com (Postfix) with SMTP id 19552143FE
for <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>; Mon, 6 Jan 2003 19:00:20 -0500 (EST)
Received: from source ([63.219.66.114]) by exprod5mx57.postini.com ([64.75.1.245]) with SMTP;
Mon, 06 Jan 2003 17:59:04 CST
Received: (from majordom@localhost)
by mail.iedconline.org (8.9.1a/8.9.1) id OAA12460
for iedcmember-outgoing; Mon, 6 Jan 2003 14:12:40 -0500 (EST)
X-Authentication-Warning: mail.iedconline.org: majordom set sender to <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED] using -f
Reply-To: <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
From: "Jason Christian" <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
To: <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]>
Subject: IEDC One Source - January 6, 2003
Date: Mon, 6 Jan 2003 14:02:42 -0500
Message-ID: <<mailto:02be01c2b5b6$3126d8e0$[EMAIL PROTECTED]>02be01c2b5b6$3126d8e0$[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_NextPart_000_02BF_01C2B58C.4850D0E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Sender: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
Precedence: bulk
X-pstn-levels: (C:99.7951 M:94.5022 P:95.5390 R:95.9108 S: 0.6754 )
X-pstn-settings: 1 (0.1500:0.1500) X-pstn-addresses: from <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> forward (user good)
Now my router entry look like this:
<*@postini.com> = error
*postini.com = error
I guess my certain lack of experience is frustrating me.
I appreciate your patience. :^)
Chris
#############################################################
This message is sent to you because you are subscribed to
the mailing list <[EMAIL PROTECTED]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
