tissandier
Forum Replies Created
-
Forum: Plugins
In reply to: [Contact Form 7] “Reply To” header not being sentSame issue here.
The “Reply-To” in the Additional headers field in CF7 is now being ignored (stripped out?) by the WP Mail SMTP plugin and not included in the sent email.
- This reply was modified 1 year, 7 months ago by tissandier.
Aha, yes you’re right. Thanks for taking the time to write that explanation.
In the logs I can see that there were two earlier temporary lockouts for the IP in question. So on the third time it tried a permanent ban (which didn’t work because of nginx) and then kept trying a permanent ban over and over again.
So ideally ithemes should have realised the ban wasn’t working and reverted to temporary lockouts, or at least stopped trying to ban the IP.
To stop this happening again I guess I have 3 options:
1) Figure out how to restart nginx every time ithemes makes a change2) Switch to a different security plugin
3) Temporary solution: Set “Blacklist Threshold” to 999 so that ithemes just keeps using lockouts instead of trying to ban.
Any other options?
The iThemes plugin actually did what it is supposed to do.
It’s supposed to send hundreds of identical emails in a 15 minute period?
If the host lockout was working properly then presumably the login attempts would have stopped for 15 minutes, and I should have only received another email if / when the host was unlocked and then locked out again.
Ok thanks for the nginx info, that makes sense. Does the 15 minute host lockout also work by changing nginx.conf, or just the bans?
In this case all the login attempts were from the same IP, trying to login with the same non-existent username (“Administrator”). All the emails had the same content and were sent in the same 15 minute period.
I guess ithemes couldn’t lock out the host because nginx wasn’t reloading the config file, but it kept trying and sent an email each time?
Is there a way to force nginx to reload conf files when they change?
Thanks for your reply.
Server is running nginx 1.6.2
Yes I understand the notifications were in response to a brute force attack. The problem is that hundreds of notifications were sent at once.
Ok I’ve realised the 24 emails per hour thing is because Mandrill only sends 25 emails per hour and puts the rest in a backlog, which it has been slowly trying to clear since yesterday.
So it’s likely that iThemes tried to send all the emails at once.
The question remains why iThemes would send so many notification emails?