shinerweb

@vcollinzo I had a similar issue in that the update URL was redirecting to the 404 page.
Had me stumped as I hadn’t updated anything other than WP-Hide-Login.
Turned out to be a weird Chrome Cache issue as I could load in Firefox/Safari but not Chrome.
Once I cleared the cache (clearing cookies didn’t help), all was fine. What was confusing was that even in Chrome Incognito it was failing. Chrome has been doing some really weird things with it’s cache of late.
Panic over…

(cheers @mountainguy2 for the reminder to clear down !!)

Basically the ‘bad guys’ are hitting your site looking for those plugins in the hope that you have at least one of them installed.
They’ve probably determined your site is a WordPress site but that’s as much as they know. They then go through all the known vulnerabilities in the hope they find one.
Given that it’s likely the attacks are coming from botnet, if you see repeated attacks from the same IP, you can block that IP for a period. WordFence is protecting you from the known vulnerabilities already.

Unfortunately, you can’t stop these premptive type attacks, but by you can slow them down by removing as many signatures indicating that your site is a WordPress site, but in reality, they’ll eventually find you out.

It’s basically the equivalent of a cold call on the hope they find something…

The CGI-Mailer sounds like you have an old PHP based form installed on your server somewhere if you are getting these to your inbox.

If you are not seeing any transcript errors in your SMTP logs, that suggests they are sending fine.

View the ‘source’ or full email headers of the inbox message, and it might show you the URL of the script (CGI-Mailer) that is doing the sending.
It might also be ‘bounceback’ in that someone else has faked your TO: in an mass email/spam run.

If you want to forward the full email to me at wpforum (at) yaps4u (dot) net, I’ll take a closer look at the mail for you…

Where are you seeing that error?
What are you using to send your email? (Where is the SMTP server you’re connecting to?)

Are you seeing those messages in your log, or are you receiving them in your mailbox?

If I understand you right, you want to be able to send emails from two different addresses on the same domain. Something along the lines of:

[email protected] and [email protected]

You don’t actually need to log into two different SMTP accounts to do the above.
You could for example create [email protected] and use that to send ALL of your emails.
But in the Reply To: field, you set [email protected] and [email protected]

When the email is validated at the receivers end, it’s done using the @yourDomain.com part and not by the actual address.

So long as the domains match in the From: (smtp@) and ReplyTo: (sales@ or general@) then you won’t fall foul of any anti-spam measures.

What I think Yehudah was thinking that you wanted to do was have the ability to log into [email protected] and [email protected] which he is right, would need a heck of a lot of customisation to achieve.

So long as the different addresses you want to use are on the same domain (as you stated in your original post), then doing as I suggest will work. (I do it all the time).

According to the page code, you have the WP Members Widget enabled.

Go to Appearance -> Widgets and remove any Widgets in your theme that you don’t want.
It may also be that as you are using what looks like a single column themed layout, it might be using a ‘default’ widget set. Sometimes, you might have to define your own widget section, but not put anything in it, then it won’t try and use the theme’s default widgets when it detects you haven’t selected any.

However, given that WP Members is a plugin, it’s not likely to be part of a default theme, so I would hazard a guess that you do have the WP Members widget enabled in a widget section somewhere. Just a case of going through that themes widget areas and finding out where it has been included. Shout if you can’t find it still.

hmmm. I’ll have to do a bit more digging. I’d put in the extra line breaks just for ease of displaying them in the ticket. (I have it without in the actual page code).
I did do a little more investigating and I could get all the WPMEM shortcodes to work (as expected) but none of the shortcodes with any other plugins would work.
This site is using the Aviva theme which is new to me so I’m learning any funnies that come with that theme ‘on the fly’. I’ll have a deeper look into the code and have a play on my development server.
It’s more likely my end as I’d have expected more people to yell.
Cheers for the update and I’ll be in touch if I can find any useful info.
Regards
Chris

Have you disabled XML-RPC access? (There’s a simple plugin for that).

As for the point, these are automated comment spam bots that attempt to sign-up, and then leave comment spam (or attack other attack vectors).

They don’t actually visit your site, then find the login form link, click on it.
Basically they grab a list of all domains with WP sites on.
Then they visit https://www.SomeDomain.com/login-link or https://www.SomeDomain.com/XML-RPC interface and automatically try to log in / create an account / leave spam.
Their scripts are too dumb to realise there are steps missing in the process, but they will respond to any accounts that are then authorised.

Another trick to slow them down is to change the wp-admin link to something else.
Most of the automated scripts attacking the site will come in via wp-admin.
(There’s a plugin for that too).
Change it to something not so obvious like yd1-bdadm (Your Domain – Back Door Admin)
You’ll bookmark it anyway so it could even be something random like /wi345hti43ioh
The plugin will also give you a bunch of code to throw in your .htaccess to direct those looking for /wp-admin/ to a 503
It will reduce the traffic load on your site too.

Do you have the contact form setting the reply to field, and POST SMTP setting to “Prevent Plugins and themes from changing this” enabled?
Or, can you set it in the Email Address in POST SMTP?

