Sandy wrote: > 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.
Agreed. > 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. You may very well be right but I was under the (false?) impression that if the MTA has AUTH advertising disabled, MUAs would/should not send creds. (Conversely, I realize that an MTA that accepts AUTH without advertising it will respond to an MUA's AUTH request, right?) > 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. Yup. And thanks for your comments; they may not contain metrics in rems of percentage load increase (under various database types) but they do help to shed light on what AUTH entails at the mail server end. Guy -- Guy Isabel <[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/
