[CLUE-Tech] If you administer a mail server, you might find this useful.

[William]

Something that needs to be said:

popauth3 is *not* a content filter.  It does *not* scan for, or reject UCE that your system has
already permitted.  popauth3 blocks *identified* spammers at the connection level, before *any*
data is transmitted from them, to you (even the envelope).  It accomplishes this by watching log
output from your existing MTA to set up its IP filters.

Here is an example (should I put this on my project website?):
1. Your MTA subscribes to one or more RBL providers.
2. A spammer connects to your server, and your RBL filters reject the connection.
3. popauth3 notes this rejection and records the IP into its own cache.
4. Every time that *same* spammer attempts to connect, popauth3 heads off the connection attempt
before your RBL list is consulted.
5. When the connection attempts from this spammer reach your threshold limits (either in total
connection attempt count, or frequency), that spammer's IP is null-routed for a term you also
specify -- based on which threshold was tripped.

Here is another example:
1. Your MTA may or may not subscribe to RBL providers, but you do have filters set up that prevent
spammers from forging connection/envelope/header data.
2. Any time your MTA rejects messages or connections from spammmers/virii that attempt to forge
their helo/sender/recipient/etc data, popauth3 notes this rejection and records the IP into its
own cache.
3. Every time that *same* spammer attempts to connect, popauth3 heads off the connection attempt
before your RBL list is consulted.
4. When the connection attempts from this spammer reach your threshold limits (either in total
connection attempt count, or frequency), that spammer's IP is null-routed for a term you also
specify -- based on which threshold was tripped.

Here is another example:
1. Your MTA bounces messages that are being sent to fictional addresses on your machine.
2. popauth3 notes the bounce, where it came from, and the nature of it (unknown local part).
3. If the *same* IP attempts to bounce *different* bad e-mail addresses off of you, it tracks the
number and frequency of attempts.  It decides whether this person is attempting to guess local
e-mail addresses.
4. When these attempts reach your thresholds of tolerance, the process results in a null-route as
above.

Does this help explain my approach to anti-UCE and why a log monitoring utility is appropriate for
this solution?  :)

--- Angelo Bertolli <angelo at freeshell.org> wrote:
> > Actually I administer several mail servers and I think that a tool like
> > popauth3 could be useful to fight UCE.  Perhaps you don't have a bunch
> > of remote users who use hotel, dialup, wireless hotspot, or other
> > Internet connections.  As you know mail servers have to restrict somehow
> > mail they accept for relaying.
> >
> > If a mail server accept any old mail for relaying, then the spammers
> > win.
> >
> > If you restrict the relaying to a few IP addresses, then the spammers
> > can't use your mail server as a relay, but neither can your mobile
> > users.
> >
> > If you have a tool like popauth, then the spammers still can't use
> > the mail relay, but your mobile users can.  This is how it fights
> > UCE.
> 
> In the end, I think as long as you keep the spam from getting to the 
> end-user you can win against spammers.  But this is a really difficult 
> thing mostly because the situation isn't the same for all servers (not 
> everyone has the same type of users).  For example, with our users it's 
> more important that they don't miss a valid important email, than it is 
> that their spam is zero.  So spam gets through.  Being on the server-side 
> of the equation, I also feel that it's "safer" (from a responsibility 
> standpoint) to let the mail through and allow the end-user to filter it. 
> But then, when I'm sure I can filter something I will.  For example, our 
> users have no need or desire to send mails with attachments with .exe, 
> .com, .cpl, .scr, etc. extensions, so it's perfectly OK for me to filter 
> out all mails containing those extensions.
> 
> Angelo
> 
> _______________________________________________
> CLUE-Tech mailing list
> Post messages to: CLUE-Tech at clue.denver.co.us
> Unsubscribe or manage your options: http://clue.denver.co.us/mailman/listinfo/clue-tech


=====
William Kimball, Jr.
"Programming is an art form that fights back!"  =)


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/