Hi Neo,
I want to change my E-mail address, have sent a confirmation mail 3 times - but they do not arrive.
According to our mail server, your SMTP is blocking, hence the problem appears with "mimecast.com"
Note, our logs show your SMTP server has blocked delivery attempts four times to that same address.
Also, FYI only, I checked all the recent deliveries, from our server, and they are mostly all "Delivered".
Not sure if I can search by "blocked status", but so far I can only see that yours are blocked by your server.
I will move all user notification traffic off SendGrid and see if your server blocks gmail as well as sendgrid.
Standby. I need to rebuild the app and flush redis.
Done. Discourse is now sending these user notification emails using gmail v. sendgrid.
After you try again, let me know if you get it this time (not blocked).
I flushed your new email address out of the "queue" so you can start fresh again 
Thanks for your quick answer.
Now I have two times my new address, I clicked on the first one, and now it has worked.
I get other notification mails from community.unix.com. A contents filter? (I hate all this KI-based autocorrection and filtering.)
How do I make the new mail address primary?
I think you need to add your new email address again first; because I flushed it so you could start over and the system only shows your old one.
Hmm, now I have the new mail address twice, once primary and once unconfirmed.
The old mail address is also there (okay, it is still valid for some months).
I guess those duplicates were caused by the fact your new server blocks sendgrid and we were working in near real time and the requests were not flushed from the change request queue.
So, I manually deleted them from the DB just now and all looks ok.
It looks perfect now, thank you Neo for your premium support!
Nevertheless I'll open a (low-prio) ticket with my company...
It was also instructive to me to see that SendGrid, as an SMTP service, is blocked .
However, since SendGrid is often used to send out bulk email, it's not really surprising; so because of this caper, I have moved all user notifications off SendGrid for now; and will just use SendGrid for digests.
I think it is better to keep the user notices emails out of the same SMTP channel as the digests; so this will help other users as well, since we now know "some SMTP server" block SendGrid.
See SendGrid message:
1 Like
I have moved this discussion to the "Discourse" category because Discourse recommends sys admins use these "bulk email providers" for all Discourse messages; and that is the exact reason I created this plugin, so we can put priority email outside of the digest channel:
This "caper" demonstrates why having the Discourse bulk email channel and the main channel, as "one-in-the-same" results in delivery issues for users.
In addition, we often read on Discourse meta (support) where users are not receiving confirmation or email messages.
This situation, now resolved using the plugin above, helps explain it, clearly. Discourse, configured with a single email provider, the same provider which sends digests, will have a problem with email being blocked, just like in this case (now resolved).
The answer from my ticket:
The sender has been reported by users.
The sender can by https://www.spamcop.net/w3m?action=dispute;ip=50.31.63.175
say no to the listing, if it can adequately demonstrate that it is not spam.
Thanks.
This is up to users to deal with their organizational spam filters, etc.
It's not feasible for forum admins to chase all these issues down for users.
Yesterday, was a special case where I did the analysis; but in general, it's not the responsibility of web site admins to chase down all the crazy implementations of spam filters and blocking by the millions of organizations in the world, most of which have very poor system admins working in their shops and overly aggressive and poorly configuration anti-spam software.
My suspicion is that your organization uses a spam filtering/blocking service which filters and blocks everything from SendGrid; and this is simply an ill-conceived way to manage things, in my view; but the person who suffers are users, like @MadeInGermany; who could not change their email address because of this issue.
Basically, I have always said that these types of "black-list" based services are not accurate and very difficult to maintain; and but most organizations do not budget for IT staff who actually understand what they are doing, so they outsource these services to organizations who also do not fully understand what they are doing!
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.