Subject: [Asrg] Going to Extremes to Fight Spam

From: "Johan Louwers" <[email-masked]>
Date: Tue, 4 Mar 2003 16:22:20 +0100

Going to Extremes to Fight Spam 

http://www.wired.com/news/technology/0,1282,57867,00.html
Please take a look at wired.com and read about fighting spam. 

I still feel that there is a need of some sort of mechanisme to check if a mail is comming from a known spammer adres. And we also need the checking methode if the user is sending from its own domain and out of its own name.

<snippet>
Return-path: <[email-masked]>
Received: from yoshi[192.168.0.102]
 by yoshi4184.myip.org [192.168.0.103]
 with SMTP (MDaemon.PRO.v5.0.4.R)
 for <[email-masked]>; Tue, 04 Mar 2003 15:46:59 +0100
</snippet>

step 1)
Server recieving e-mail.

step2.1)
check against spam-blacklist-server if 19.168.0.103/yoshi4184.myip.org is a trusted mail relay server.
if not --> drop mail to [email-masked] 

step2.2) (optional)
check against local maintaind spam-server-blacklist if 19.168.0.103/yoshi4184.myip.org is a trusted mail relay server.
if not --> drop mail to [email-masked] 

step 3)
check if 192.168.0.102 is allowd to send in name of @Yoshi4184.MyIP.org
if not --> drop mail to [email-masked] 

step 4)
check if [email-masked] is a correct account at @Yoshi4184.MyIP.org
if not --> drop mail to [email-masked] 

step 5)
if all is ok accept mail.

------------------------------------------------
There are only 10 types of people in the world: 
Those who understand binary and those who don't.

---

From: "David F. Skoll" <[email-masked]>
Date: Tue, 4 Mar 2003 11:00:04 -0500 (EST)

On Tue, 4 Mar 2003, Johan Louwers wrote:

> check against spam-blacklist-server if
> 19.168.0.103/yoshi4184.myip.org is a trusted mail relay server.

Blacklists have lots of problems, as most list readers know.  They
can be overly-broad, or else too narrow.

> check if 192.168.0.102 is allowd to send in name of @Yoshi4184.MyIP.org

This requires extensions such as RMX.

> check if [email-masked] is a correct account at

How do you check this?  For example, Yahoo and all M$ Exchange servers
do not verify recipient addresses at RCPT TO: time.

> if all is ok accept mail.

You need textual analysis somewhere in the mix.  Blacklists are reactive,
overly-broad or too narrow.  Distributed checksum clearinghouses are
easily fooled by small changes to messages.

I'm not saying blacklists and DCC are useless; just that they need to be
used as part of a broad-spectrum approach.

--
David.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Johan Louwers" <[email-masked]>
Date: Tue, 4 Mar 2003 17:33:46 +0100

> can be overly-broad, or else too narrow.

Correct, they can be overly-broad, or else too narrow. On the other hand...
if maintaind correctly and updated like DNS servers you have the option to
access a correct and good updated list. Which organisation would be
responsible of maintaining the list I do not known at this moment and should
be a point of disscusion in this mailling list I think.

Aboute the "too narrow" part, do not forget "step2.2) (optional)" .
Mail admins must have the possibilitie to maintain a local extension to the
list where they can add or exclude blacklisted servers.

> This requires extensions such as RMX.

maybe,.... a ISP knows what range of IP adresses are handed out to the
customers so think aboute a new kind of protocol something like SRCP (Spam
Rejection Control Protocol) where you have the option to check a IP adres
with the relaying server.

> do not verify recipient addresses at RCPT TO: time.

Not the RCPT TO... you should check this as recieving mail server so you
have to check the MAIL FROM with the relaying server to verify that the
account sending the mail exists at that server.... make use of the just
discribed SRCP protocol (Spam Rejection Control Protocol). This check
mechanisme should be part of this protocol.

I think that spam is such a big problem we should not only think aboute
remoddeling existing protocols buth we should also think aboute creating a
new protocol to prevent SPAM. The only problem is that you need the
industrie to get this new protocol up and running with new versions of mail
servers. You also should think aboute a transaction time to update existing
servers and create new versions of mail serversm i think we are talking
aboute a transaction time of 2 to 2.5 years counting from the moment the new
protocol is ready for implementation.

reagrds,
Johan.