Run, don't walk, to a bookstore and get Lincoln Stein's "Network
> Programming with Perl." It will cover at least 80% of what you need to
I have that book, it really is great for people who know about
network/IPC programing and are switching to perl!!
----- Original Message -----
From: "Peter Scott" <[EMAIL PROTECTED]>
To: "Exile" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: "Felix Geerinckx" <[EMAIL PROTECTED]>; "John W. Krahn"
<[EMAIL PROTECTED]>; "Mat Harris" <[EMAIL PROTECTED]>
Sent: Friday, August 23, 2002 5:08 PM
Subject: Re: Where to start ? Listening to a port ...
> At 07:48 AM 8/24/2002 +0800, Exile wrote:
> > > The Win32 system is the one receiving the inbound SMTP connections
> > > containing your mail? That is not the platform I would choose for
> > doing that.
> >
> >Yes. Connie and me are playing on the same SMTP server.
> >This is ours home server, not for my office or hers. So
> >some risky are still affortable, for learn something new. :-)
>
>
> Win32 systems are terrible for developing something like that on. You are
> handicapping yourself.
>
> > > You will have a heck of an easier time doing what you want on a Unix
> > > system if you can get the mail directed there. You will be able to
use
> > > standard daemonizing and connection forking code.
> >
> >Any reference? Are you pointing to the whole system, or SMTP?
>
> Look up "daemon" and "server" on CPAN.
>
> > >
> > > As pointed out, this is an extremely ambitious project nonetheless.
If
> > > you make a good enough start at it, you might get other people
> > > interested in helping if you go about it the right way.
> >
> >I hate spam and I believe everybody does too. ;)
> >
> > >
> > > If you've never written a server, or never used sockets, or don't know
> > > what "fork" or "daemon" mean, I suggest you are taking on more than
you
> > > can handle.
> >
> >I am totally newbie about Perl. But I've welly studied about
S-M-T-Potocal.
> >and I also well known on how to "split" a mail in different parts,
whatever
> >7-bit, base64 etc., unless they are somewhat PGP formatted.
> >
> >I know what daemon and fork are, but have not much idea on how to deal
with
> >this on Perl. I mean, socket programming. Not really much material on
hand
> >I can study about this.
>
> Run, don't walk, to a bookstore and get Lincoln Stein's "Network
> Programming with Perl." It will cover at least 80% of what you need to
> know that's Perl-specific. The hard stuff will be exception handling,
that
> kind of thing.
>
> > > I know those things and I would still not attempt this
> > > task. Instead, I have a .forward on the (Unix) machine that receives
> > > my mail that runs it through a small script I wrote using Mail::Audit
> > > and SpamAssassin that dumps some messages and tags others. I would of
> > > course rather the spam was rejected at connection time but it is not
to be.
> > >
> >
> >I have a plan like this :
> >
> >At the HELO step, try resolving the remote host. If not resolved, Reject.
> >At the envelope header step, if no from (annoymous), Reject.
>
> You will be rejecting messages which are valid non-delivery
> notifications. See the latest comp.risks.
>
> >Looking up those remote host and from (and so on about subject etc). see
> >if they are matched to a sort of blocking list, if matched, Reject.
> >
> >If recipent is unknown.. (no, that's Connie, I mean 550 error), mark down
> >the mail is from who. and counting it, if 550 request from that remote
side
> >reaches 10 times, add it to the reject list.
> >
> >What I mean reject is to throw back a 550 error. I don't know if that's
> >possible to throw 221 and giving a direct cut...
> >
> >I've evaluate that, with this tatic, I can filter out 30% up spams.
> >What actually we planning so far is somthing like that. Any comment?
>
> SpamAssassin filters over 99%. It uses a genetic algorithm to tune its
> heuristics. You ought to use its ruleset for everything after the
connection.
>
> >Is that something like that had existed? Anymore programming reference
> >(not RFC) could you recomment ?
>
> Peter Scott
> [EMAIL PROTECTED]
> http://www.perldebugged.com
>
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
