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: xmail@xmailserver.org 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]
