> I know that (from looking at logs), a separate process is spawned > for AUTH, but I have no idea whatsoever regarding how much it > represents in terms of additional resources.
The load is directly related to the database type and the performance of the database connection, which dictate how fast a given session returns from the AUTH routine. The Registry will always be the fastest to return, accelerated by dedicated disk and CPU, an ODBC connection may be acceptable or drag depending on network, hardware, and software issues. I think there's an error of logic going on in this thread suggesting that turning off the requirement for SMTP AUTH on the server side (whether by permissioning through 'Relay for Addresses' or any other means) will prevent clients from sending SMTP AUTH credentials, and thus invoking an internal/external database connection. On the contrary, a mainstream MUA that sees that AUTH is supported, and is already supplied with valid creds, will pass the creds anyway, and IMail will validate them against the database anyway, so the chances of Mahmut's tactics reducing load for those users are slim to nil. As I mentioned a few days ago, if a spammer's MUA is hot-switching between non-AUTH and AUTH in that order, which is the opposite of what normal mail client software will do, this might offer an explanation, but we still don't know how much/any of the traffic on the server is rogue or at least non-standard. It's feasible that a single ill-behaved client is causing a DoS, but only detailed log analysis will show. Some add'l cases, briefly put: - A submitting MUA or MTA that is not configured to use AUTH will still invoke the database connection if the server is configured for 'Relay for Local Users' (less overall computation, however). - If the submitter does not support AUTH and 'Relay for Local Hosts' is selected on the server, the database will not be consulted, but the Registry settings will be hit. - If either 'Relay for Local Users' or 'Relay for Local Hosts' is selected, the accept.txt file will be loaded and parsed. - If 'Relay for Addresses' is selected, the smtpd32.loc file, which is only loaded at service start, will be parsed. - If 'Relay for Anyone' is selected, no settings, database connections, or files need to be consulted. I find it very difficult to believe that the root of this problem is with the shipping SMTPD32 7.07. The EXE or Registry may be corrupt, one of the auxiliary files may be broken (smtpd32.loc, accept.txt), or the database or database connection may be buggy (I still don't know what database(s) are in use, by the way). I'd suggest killing all auxiliary files, DSNs, etc. involved in relaying, as well as troubleshooting network connectivity, controllers, etc. -Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] ------------------------------------ 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/
