Bug admins do not receive quote notifications

[zfx]

Okay, this is a concern that has arisen from the issue I posted about yesterday which turned out to be an email filtering problem on the recipients' end. So it's unrelated. Or at least it appears so. However, the issue has come to focus because of the very troubleshooting steps performed during yesterday's situation.

The issue is as follows:
For some reason, the administrator accounts on our forum site are currently unable to receive AUT quote email notifications. All other users, including moderators and members of other usergroups are able to receive AUT quote email notifications. Administrator account toplinks quote notifications continue to appear properly.

This issue occurs on each of the two existing administrator accounts. The one that I generally use was able to receive AUT quote notifications up until February of this year. I should mention that the hardware for the dedicated server that hosted our forum site --while the administrator account quote email notifications were working-- had failed and was thus replaced in early March. I migrated the entire file system to a new HDD on a new physical server, seemingly without issue. So I suppose it could be an OS-level permissions matter. If so, I'm yet unsure which files or directories might be responsible.

Note: This issue doesn't appear related to the forum software's usergroup permissions. All of the Dragonbyte Tech AUT permissions for the administrator usergroup are set to 'No' with the exception being "Can Mention Usergroups" which is set to "Yes".

There must be an easy answer to correct this issue. It just seems that finding it is the problem. Any thoughts will be appreciated.

Thanks

EDIT:
I've just checked a few more things and this is clearly not a Dragonbyte AUT issue, much less a bug. While I don't know what's causing the admin account email notification failures, neither vB subscribed threads email notifications nor AUT mention email notifications are working for admin accounts either. I'm unsure when they stopped working because I don't use these email notifications on the admin accounts. The strangest part is that email messages that are manually sent to either of the admin account email addresses via the 'Send Email to Users' CP function or via the email diagnostics test function always immediately arrive at the destination inboxes. Sorry to raise this issue here... I should have tested all of this first.

 

[Fillip H.]

Can you please double check their UserCP settings and ensure that "Receive Emails from Members" and "Receive Emails from Administrators" are both turned on?

For anti-spam compliance purposes this mod does not email people if one or both of those settings are turned off.

 

[zfx]

Can you please double check their UserCP settings and ensure that "Receive Emails from Members" and "Receive Emails from Administrators" are both turned on?

For anti-spam compliance purposes this mod does not email people if one or both of those settings are turned off.

Thanks for the reply.

The 'Receive Email from Administrators' UserCP option is one of the first things I checked and has always been enabled. There is no general 'Receive Emails from Members' option on the UserCP page but the other two email notification options there, 'Receive Friendship Request Email' and 'Receive Email Notification of new Private Messages' are currently enabled as well. So it seems that none of those options are affecting the problem. It's puzzling.

EDIT:
Unless you meant the 'Receive Email from Other Users' setting in the AdminCP User Manager panel under Browsing Options. For what it's worth, that option and the one above it ('Receive Admin Emails') were already set to "Yes". So it's apparently not related to them.

EDIT2:
Through some further testing, I've learned that I was wrong when I stated above that vB thread subscription email notifications also weren't working on the admin accounts. They actually are. What I've just discovered is that a member can't be already subscribed to a thread and simply change the notification type from "control panel only" to "instantly, using email" and expect to be notified via email upon new thread replies from that point forward. If a member changes the account's notification type to "instantly, using email", as it turns out, it as well becomes necessary to remove and replace any existing thread subscriptions in order to make new replies trigger email notifications. So it's just the AUT email notifications that aren't being sent to the administrator email accounts for whatever reason.

 

[Fillip H.]

It doesn't make any sense for the subscriptions to need to be removed and re-added, there must be some deeper issue with your server's ability to deliver mail. All I know is, it's not related to this mod as we use vBulletin's standard email delivery service that all other aspects of vBulletin also uses.

 

[zfx]

It doesn't make any sense for the subscriptions to need to be removed and re-added, there must be some deeper issue with your server's ability to deliver mail. All I know is, it's not related to this mod as we use vBulletin's standard email delivery service that all other aspects of vBulletin also uses.

