Hi Henri - I suspect this makes little difference, but just in case you aren't aware of this, you can run ASSP on a different computer - it doesn't have to be the same system, and so Perl also does not need to be on your XMail system. I'm not certain why you have feelings about running something in front of XMail if it will simply reduce the burden on your server (significantly) but we all have our reasons, I suppose!
If you aren't processing much email, then I can't understand why you are getting the "server too busy" errors you mentioned in your first email. Something doesn't sound quite right. Frankly, even before I was running ASSP, I was processing quite a bit of email (thousands a day, sometimes more, and thousands more a day of SPAM) and I never received an error like that on send. I understood you to say that you were getting SMTP connect errors because XMail was taking too long to refuse invalid users. Logically, if you are receiving server too busy errors simply from refusing emails to non-valid users (as I read your first email to be saying), which would require an incredible volume of invalid email (or a very, very slow server), then the only way to prevent server overload would be to put something in front of XMail, since XMail is already refusing those emails that are causing the problem. But I must have misunderstood given the direction the rest of this thread has taken. If it is simply an issue of SPAM in general, and you need to block it, and you don't want to use something like ASSP (for reasons of purity?), then your best bet is greylisting (as Rob Arends covers well), RBL blocking, and perhaps something like you mention with an automated addition to the spammers list as a last addition. Jeff Henri van Riel wrote: >Hi Jeff, > > > >>You can run ASSP on a different server than XMail. Also, you can >>use it simply to verify that the address being sent to is a valid >>one - it does not need to perform Bayesian -filter based SPAM >>blocking unless you want it to (you could open up the ruleset, or >>you can have it simply tag the email that goes through with >>something if it thinks it's SPAM). If what you need is to be able >>to close sessions to invalid addresses quickly, that is the only way >>I know how to do it. >> >> > >I'll certainly look into it but I don't like the idea of having to run >something in front of XMail... Also, I'd need to install Perl on my >mailserver which is *strictly* a mailserver. > > > >>What you suggest might work, but spammers domains and addresses >>change very rapidly, so I'm not certain you would actually cut down >>the volume much, and you would end up having to process all of that >>email. ASSP will simply terminate the session more or less >>immediately if it doesn't like the email, the sender, or the >>address, or any combination of those things. >> >> > >I don't have to process that much email though. First of all, my new >CustMapsList filters out a lot of spam. If the sender seems ok, XMail >first checks if the recipient is known. If not, it redirects it to my >catch-all account. While it is doing that, the filters.pre-data.tab >filter kicks in *before* the data command, only the headers have >arrived so far. Next, my script will get the ip address from those >headers and exits with code 3 which makes XMail to terminate the >connection. Mail with a valid recipient will still go through the >filter but that's not a problem. > >Sounds to me that it could work! ;) > > > - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
