Forums & Blog

When attempting to use SOAP calls to work with the SmarterMail API, I get the following message returned by the WebService:

"You have already attempted to log in too many times within a short period. You must wait a set amount of time before trying again. If you require assistance, please contact your email administrator."

 The ResultCode is: -20

I got this message the very first time I tried communicating with the API. I waited for a good 30 minutes before trying again and got the same result. Debugging the soap class shows that it DOES successfully connect to and query the API and it indeed does receive this response. 

Any ideas? Thanks in advance. 

Update: Waited an hour or so.... it worked one time. It took a good 45+ seconds to return (returned false only) and then immediately went back to disallowing any further queries. I assume there is a config setting somewhere to control this, but I can't seem to find it... any ideas?

Another Update...

It appears my previous update was a fluke. I believe it timed out during that attempt. I have waited almost four hours and am still getting the same error.

I have full logging enabled on the site instance that's hosting these web services and I am the ONLY person attempting to access the /Services directory.

I have tried removing all references to preventing brute force within the web.config files as well. Even with those directives included, I still shouldn't be locked out on brute force suspicion indefinitely.  The default was 100 attempts and a 5 minute lockout.

 ANY ideas at all are greatly appreciated as I'm tearing my hair out over here. :)

Alright, this is clearly not an issue of too many login attempts in a short time period, as I have waited over 8 hours and still cannot get through. IIS logs still show ONLY ME as the single IP trying to access these services. 

With the user/pass I'm sending, I can still log in to webmail just fine. 

This is looking more and more like a configuration problem on my side. I just tried using a bogus AuthUserName and AuthPassword and I get the same exact error message. That seems to suggest something NON-account-specific, which seems to suggest configuration. 

Clearly these web services work, so this has got to be something on my end.

It would be really nice to know from ST though, if the error message I'm getting ("You have already attempted to log in too many times within a short period. You must wait a set amount of time before trying again. If you require assistance, please contact your email administrator.") is actually a message internal to ST, or if it's something else entirely.

Anyone have any ideas at all, or can you point me in the right direction?

Hey eping,

 Take a look at your web.config for the Webmail, especially the Login.BruteForceDetection.BlockTime appKey. The default setting should be 5. You also may need to restart IIS in order to flush the webmail application cache. You can do this from a command prompt by running 'iisreset -noforce' keep in mind that this will disconnect all webmail users and force them to login again...

E 

That message is from SmarterMail's Brute Force detection. As mentioned, make sure your web.config has sane values for:

    <add key="Login.BruteForceDetection.TriesBeforeBlock" value="10"/>
    <add key="Login.BruteForceDetection.BlockTime" value="5"/>

That means that 10 failed logins will cause the IP to be blocked for 5 minutes.

I will look it over again, but I have already messed with these settings.  I have made the modifications both in the IIS panel and directly in the web.config file.  I have even removed the directives completely, but to no avail.

The original setting was 1000/5, and as I said, I am the only IP accessing the web services according to my IIS logs.

Confirmed... I had been trying 10000 but I still get denied every time. Even at 100000 I am denied. 

Even with a full server restart, I still only get this message.

I have solved the problem.

Despite the apparent login failure, brute force denial has absolutely nothing to do with this. It turned out to be a malformed request. I guess the SmarterMail API couldn't understand the format, but rather than produce a Bad Request error like it does with most bad requests, it decided to continue processing and produced that strange login error.

Part of the problem is this deployment required me to code the service call in PHP using a third-party SOAP module. I will post in these forums a little later with a tutorial on how to make PHP work with the API now that I have figured it out.

 Can you please tell how did you solve the problem?

I am facing the same issue... :(