To reduce CustMapsList processing time, you can, with most of 'big blacklist' mainteners (spamcop, rbl, ..) do local a mirror for the zones in a local dns server, so you could reduce dns traffic dramaticaly and custmaplist response time by saying xmail to use the local dns server.
Note that I never used this setup for local custmaslists, as we have enought bandwidth et power for our current usage. So don't ask me how to do (or at last ressort ;-) ). First check the list maintener web site for instructions ;-) Francis >-----Message d'origine----- >De : [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] la part de Rob Arends >Envoyé : mercredi 15 février 2006 15:07 >À : [email protected] >Objet : [xmail] Re: Spammers - How to block them. > > > >The email response below reminds me of the real causes of your >slow-to-drop >connections. > >> XMail slows down considerably when I use CustMapsList in server.tab. > >The process as I understand it for an email that is to be dropped. > >1. Remote server starts SMTP connection to xMail. >2. xMail looks up IP in CustMapsList. (if found then goto 5) >3. xMail accepts the [Mail from] and [rcpt to] info. >4. xMail looks up the SMTP-MaxErrors, the local users and aliases, and >rejects as needed. (maybe even a predata filter) >5. xMail drops the connection. > >Ok. >Points 1,3,4,5 are all very easy to understand and configure. >After all, >this is what we have been discussing over the last few days. > >Point 2........ >The longer the CustMapsList the longer the delay before xMail >can determine >that the IP was black listed. >xMail will ask each of the RBLs if they have the IP listed, (I >think this >synchronously, but could be in asynchronously). If >synchronously, then the >longer the list of RBLS, the longer before xMail can continue. >Even asynchronously xMail would have to wait for the last one to reply. >Obviously if one of the RBLs returns true, then the process stops >immediately. > >Now even if you don't have a long list of RBLs, the issue >could still be in >this area. >How fast is your DNS server response? >If it times out often or just can't cope, that will lengthen >the time for >the RBL responses to xMail. > >You can see that one SMTP connection starts a dozen other >connections before >the user [rcpt to] is even sent to xMail. Now multiply that by all the >connections you have, and...... You get the picture. > >I can't remember the number of times xMail connection faults have been >reported on this list and they boiled down to DNS issues. > >Please check your DNS response time and potentially reduce the >RBL list, or >put the most likely match as the first RBL listed. > >Get Ethereal and watch your SMTP traffic, you will be amazed >at the amount >of traffic one connection spawns. >It will also give you an idea of your DNS traffic. Remember >to use a hub >(or a switch with a monitor port) to capture the traffic, >unless you run >Ethereal on the xMail server. > >Rob :-) > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On >Behalf Of Henri van Riel >Sent: Wednesday, February 15, 2006 6:19 AM >To: Jeff Buehler >Cc: [email protected] >Subject: [xmail] Re: Spammers - How to block them. > > >Hi Jeff, > >> 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! > >The main reason for not wanting anything installed before >XMail is mainly >because I've been having bad experiences with AVmailGate but >also because >I'd much rather have XMail solve my problem. There must be a >way without >having to install (and maintain) several tools. > >> 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. > >That's odd. How many smtp threads were you running? I've set >the maximum to >16 now where 4 should be enough to handle all incoming mail (easily!). > >> 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. > >The server won't break any speed records, that's true. Still, >it should be >more than good enough for my purposes. XMail slows down >considerably when I >use CustMapsList in server.tab. My guess is that these >services are very >slow and XMail has to check 4 or 5 for each and every email it >receives. I >guess all my smtp threads are busy waiting for a reply from >these anti-spam >services and are unable to allow other connections. Setting >SMTP-RDNSCheck >to "1" in my server.tab also slows down mail processing in XMail. > >> 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. > >It's not the spam per se, I know how to get rid of that. It's >because 99.5% >of all incoming mail is for non-existent recipients. I don't >want to check >them all to see if it's spam or not cause I already >*know* it's spam. I don't want to waste server resources and internet >bandwidth for something I already know I don't want. I just >want to get rid >of those attempts from spammers to deliver spam to my server >as quickly and >as easily as possible. > >-- >Henri. > > >- >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] > > >- >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] > - 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]
