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]>
