Date: Wed, 29 Sep 1999 17:58:38 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: freebsd@gndrsh.dnsmgr.net (Rodney W. Grimes) Cc: tlambert@primenet.com, ben@scientia.demon.co.uk, chat@FreeBSD.ORG Subject: Re: Filtering port 25 (was Re: On hub.freebsd.org refusing to talk to dialups) Message-ID: <199909291758.KAA17884@usr06.primenet.com> In-Reply-To: <199909290125.SAA17895@gndrsh.dnsmgr.net> from "Rodney W. Grimes" at Sep 28, 99 06:25:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > SMTP deserves very special attention due to the fact that the number 1 > > > complaint of users of the internet is *SPAM*. SPAM is propogated via > > > smtp. Do I need to say more? I can if I do. > > > > I think you need to block POP3 and "Pine". Most SPAM is propagated > > via either reading it at the ISP, or using POP3 and pulling it down > > nto client machines. > > Ahhh.. wrong side of the problem. It needs to be stopped before it > gets into the users mail box, not on it's way from our server to > thier mail reader. Besides, we don't want to store it either!! Before you download it is topologically equivalent. Your storage argument is really an argument that you have an inefficient storage mechanism, which replicates messages to multiple users, rather than storing the messages once, and then storing per maildrop references. Most mail servers which do this (e.g. Post.Office from Software.COM and Exchange from Microsoft) have rather buggy implementations, since they do not regenerate the local "Received:" timestamp header when the message is being downloaded. This failure means that programs like "fetchmail" can't fan domains agregated in POP3 maildrops back out properly at the final destination. As far as not wanting to transit the mail to the users for user applied filtering rules (e.g. providing filtering as a service, and thereby reducing overall connect time on overcommitted modem pools and other resources), that is an issue of implementing IMSP or ACAP mechanisms for definition of filter rules on a per account basis. Again, since the opt-in or opt-out is a per maildrop question, it is a technology issue. It doesn't matter if you apply the maildrop filter rules by not instantiating a reference, or by deinstantiating it on the way out. No matter how you look at it, it's technically possible to (1) get rid of the storage argument and (2) get rid of the modem transit argument. > > Block them animated GIF banner ads... that'll decrease your overhead. > > No, CACHE the animated GIF banner ads making it look like our pipe to > the internet is much larger than it really is. If I block them I'd > have to modify the AUP, if I make them fast our clients are just a > bunch of happy campers. But they are dynamic content. By definition, you won't get the same data each time. Not that I'd mind a single, cached FreeBSD banner ad, mind you, but I'm sure your own site hosting customers (if you have any) will want _their_ banner ads propagated. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909291758.KAA17884>