Server setup impacting emails?

rockinaway

So I recently moved my WordPress setup to RunCloud + VultrHF.

I have MemberPress on WordPress which sends out emails when users register/upgrade their subscriptions on my website. This isn't cron-based but occurs immediately when the user actions this. I've noticed, since moving setup, that emails are delayed quite a bit (sometimes 10 minutes) from when the action occurs.

All my cache settings are exactly the same as they were before moving (when emails were sending absolutely fine).

I'm wondering if it's something in my server setup that's slowing the emails down? Any advice?

nqservices

You should try to enable WordPress manual cron. Depending on your needs you can set it to run every 1 minute or every 5 minutes.

rockinaway

I have a WordPress server-side cron setup already. However, as stated in the first post, these emails aren't cron based. They are meant to be immediately triggered when an action is taken and on my previous host, they were instantaneous...

chip

@rockinaway said:
I have a WordPress server-side cron setup already. However, as stated in the first post, these emails aren't cron based. They are meant to be immediately triggered when an action is taken and on my previous host, they were instantaneous...

Are they being graylisted? .. .do they appear in mail queue?

What does exim/postfix logs say?

jar

Well 40-50% of email goes to Gmail, with the next percentage being far lower, meaning the likelihood that this is being tested against Gmail is high.

Gmail somewhat frequently has internal delays and will often accept an email 10-30 minutes before delivering it due to internal issues. You can usually see if this is true by following the Received headers and determining where any gap in time was (ex. between X and Y servers, usually internal ones owned by Google).

If it isn't that, then it's going to matter how you're sending the emails. SMTP? PHP mail function? Is any of this being logged to a local MTA you can review logs for?

Also, are you testing this by waiting for the email to come in via POP3 import at Gmail? Because this is often a source of delays, as those checks kick off on intervals and not in real time.

I know my reply kind of went all over the place, but that's email for you. Describe one problem with one sentence and I'll have at least 3 relatively common scenarios that I associate with matching language.

Chievo

@jar said:
Well 40-50% of email goes to Gmail, with the next percentage being far lower, meaning the likelihood that this is being tested against Gmail is high.

Gmail somewhat frequently has internal delays and will often accept an email 10-30 minutes before delivering it due to internal issues. You can usually see if this is true by following the Received headers and determining where any gap in time was (ex. between X and Y servers, usually internal ones owned by Google).

If it isn't that, then it's going to matter how you're sending the emails. SMTP? PHP mail function? Is any of this being logged to a local MTA you can review logs for?

Also, are you testing this by waiting for the email to come in via POP3 import at Gmail? Because this is often a source of delays, as those checks kick off on intervals and not in real time.

I know my reply kind of went all over the place, but that's email for you. Describe one problem with one sentence and I'll have at least 3 relatively common scenarios that I associate with matching language.

The email king is present !!!!! Maildzilla

rockinaway

@jar said:
Well 40-50% of email goes to Gmail, with the next percentage being far lower, meaning the likelihood that this is being tested against Gmail is high.

Gmail somewhat frequently has internal delays and will often accept an email 10-30 minutes before delivering it due to internal issues. You can usually see if this is true by following the Received headers and determining where any gap in time was (ex. between X and Y servers, usually internal ones owned by Google).

If it isn't that, then it's going to matter how you're sending the emails. SMTP? PHP mail function? Is any of this being logged to a local MTA you can review logs for?

Also, are you testing this by waiting for the email to come in via POP3 import at Gmail? Because this is often a source of delays, as those checks kick off on intervals and not in real time.

I know my reply kind of went all over the place, but that's email for you. Describe one problem with one sentence and I'll have at least 3 relatively common scenarios that I associate with matching language.

I'll just try to gather my brain cells...

So you're right, I am looking at Gmail as my admin accounts are hosted on Gmail and receive the emails when users register. I've check the headers and can't see any delays.

I'm using SMTP via Gmail for my emails on WordPress. It's just strange that I haven't really changed anything aside from server and suddenly this has happened.

I need to figure out how to check my postfix logs and things. As I understand it, greylisting would only impact mail my server is receiving, not sending?

jar

@rockinaway said: I'm using SMTP via Gmail for my emails on WordPress. It's just strange that I haven't really changed anything aside from server and suddenly this has happened.

That should be a good setup then, it should be something that either works or doesn't inherently, very little statistical room for a problem with that setup specifically. So I feel comfortable saying that's a solid setup.

I posted a lot more and then realized I'm stupid, none of it applies because you're sending from Gmail to Gmail. So in this case, I think debugging the PHP during these events may actually be where you find the most value.

rockinaway

I've looked in to it further and it seems to only be with a certain plugin in WordPress but they say it's not a plugins issue. It's like the emails are being timed with the cron but in the code they aren't controlled by the cron so it's impossible they are related so I have no idea what's stopping them :') It's madness trying to figure this out!

rockinaway

The issue has been resolved and it was a sneaky plugin issue - my server sanity (just about) remains! Thanks for everyone's help!

Arkas

@rockinaway said: The issue has been resolved and it was a sneaky plugin issue

Nothing to do with the coincidental server move?