Andy, I should have mentioned in my first response that the help has been updated to properly describe the actions that take place.
If the Max Invalid Recipients is set, it only looks at the recipients. The Soft and Hard error settings look at all errors. Therefore, the Hard Error Limit could actually fire if it is higher than the Max Invalid Recipients settings. As far as the UI is concerned, I agree 100%. We are implementing a more user friendly and accurate UI for these settings for the 10.5 release scheduled for later this year. As far as the white list issue, we are looking at this and it will be addressed for the next release. Unfortunately, we are too close to the 10.01 release for any more changes to be added. Thanks, Tom Lewis Ipswitch, Inc. Development Manager - Messaging Products 706-312-3573 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: Tuesday, July 01, 2008 8:56 AM To: Imail_Forum@list.ipswitch.com Subject: RE: [IMail Forum] V10 - Dictionary Attack defense no longer functional -> confirmed! Dear Tom: Thank you for posting an update to this issue. Your progress report is much appreciated. Allow me a few constructive comments with respect to your documentation AND to your settings screen. If those were corrected, this entire feature would become much more obvious to the admins (and even your support staff). a) The online documentation (= help) does not match with the explanation you provided. It states: "Max Invalid Recipients Per Session. Enter the maximum number of invalid recipients the server will accept before the session is dropped AND the IP address of the sender is added to the Control Access table." As you can see, it clearly implies to the reader that the Max Invalid Recipients Per Session will ALSO add IP addresses to the access list (and then leave the reader wondering about the meaning of the other "limit" settings. b) If the "Soft Error Limit" relates to the "Error Delay" and the "Hard Error Limit" relates to the "Deny Access", then I think at minimum the ORDER and CONSISTENT TERMINOLOGY of the related fields in your admin screen should reflect that. Right now, the naming and ordering of these fields implies NO relation between ANY of them! An improved "user interface design" would fix that, e.g.: Max Invalid Recipients per Session: 4 Errors Before Responses are Delayed: 2 Seconds Delay: 10 Errors Before Denying Access: 5 Minutes to Deny Access: 5 c) Even with your clarification, the effect of combining some of these values remains questionable: If I define Max Invalid Recipients = 3 but Hard Error Limit = 4, then the connection is dropped after 3 bad recipients - so that means it could never ever reach the Hard Error Limit, so that setting is entirely irrelevant? Clearly not what the user intended! If I define Max Invalid Recipients = 4 but Hard Error Limit = 3, then (according to the manual), the IP is added to the deny list AND the connection is ALSO dropped. So it never reaches the Max Recipients = 4 limit, thus this setting is irrelevant. In other words, it appears as if these two settings are mutually exclusive. And the same is true with the "Soft Error Limit". If this is defined LARGER than the Max Invalid Recipients or Hard Error limit, then it is entirely ineffective, because the connection will be dropped BEFORE it ever gets a chance to delay recipients? If all these settings work as documents/explained, then a well thought-out User Interface would put the options in the order they take effect, use "additional errors" to enforce that one limit is less than the other, AND use checkboxes to show which settings occur together: Session Limits for Max Invalid Recipients Error Limit Before Delaying Responses: 2 Seconds Delay: 10 Additional Errors Before Disconnecting: 4 Deny Further Access When Disconnecting: [X] Minutes to Deny Access: 5 The above options would have the same effect as soft error = 2, hard error = 2+4= 6. It also prevents that "max recipients" could be defined LESS than soft errors or hard errors, and it prevents that hard errors being defined as less than the other two settings. d) Your mention of fixes in the next update, didn't address the situation that adding an IP address to the IP WHITELIST does NOT prevent it from being automatically added to the the DENY ACCESS LIST - which defeats the purpose of a WHITELIST? Best Regards, Andy Schmidt To Unsubscribe: http://imailserver.com/support/discussion_list/ List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://imailserver.com/support/kb.html To Unsubscribe: http://imailserver.com/support/discussion_list/ List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://imailserver.com/support/kb.html
