Is there a b2c sign-up email slow-down today? Taking forever to get email verification ids. Lagging 20+ minutes to deliver, by which time the code has expired.
In Azure, there is no SLA on email delivery. Could be an transient issue as well. As Micah suggested you can post your query in MSDN forum.
Related
We use Google Pub/Sub service for being notified when our users receive emails on their Gmail accounts.
We use the Ruby Gmail client (https://googleapis.dev/ruby/google-api-client/latest/Google/Apis/GmailV1/GmailService.html) for watching the Gmail accounts of our user (connected with OAuth authorisation). We expose an endpoint in our Rails app for getting the posted notifications from Google.
It has worked for years without any problem for more than 1000 Gmail accounts. Since two weeks ago, we stopped receiving notifications for some accounts (I would say around 20).
Each account is re-watched once a day (with stop_user() and then watch_user()), so it's not a problem of expired subscription.
Once a notification is not received for an account when there is a new mail, we never receive a notification anymore until it's re-watched. Then, it works for several minutes/hours and then it's broken again. It always happens for the same accounts.
The quotas page on GCP shows that there is not quotas limit exceeded.
I don't know if it's directly related to the Pub/Sub service or if it's a Gmail issue...
Does someone already experienced the same issue ? How can it be investigated / fixed ?
Thank you in advance for your help !
Rémi
As talked in the comments, this seems to be a bug. Adding it as an answer for visibility purposes. You can click on the star next to the issue number to give more priority to the report and to receive updates.
A bug has been created here on the Google issue tracker : https://issuetracker.google.com/issues/208369302
Is there any configuration present in Azure B2C to limit the number of verification emails ( used for email verification during create account & reset password workflows ) sent to users in a specified time window aka rate limit. We want to prevent malicious actors email bombing our customers with these verification emails.
You can add a retry limit in the selfasserted page if using Custom Policies. It will force the user to be sent back to the app, and they have to try the process again.
setting.retryLimit
https://learn.microsoft.com/en-us/azure/active-directory-b2c/self-asserted-technical-profile#metadata
The service itself has some throttling limits on how many can be sent from a particular IP within a certain timeframe.
I'm facing intermittently delay with polling email messages via Gmail API from GSuite user's inbox. Those calls origin from automatic jobs and use multiple G-Suite users to disperse the work and avoid reaching Quota limits.
However, there are still delay of at least 3 minutes in reading the email. Investigating message email headers showed neither errors (429) or delay time, nor quota limits are being reached.
I examined the push notification method and I'm limited to use it.
Are limit units calculated according to domain rather than per G-Suite user so I'm indeed reach quota?
What else can cause those delays?
The Gmail API has usage limits per method and per user.
Email sending limits are calculated per user per day, not per domain.
Limit units are calculated from all requests made from your application per day
You can check your quota in the Cloud console, choosing your project and API (in this case Gmail).
In my case, I could clearly see the email inside the 'Sent' folder but the recipient had not got any email, so I knew the limits for using the API had not been crossed. It was spam protection taking a ton of time to figure out if the sent email was spam or not. The most common case would be if your emails are all similar with a link in them. I removed the hyperlink in my template email notification and it started working again without any delay.
I would like to implement automatic email notification system for recurring billing in Nodejs. E.g. when subscription is about to expire in 5 days or in 24 hours I want to send an email reminder for a user.
I am using Sendgrid as mailing service. Sending an email is a easy task. Question is what is the best practice for implementing such workflow.
I imagine that cronjob could be setup to run every hour or so.
Script is executed that finds all the users with subscriptions which expires in 5 days or 24 hours. Doing so would lead to sending notification every time cronjob is run. I have to track which users are notified already to avoid duplicated emails.
You should create a cron job for that, like I said in comment, daily. After you find and sent emails you can check sendgrid api to make sure email has been delivered.
https://sendgrid.com/docs/Glossary/deliveries.html
You can also make a web hook to check that
https://sendgrid.com/docs/API_Reference/Webhooks/event.html
the rest of implementation in logic.
I have provisioned a number of accounts to users for my domain.
I need to send out some reminders to inactive users, as information is being delivered to their accounts online, and if they are not logging in, they could be missing the information.
Is there any way for me to retrieve the last logged in time for a user or group of users within a Google App Script framework?
There is no way to get that information for now, you could raise an enhancement request on the issue tracker, the only thing you can get to know is whether or not a domain user has logged in once and agreed the terms of usage