bikefridayadmin

Thanks again for the reply. Tested out 8.6.1 today and the issue did not persist, so it seems like it is solved. The ultimate fix was clearly more than just the workaround code referenced in the GitHub issue.

Thanks for the reply. Unfortunately, as I said, the workaround didn’t work. Reverting did.

I’m sad to say the workaround did not work for me. I hope the code change will have different results.

Actually, I did figure it out. We’re hosted on Rackspace and Mailgun is their product. I’m not sure if they just automatically use Mailgun if you want to do mail through them, but that’s what we had (to be perfectly clear, they use an MTA on the server, but use Mailgun as a relay host). Apparently, we set it up to use the non-production sandbox mode because it has tighter restrictions on quantity of mail, which we were using to prevent the case of some web spider ignoring our robots.txt and trawling our custom product builder, which could generate lots of spurious transactional emails.

The problem lies mostly here, as they made changes to domain verification that required us to add a sending domain (note, however, that Rackspace never alerted us to this fact). Your situation may not be the same, but should be related. Note that only the Rackspace account owner can access the Mailgun settings, which can find instructions about here. Good luck.

Well, yes, now I come to discover we use Mailgun on our server rather than having it on WordPress. Argh. Sorry for bugging you and thanks for the quick response.

4.1.2

Fixed bug in SPAM comment blocking functionality.

Got this update this morning and I can confirm that, at least for my specific case outlined above, the fix does work. Thanks for the quick response!

Glad to hear the fix has been applied. Need someone to test?

If you make any headway on those wishlist items, please keep me up to date.

Thanks again!

Well, I got rid of all the plugins and still had the problem. I was just about ready to throw AIOWPS in the trash when I checked out the Permanent Block List, and there it was!

So, it was blocked by the auto block of comment spam IPs. I looked through the spam comments and found nothing. What I did find is a test comment someone in the building did that I moved to trash.

It would seem to me a bug that AIOWPS thinks that trash = spam. I could kind of see the logic (maybe someone was careless and just trashed their spam), but I think better safe than sorry. Maybe make an option to check if you want trash to be considered spam.

The other thing that comes to mind that I really wish we could have is a non-.htaccess way of whitelisting. And not just for the login page, but EVERYWHERE.

Finally, I would also really like to have a way to globally change where blocked users end up. For example, if it routed them to the main web page, that would be very telling for me, since it would only do that to us if our IP was blocked.

So you get a bug and two wishlist items out of this. Do you want me to formally file those on a tracker anywhere? Let me know how else I can help, because I appreciate your help!

already tried individually disabling rules to no avail. are any of those plugins known to create conflicts with aiowps?

rename login page is enabled. login whitelist is not. remember, no .htaccess.

and yes, by internal network, i mean the internal network at my workplace. no proxy server.

no cache plugin. the following plugins are active:

• Akismet
• All In One SEO Pack
• Contact Form 7 confirm email field
• Contact Form DB
• Contact Form 7
• GA Google Analytics
• Meta Box
• Nimble Portfolio
• OSD Blog Search Widget
• PopUp by Supsystic
• Regenerate Thumbnails
• Revolution Slider
• Screets Chat X
• Shortcodes Ultimate
• Tracking Script Manager
• UpdraftPlus – Backup/Restore
• Velvet Blues Update URLs
• W3 Total Cache
• WordPress Importer
• WP Add Custom CSS
• WP Category Permalink
• WP Customer Reviews
• WP Adverts

we have all sorts of security set up at our workplace, a hardware firewall among them.

regarding ip address, i’m not sure which one you mean but the external ip address at our internal network has not changed and the ip address of the website itself has not changed.

We don’t use .htaccess, so the Login Whitelist doesn’t work. Boo. Thanks for trying, though!

Yeah I could Allow Unlock Requests, but I fear what intrepid spammers might do with that. Not like it isn’t insurmountable, but I’m trying to limit unnecessary strain on the network.

We do have several admins and this trouble user is one of them, so I’m not sure the membership plugin would really fix our issue.

That being said, my request remains. Meanwhile, I’ll continue to put up with it… ?

Thanks for the great plugin.