Or do you have something different in Reply To: field in the Additional Email Address.
(Can you set it there?)

You’ll find those settings in POST SMTP -> Settings -> Message tab

Not a problem and cheers for the quick update.
Not a small task taking on such a well loved (and used) plugin and attempting to bring it back to life. Much appreciated.
FWIW – I didn’t mind the new menu option… don’t care where the menu is all the time it works and is making my life easier… Who spends all their time sat in the WP Admin interface anyway? (Saw that in another thread !!)

The last release added a feature that if an error occurred during the regular sending of an email, the plug-in attempted to use the basic method of sending the email rather than the SMTP settings to at least attempt sending a mail.
It then sends you a transcript of the message to the admin email set for the website.

I’ve also seen a while bunch of these and when checking the mail error logs, can’t see any failures. I’m still getting a transcript of an apparent failure. There are no errors in the php error logs either.

It would be handy if rather than the transcript, the plugin emailed the actual error that occurred as the regular email log should have an entry of the message that we sent. The error email could give the error that occurred and include a reference by way of a link to the that’ll log entry (rather than include the whole of the email).

HTML mails are not being rendered by this new transcript method either which confuses a lot of less experienced users.

I’d also like the ability to switch on/off the fallback operation which could be achieved with a simple “use fallback” flag on the settings panel.

It’s one thing for the plugin to detect an error during sending, but we can’t fix those errors if we don’t know what the actual error was.

Whilst using the fallback means at least an mail was sent, this usually means the message may well be classed as spam at the recipient’s end due to the default method using a different sending method. (Remember, the reason we are using post SMTP is to use an email transport method we have specifically set up with SMTP, DKIM/SPF etc). The default won’t be set up in most if not all setups.

Perhaps another option would be on detection of an error, to have a number of retries attempted. Have a ‘attempt retry on failure’ flag in combination of ‘number of retries to attempt’. Possibly a delay between retries variable too.
This would get round transient errors due to an email server temporarily not being available rather than just acting as if a hard failure.

Some email setups have a throttle to limit sending of emails and will reject any attempt to send an email directly after a previous email. This reduces the chance of a hacked web server from being used to send spam en masse. It might be prudent to have a setting that uses a delay between sending emails sent to the post SMTP plugin to reduce the chance of this happening. Simply adding a delay here might not work as the server could terminate the PHP call due to server limitations. One possible method would be to create a WP cron event to send an email at a set time defined by a ‘delay between sending’ delay value. Basically offload the actual sending of an email to a’thread’ that uses WP cron tasks to the email…

From within the WordPress installation

Go to JetPack in the left hand menu.
Cick Settings
At the top of the page, click the “Dashboard” link (next to the settings link)
Scroll down to the “Connections” section (Below performance).
You should see “Site connection” and “Account Connection”
Under site connections you will see “Manage Site Connection”
Click “Manage Site Connection”
On the panel that pops up, click the red “Disconnect” button.

The original admin can also disconnect JetPack by logging into their wordpress.com account. Selecting the domain under “My Sites” and then going to the plugins section, find Jetpack and click “Disconnect” from there too.

Hope that helps.

• This reply was modified 7 years, 4 months ago by shinerweb.

@fijidance Your error is related to your installation of the Visual Composer, not the W3 Total Cache however, if you log into your hosting package and use your file manager, or connect via FTP to your server, simply remove the Visual Composer folder (within the wp-content/plugins folder). By removing the plugin, WordPress will disable the plugin and your site should come back up. (I’m assuming Visual Composer is a plugin).

If that’s not the case, go to the Visual Composer page and raise a support question there. It might be a known issue between that code and other plugins/themes.

just in case you didn’t see the other post in the group, this was spotted here:

https://www.ads-software.com/support/topic/extra-var_log-statement-outputting-mysql-on-simple-login-log-listing/

There’s a quick edit in the comments that shows you how patch the plugin until it’s updated. (Basically comment out or delete line 568 in /wp-content/plugins/simple-login-log/simple-login-log.php)

It’s most likely that the attacker is running a script which is meant to be doing a bruteforce attack on your site. i.e. it’s trying to use various usernames to log in to your site.
Unfortunately for the bad guy but fortunate for you, they don’t appear to be the sharpest pencil in the box in that their script is either broken, or in they left in the default ‘username’ of {login} in their script. So when it ran, it sent {login} instead of a usual username.
Common usernames certain scripts will try are ones like: {login}, root, rootuser, feed, admin, adminstrator, admin123, test, username, name, domain.tld , domain (where domain is the domain name of the site and TLD is the top level domain (i.e. com, net, uk, etc).

I like to maintain a common list of usernames that these scripts try to use to bruteforce log in and add them to all my WordFence configs.
Immediately any hacker tries to log in using one of these usernames, they are blocked. Use the WordFence options and scroll down to the “Immediately block the IP of users who try to sign in as these usernames” and enter the list of usernames above, one per line).

Along those lines, never use a username of admin or administrator or any other commonly used username as these will most likely be guessed by the attackers. (If they have the username, that’s 50% of their guesswork done, they only need bruteforce the password).