Before answering this, I just discovered the 'Delay Between Recipients' option in the SMTP Service Advanced tab:
"Delay between recipients. Sets a delay (in milliseconds) between recipients within a message for relayed external mail. This prevents spammers from taking all of your CPU time. However, it also makes your server a little slower. The default setting for this option is 0." ... on to the testing. If I run multiple concurrent tests with my script, it appears that this delay halts all connections on the SMTP server, not just the one that is trying to relay? On Fri, 2003-07-11 at 14:48, Len Conrad wrote: > There's all kinds of very difficult nastiness coming from DSL and cable > links these days, even from dial-ups. It you want to protect your server, > block access from "subscriber" IPs, if you can. Compared to our Linux mail servers (mixture of sendmail and exim), we find that IMail does not perform particularly well, so we are already in a state of mollycoddling the server by letting the other mail servers handle incoming mail and delivering to IMail via a static route. If it wasnt for the fact that customers still need access to the authenticated SMTP services directly on the IMail server, we would block any direct SMTP access to it... unfortunately that's not an option at the moment, but I can think of a few ways to pass that on to other servers with a bit of development time. It would require some form of daemon to authenticate against the registry entries. > Imail has to query > > 1) the registry to learn which domains are IMail domains (I bet list could > be kept in memory Yep, as you said in your message, this will probably be done for both local and relay domains. > 2) the ACLs for relay-for-addresses, for deny-IP, etc (potentially too big > for memory) In our particular case, we have relaying switched off completely, except for authenticated users; so this shouldnt take long. > 3) the etc/hosts file to learn which @recipient.domains to relay for. I guess it wont do this in our case either. > >It seems to me that if the domain is not local, then IMail is doing some > >sort of intensive check when a RCPT TO: command is issued. Is there any > >way around this problem? > > That's pretty deep inside SMTPD on a critical code path, only Ipswitch > could answer. There aren't any admins knobs you could twist. I'd be really interested to hear what they have to say about this. I can live with the SMTP RCPT TO: delay for the time being, but something very intensive appears to be going on under the hood. I really dont have the time to attach a debugger to it and find out at the moment... > aka tarpitting. There's not much tarpitting available in Imail. Look in > the IMail u/g "configuring SMTP server". Ah, that's what it's called... as you've seen, I discovered the delay option to implement a basic version of this. > Most MTAs run the SMTPD process at the highest priority, preferring to > receive mail over any other MTA chore (although intelligent MTAs detect > when receiving mail is out of balance with unattempted mail in the queue > and then prefer receiving less). Yep, but in our case, because we're faced with hanging all SMTP connections through the delay option anyway; so the short bursts of processing for the Web interface when necessary would have the same, or lesser effect to SMTP clients, but allow for a more snappy interactive response to browsers. Heh, or a similar DoS to SMTP clients when we find a similar issue with the Web interace executable. Thanks for your response. -- Jon Miles <[EMAIL PROTECTED]> Cybah on IRC(net) To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
