How do I stop this spam?
Scot W. Hetzel
I am using Claus's Anti-Spam & Relay rules to protect my mail servers.
I received some spam in my box that has the from & to addresses the same &
an invalid username. I know why I received the message, because of the
"for" line in the Received header. How do I block this SPAMMER, with out
blocking all the UU.NET users.
Return-Path: <>
Received: from gw0.westbend.net (ns0.westbend.net [207.217.224.193])
by mail.westbend.net (8.8.8/8.8.8) with ESMTP id DAA03918
for <het...@westbend.net>; Sun, 22 Feb 1998 03:22:12 -0600 (CST)
(envelope-from )
Received: from 153.34.196.249 (1Cust121.max30.san-francisco2.ca.ms.uu.net
[153.34.196.249])
by gw0.westbend.net (8.8.8/8.8.8) with SMTP id DAA23394
for <het...@westbend.net>; Sun, 22 Feb 1998 03:22:09 -0600 (CST)
(envelope-from )
Date: Sun, 22 Feb 1998 03:22:09 -0600 (CST)
Message-Id: <1998022209...@gw0.westbend.net>
From: 77447.@gw0.westbend.net
To: 77447.@gw0.westbend.net
Subject: 40 EMAIL ADDRESSES FOR ONLY $39
Thanks,
Scot
Claus Assmann
"Scot W. Hetzel" writes:
> How do I block this SPAMMER, with out
>blocking all the UU.NET users.
>Return-Path: <>
>Received: from 153.34.196.249 (1Cust121.max30.san-francisco2.ca.ms.uu.net
>[153.34.196.249])
>From: 77447.@gw0.westbend.net
The problem here is the use of '<>' as envelope sender.
This address must be accepted according to the RFCs.
So you would have to take a look at the headers, not the
envelope. Three common suggestions are:
a) spamcan
Patch for sendmail, see
http://consult.ml.org/~timb/spamcan/
Spamcan: A Sendmail patch to capture spam by regular expression
b) another patch for sendmail:
http://www.stud.uni-hannover.de/~jk/map-regex/check_header.html
c) procmail
can be used as local delivery agent, includes filter possibilities; see
ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail/
http://www.jazzie.com/ii/internet/procmail/
Another chance might be to block access from UU.NET dialups,
but you would need a list of names/IP-numbers.
Regards,
Claus Assmann
--
[either reply or followup, don't post and mail. thanks.]
<URL: http://www.informatik.uni-kiel.de/%7Eca/ >
Per Hedeland
In article <6csub4$81k$1...@nexus.flensbone.net> "Oliver J. Albrecht"
<o...@nexus.flensbone.net> writes:
>I did some tests this weekend and was wondering if the following
>extensions to check_mail, even though not in line with the RFC's,
>would be appropriate to do the following:
...
>+ local names, empty brackets, users+tokens, incomplete
> hostnames etc. are not allowed from "foreign" (non LocalIP)
> systems
This would mean that your users would never get any bounces from those
systems - per the SMTP spec (RFC 821, 1123) error messages must have an
empty envelope sender, i.e. <> (which is what Claus Aßmann was referring
to earlier). I.e. mis-addressed mail may effectively disappear down a
black hole - this is Bad.
--Per Hedeland
p...@erix.ericsson.se
Andy Harper
> I did some tests this weekend and was wondering if the following
> extensions to check_mail, even though not in line with the RFC's,
> would be appropriate to do the following:
>
> + systems that are in {LocalIP} are allowed to use whatever
> envelope from address they like
> + other systems (obviously not customers) have to provide a
> hostname that doesn't appear in sendmail.cw
All of the above are checked by the checking macro which i announced last
week, and on a client by client basis too (that is, you can make different sets
of checks for different clients). See:
http://www.informatik.uni-kiel.de/%7Eca/email/H/
> + local names, empty brackets, users+tokens, incomplete
> hostnames etc. are not allowed from "foreign" (non LocalIP)
> systems
>
Local names and incomplete hostnames are also checked by my macro. However,
empty brackets <> are part of the standard so it's hard to see how these
could be rejected as invalid.
Regards,
Andy Harper
Kings College London