Skip to main content
Topic: Email notifications are unreliable (Read 1185 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Email notifications are unreliable

For our forum, we have many -let's say- conservative members. They prefer getting email notifications, and replying to topics by email. They simply are not in the habit of logging on to the forum via browser and check for new topics now and then. We took great care of setting up everything related to notifications properly in the user profiles.

Still, I have to notice that the notifications are sent very unpredictable, and not reliable too. What seems to help is to clean the cache from the administrator panel (forum maintenance -> routine). Most of the time, that triggers the email delivery. Needless to state that I am not very happy with this situation as it needs permanent attention of the admin.

For the record:

- ElkArte v1.1.9
- Mail setup: via smtp, having the mail queue enabled

On top of this, there are quite a few mails that are undeliverable, mostly due to some spam issues going on between the smtp server and the receiving end. Although I'm unsure how to help with that, I can accept this as a general obstacle. If only the notifications went out reliably ...

Any hint is highly appreciated!

Re: Email notifications are unreliable

Reply #1

If you can live without the mail queue, turn it off. 

Mail that goes into the queue will not be sent unless there is some traffic on the site to trigger the sending event.  Even bot traffic should trigger the sending.  If there is no traffic, or very sporadic traffic, the queue can take some time to clear.  If you are on your own server running w/o the queue should be fine.  If you are on shared hosting you could be limited by number per hour or per min. 

If you have to run the queue, you might be able to run a cron job that simply fetches the main page of the site with curl or wget, I think that would also trigger the queue.

Mail being rejected is part of the fun with email, especially if you are not sending it through one of the standard providers.  If your server IP lacks "reputation" mail could be rejected.  In those cases you will have to follow the instructions in the rejected email for how to get on a passlist for whatever provider is blocking you (like outlook).  You also must have rdns, dmarc, spf, dkim all properly configured or rejection is sure to await.

Re: Email notifications are unreliable

Reply #2

All good scoop, and.. I discovered that sometimes you just have to contact the recipient and tell them if they want email from you THEY have to contact their own host and request your server to be "whitelisted", hoping the host will be more responsive to their own users than to you as a sender..  and that's even if you can figure out how to contact them.

For example:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

 xxxxxxx@comporium.net
    host comporium-net.mx.av-mx.com [150.136.204.204]
    SMTP error from remote mail server after end of data:
    554 5.7.1 [VI-1] Message blocked due to spam content in the message.
 xxxxxxxxx@northlink.com
    host northlink-com.mx.av-mx.com [150.136.204.204]
    SMTP error from remote mail server after end of data:
    554 5.7.1 [VI-1] Message blocked due to spam content in the message.
 xxxxxxxx@tds.net
    host mx.tds.net [129.159.64.89]
    SMTP error from remote mail server after end of data:
    554 5.7.1 [VI-1] Message blocked due to spam content in the message.
 xxxxxxx@tds.net
    host mx.tds.net [129.159.64.89]
    SMTP error from remote mail server after end of data:
    554 5.7.1 [VI-1] Message blocked due to spam content in the message.
xxxxxxxx@zoominternet.net
    host mx.armstrong.syn-alias.com [193.122.187.19]
    SMTP error from remote mail server after end of data:
    554 5.7.1 [VI-1] Message blocked due to spam content in the message.


In this case, doing an IP lookup those IPs are all actually hosted on the same "data center", and you get to play "who's to blame/who can fix it" ping-pong (with you being the ball) between the data center and the hosted domain owner.  (All of the above are on the same Oracle Data Center in Virginia. They think it's spam because the same message from the same server is hitting their various hosted IPs at the same time).
Last Edit: October 10, 2023, 01:01:18 pm by Steeley

// Deep inside every dilemma lies a solution that involves explosives //

Re: Email notifications are unreliable

Reply #3

Quote from: Spuds – If you can live without the mail queue, turn it off. 

Mail that goes into the queue will not be sent unless there is some traffic on the site to trigger the sending event.  Even bot traffic should trigger the sending.  If there is no traffic, or very sporadic traffic, the queue can take some time to clear.  If you are on your own server running w/o the queue should be fine.  If you are on shared hosting you could be limited by number per hour or per min. 

If you have to run the queue, you might be able to run a cron job that simply fetches the main page of the site with curl or wget, I think that would also trigger the queue.
 ...

Thank you for this explanation! I have deactivated the mail queue now, and will observe to what extent this helps with our problem. A very first quick check looked promising! I will report back here as soon as I have results.

Re: Email notifications are unreliable

Reply #4

Just mail link to the forum and not content for any post.

 

Re: Email notifications are unreliable

Reply #5

After several days of using these settings (without the mail queue), I'm happy to report that it seems to avoid the problem with delayed or missing notifications. There has been decent traffic on our forum, and all the notifications were sent on short notice, without exception. Thanks for this very valuable hint!

Now it's time for me to go through the bounced mails to hopefully help at least with some of them.