Based on your query, I don't think David's suggest was at all 'holier than
thou'.
And I agree with him , that unless you plan on pushing ALL outbound traffic
from all your Webservers utilizing SMTP scripts,pushes,forms,etc to relay
off your SA Gateway before being pushed to the Internet, I would suggest
EXACTLY what David said.
Enforcing a stronger policy on form code, uploads, Users , a strong TOS, and
reviewing what code is being placed on your servers.
If you are allowing users to upload 'weak formmail script' that is still
YOUR responsibility, and its your IP block that will get listed, not your
users.
Having an outbound spewage detection on smtp emails sent from formmailers,
webservers,etc is going to cause about the same amount of administrative
management cost as it would to enforce a strict TOS, and code review policy,
except the latter won't increase your bandwidth utilization, or put a
heavier load on your mail gateway.
And I won't touch that 'spammer as a user' comment either <g>

-JR


----- Original Message ----- 
From: "David Gibbs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, December 20, 2003 12:51 PM
Subject: Re: [SAtalk] Re: checking outgoing mail


> Jeff Koch wrote:
> > Good grief. What a 'holier than thou' attitude.
>
> Not in the slightest ... you didn't mention you had customers that might
> be spammers (I won't touch that).
>
> Based on your original post, it seemed to me that your primary problem
> wasn't the spam going out, but that people were getting into your system
> and sending spam.  That warrants tightening your security.
>
> > To be more specific we have had cases where user cgi scripts have been
> > subverted into being spam senders. And yes we don't allow FormMail
> > scripts that don't control the recipient list - but occasionally a user
> > will upload a weak formmail script and then
> > we have a potential problem. Or possibly if we end up with a spammer as
> > a user. So I am simply asking if there is a method we can use with qmail
> > to SA check outgoing email and close this possibility.
>
> Now that is a different story ... Although I still don't think setting
> up SA on your outbound email is a good aproach.  Educating your
> customers, enforcing TOS when they violate, and possibly reviewing
> customer code before it's implemented would probably be better (I know
> that could be a major burden ... I'm a Sr. Developer for the company I
> work for and have to review other developers code frequently).
>
> Mind you, I've never run an ISP, and security is not a major concern of
> mine (I'm the only person using my system and [I think] I've locked it
> down fairly well).    I do, however, keep an eye on what my systems are
> doing ... so if they start doing something I don't expect, I can shut it
> down (hasn't happened yet).
>
> Best regards!
>
> david
>
> -- 
> | Internet: [EMAIL PROTECTED]
> | WWW:      http://david.fallingrock.net
> |
> | We're not in the middle of nowhere...
> |   we're on the outskirts of everywhere!
> |
> | - DMRoth (adapted)
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Spamassassin-talk mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
>



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk

Reply via email to