I guess I don't understand how an issue with the server's smtp mechanism could force a requirement for vB thread subscription status to be cycled before accepting outgoing notifications to the send queue. My basic two questions would be: 1) How can smtp software on a physical server know whether or not separate forum software on the same HDD has toggled on a mail sending option before or after it has added a user thread subscription? And 2) why would it even care? I'm entirely confused about this but I've duplicated it multiple times and found that each vB thread subscription has refused to send thread reply email notifications until the subscription has been cycled by the user after the "instantly, using email" option has been set. And I can't begin to guess whether this strangeness has anything to do with the inability of AUT to send notifications to the admin email addresses. I can easily agree with you that none of it seems to make much sense.

So to summarize, all I am saying is that my testing has shown that both AUT and vB email notifications are in fact sent to non-admin users with no problem, as long as creation of the thread subscriptions follows the switch to "instantly, using email". I can live with that. I'll keep playing with the failed AUT sends to administrator addresses and see if I can learn anything further. I admit that it all seems quite bizarre.

Thanks for the reply.

 

[Fillip H.]

The answer to both of those questions is I have absolutely no idea. There is no logical reason that I can tell for why this should be required. Even if the mail queue was somehow trying to send to the old configuration, it shouldn't affect future emails going forward.

 

[zfx]

I have tested the subscription cycling requirement yet again and the tests have confirmed that the cycling is indeed necessary to cause the vB notification emails to begin being sent. Again, this even works with the admin email accounts, but only for the vB thread reply notifications. And I really have to believe it is by design since when I manually subscribe to a thread I am first prompted with an option screen which presents a drop-down menu showing the last selected subscription notification choice (e.g., "thread notifications by email" or "thread notifications through control panel only). This suggests to me that the subscription notification choice bit is perhaps not set/updated until a subscription is renewed. And the noted behavior seems consistent with that theory.

I'm still trying to learn more about the AUT notification failure on the admin email accounts. What I can tell you now is that each of the two admin email addresses are for accounts on different MTA's residing at different physical locations, and that the servers and mail systems are owned by different organizations - one of them is my own. So there's seemingly no common denominator there. But I think all of that is irrelevant anyway because the admin mail account AUT messages are never even sent by the local system.

I found a way to overcome Gmail's unannounced sudden blocking of SSL/port 465 smtp sends - they didn't seem to respond to my trouble report the other day. I merely changed to a TLS/port 587 config instead, which thus gained back the service. Since the Gmail service is now working again, it's easy enough to log onto the Gmail control panel and view which messages append to the Sent Mail list. None of the AUT notifications that should be sent to our vB site administrator mail addresses ever appear in that Gmail Sent Mail list. All other sent messages from the forum software, however, in fact do appear there (as long as I cycle the subscriptions as described above, that is).

And Fillip H., If my situation is not appropriate to continue posting about here, please let me know and I'll refrain from updating further.

Thanks

 

[Fillip H.]

Do you have a test server somewhere you can set up and re-test this? Somewhere that uses its own MTA, then a separate test instance where you use Google's MTA?

We use Google here and we had no issues with email delivery when making the switch.

 

[zfx]

Do you have a test server somewhere you can set up and re-test this? Somewhere that uses its own MTA, then a separate test instance where you use Google's MTA?

We use Google here and we had no issues with email delivery when making the switch.

Yes, I have a test server and that's an idea. However, my personal Internet connectivity went away on Wednesday and has not returned since. Consequently, I've been relegated to dial-up connections until my new service is installed in a week or two. I've been having trouble with sending and receiving mail while on dial-up, so I'll have to postpone further testing for now.

Thanks for your thoughts.

 

[DragonByte Technologies]

Hello zfx,

This ticket has now been closed with the status Cannot Reproduce.

We hope your issue or question has been addressed to your satisfaction. If not, please feel free to re-open it by clicking this link.

If you have any further issues or questions, please feel free to start a new support ticket via the button at the top of every page.

Thank you!