Ian Eiloart wrote >> >> --On 26 December 2006 05:53:12 +0000 Monty Ree <[EMAIL PROTECTED]> wrote: >> >> > Hello, list. >> > >> > I have used well SA with procmail well against incoming mail. >> > But there are lots of outgoing spam-mails using web programs or using >> > sendmail at my server. >> > (There are several domains are hosted at the server.) >> > So is there any program like spamassassin which can filter against >> > outgoing spam mail? >> > or any program which can limit sending spam-mail? >> > >> > Please recommend any for me.. >> > >> > my system is linux and sendmail. >> > >> > >> >> Don't use spamassassin for this. That's intended for use when you can't >> police the sender. >> >> First, use a firewall to force web applications to use your mail server, >> and not connect directly to remote mail servers. Otherwise, you can't know >> that you're even seeing all the email.
while I basically agree with you - and this measure will stop misconfigured web applications - there may be a need for direct connect. I am running an email verifier on a shopping website that tries to verify email addresses before customers submit their orders. Before that, I had almost 1% failed email addresses (which would not receive order confirmation, shipping confirmation, ...) >> >> Then, require that web applications use a username and password to connect >> to your host. The PHP class PHPMailer, for example, can do this. That way >> you can trace offenders by checking the sender address. >> The average hosting client will not like to rewrite somebody else's mail script from mail() to something else. With qmail, defining QMAILHOST as the domain name in the apache config ensures that scripts calling mail() use a valid sender I have seen abuse where a mail sending php script was placed into /tmp area and executed. Mails generated from such script would originate from an admin or role account, so checking that such mails only go to specific recipients (and only mails from a valid customer domain are allowed outside) would create an additional line of defense >> Require that sender addresses are not spoofed. That way the real sender >> (well, the web application owner) can be held to account for misdemeanours. >> >> Arrange that copies of emails are sent to you (and maybe the application >> owner), perhaps stripped of the body, or at least notifications. That way, >> you can get early alerts of abuse. You might want to rate-limit the sending >> of email. >> >> -- >> Ian Eiloart >> IT Services, University of Sussex >> One additional suggestion: do not offer your hosting clients any preconfigured script that allows to specify the recipient via the web form. Rather provide a template where they will hardcode the recipient in the script Wolfgang Hamann
