I've made small changes in my project's notifications config:
In "Delivery settings" selected "Deliver to email address"
This email address is a distribution list that consists of several members
Now the notification configuration is like this:
However, notifications aren't delivered to this DL.
I'm wondering what may cause this misbehaving? Or I'm doing something wrong?..
There are different reasons for not receiving email notifications:
Email server might be down, unreachable or rejected authentication
Email was delivered to an unchecked folder
Subscription is disabled or opt-out
Event might not be matching with subscription key filter conditions
Subscription is defined to not send emails to the initiator of an event
Organization level do not deliver setting is impacting email delivery
The team or group level do not deliver setting is impacting email delivery
You're not a member of the group or team receiving the email
You're a member of an Azure Directory (AD) group and the subscription contains a #Me clause
You don't have permission to view the event details, which are included in the email
To check each and every condition and to troubleshoot your settings, consider the below link for walk through the procedure.
https://learn.microsoft.com/en-us/azure/devops/notifications/troubleshoot-not-getting-email?view=azure-devops
Related
I am new to firebase and I am trying to handle firebase user authentication in React.js. I did manage to create users with email and passwords. But, now I would like to send the user an Email link to reset their password.
My code currently look like this.
// This line of code belongs to the top
import { auth } from '../firebaseConfig'
//This part goes under the React component
<p onClick={async () => {
try{
await sendPasswordResetEmail(auth, // My Email Id)
alert('Password reset link has been sent to your email')
}
catch(err){
alert(err)
}
}}
>Forgot your Password ?</p>
However, I do not get any error messages and I do get the alert message that says "Password reset link has been sent to your email." Unfortunately, I didn't receive any email. Note that I have given my own email id as the parameter for testing purposes.
firebaser here
Did you check your spam folder? We recently see a lot of the emails from Firebase Authentication ending up in the user's spam folder or being marked as spam in a system along the way. This is being tracked in this status message on the Firebase dashboard and in public issue #253291461.
To reduce the chances of the messages getting marked as spam, consider taking more control of the email delivery yourself.
As a first step, consider using a custom domain with your project. Email that comes from a custom domain has less chance of being marked as span.
As a second step, consider setting up your own SMTP server.) for delivering the email, so that the emails are not being delivered from Firebase's shared infrastructure anymore.
While these steps are more involved, they typically will drastically reduce the cases where the messages from Firebase Authentication are marked as spam.
Full Guide Based on Frank's Answer
Firstly create a new email account you can use to relay the Firebase emails through the SMTP server with. I personally chose Gmail, but I tested with Outlook and it also works.
You can now find an SMTP server host that will work for your scenario. If you're sending less than 1000 emails per month you can find free and reliable hosts. I chose SMTP2GO's free option.
Now you've found the SMTP host, add the email address you've chosen as a single sender email (note that if you do own a domain, you can alternatively use that to send emails).
Note that you will have to verify the email, usually by your host sending a link to the email's inbox. Make sure to check spam.
Once verified, navigate to where you host allows you to add SMTP Users and add a new user. This will allocate an SMTP username and password.
Navigate to the Firebase console, and choose the Authentication option from the sidebar (within the Build product category).
Go to Templates → SMTP Settings and enter the details of your SMTP server. The username and password fields are to be filled with the SMTP user login you created in the step above.
It is better to use TLS, but I believe SSL should work too but it is untested.
Click save, and you're all set up - but there may still be steps to perform depending on your email provider.
Provider Specific Steps
If the emails are being sent to an account managed by Google you will have no issues with your emails being quarantined by anti-spam policies and it will work immediately.
If you are using Outlook, you will have a different problem on your hands. Outlook's built in defender will most likely have auto-quarantined your email under multiple policies - that bit is important.
These policies are likely to be both spam and phish policies. If you unblock one of them, the other will catch it and re-quarantine.
Unblock both policies for the email address, and test. You can see the status of quarantined messages in Microsoft 365 Defender app under Review → Quarantine. Please note that you will need to be an administrator to add global allow policies to your email accounts.
If this still doesn't work it is likely that your company has an additional external filter (as mine did), and you will have to add the IP's manually to the Tenant Allow/Block Lists spoofed senders tab.
One of our managers who is on the team for the project asked how to avoid getting so many emails. Basically, its just myself and another dev that really care anything about getting the email notifications when "something happens". Can I change the default notifications to use just individual email addresses, or do I need to make a new "subscription" in the project settings and then where do I use individual email addresses?
Can I change the default notifications to use just individual email
addresses
The default subscriptions cannot be modified, as Matt pointed out in the comment, you can choose to disable default subscriptions, then new subscription, set delivery to individual email addresses. The email gets sent to multiple custom email addresses, which are separated by semicolons.
But a more convenient way is to set Delivery settings.
Deliver to email address: notifications are delivered to a specific
email address.
A team member without admin rights needs to be notified when WITs are assigned or changed. The login emails for our system is not the same as the work email and assigned to me is the only default option.
Changing the delivery settings and using a custom email doesn't trickle down to the WIT alerts, but works for the rest.
The assigned to field shows ##MyDisplayName## OR [Member] and not sure how to make that reflect the users it needs to go to.
Emails being sent to the wrong addresses.
Select the Custom email address option in the Deliver to drop-down list, then add the mailbox you want to receive the notification in Address field, so that even if the mailbox is not in your organization, the added mailbox will also receive the notification.
I am working in a team, I am admin of Azure devops, and I have a requirement, I want to send a email notification of every pull request created by my developers team.
But problem is that my all developers don't have email domain access in my client's Azure devops.
My mean is my client name for example is ABC so being admin client given me access by giving email id with admin authorization ashishjain#abc.com but developers don't have this mail domains (because we are vendors and working for client). In addition my client don't use full features of office 365.
Challenge is, how can i send a mail notification of every pull request using my client's Azure devops to my developers who don't have mail IDs like abc.com.
When you create a notification you can specify the email address (any email address):
What kind of mail ID do they have to access your Azure DevOps? Even though different from #abc.com, such as xx#123.com, they should also be able to access their own E-mail xx#123.com
To be honestly, your requirement sounds like a little weird. According to your description, every pull request created by my developers team. These users should already been team members in your org.
You just need to Manage notifications for a team or group in your project. For example:
Team preference: use the team's default delivery preference.
Learn how to manage delivery settings.
If those develops are also not able to access their own sign-in E-mail address system. They cloud change their preferred email address for notifications.
You can change your preferred email address for notifications from
your organization preferences profile page. Notifications are sent
by default to the preferred email address for your organization
profile. This is typically the email address you signed into Azure
DevOps Services with.
Besides, you could also set any Custom email address: recipient is the specified email address in delivery options of your team notification.
Lastly, the E-mail which sent to develops notifications will not be the one who created the subscription. It hands by Azure DevOps Server.
Background: I was handed the reins for our company's AWS account to implement a process to make sure our SES delivery report notifications can get acted on instead of just being filed away or deleted.
That said, the first hurdle is that the email address associated with our company's helpdesk keeps receiving all Amazon SES notifications for bounces, complaints and delivery failures. This creates a mess for our support staff in having to wade through these emails individually, and our ticketing system doesn't have the capability of auto-forwarding emails even though I can categorize them based on rules when they arrive.
I have read through all the knowledge base articles for SES notifications as well as ~380 forum topics relating to email notifications, but I didn't see an answer posted this question even though it had been asked a handful of times.
What we've done:
Set up a dedicated email inbox for these requests so we can then process them correctly (that we want to divert these messages to).
Created an SNS topic with the new email address as its endpoint and applied it to all categories, but the emails still kept going to support, so that clearly wasn't the solution.
Removed all hard-coded references to these emails from our software code, but we still get individual Amazon SES notifications to the helpdesk (~30 a day).
Simple idea, but AWS is pretty intimidating especially for our small company where no one has taken the time to learn through the ins and outs after first setting it up (fire and forget).
Edit for clarity, the emails I'm trying to redirect are "Delivery Status Notification (Failure/Delay)" and "Undeliverable:..."
Here's how i got this to work:
Under "AWS SNS"
Create an SNS Topic
Create a subscription to the topic that sends an email to your desired "catch address"
Confirm this subscription by clicking the link sent by AWS to this address
Under "SES Management - Identity Mangement"
Verify a domain or email address
At the domain/email address go to Notification and DISABLE Email Feedback Forwarding
Same place select your SNS topic for Bounces and Complaints
Under "SES Managment - Email Receiving"
Create a Rule set and then create a rule with the domain or email address above
Make the action the SNS rule above
When sending mail be sure that the From address is using the domain/email address above. All bounces and complaints should now end up in the catch address inbox. ALL OF THIS must be setup in the same region.
These notifications are configured either at a verified Domain level or at a verified email address level. This page has info on it. At the bottom, it talks about how you can confirgue to have messages sent to email or a SNS topic. You probably have a notification setup on your domain or the specific email address you are using.
You'll find all this in the SES section of the AWS Console under the Identity Management section. Make sure you check both the Domains area and the Email Addresses area.
You make the feedback address differ from the sender by setting the Return-Path header in your message (subject to a few other rules):
From the developer guide:
If you used the SMTP interface to send the message, then notifications go to the address specified in the MAIL FROM command.
If you used the SendEmail API operation to send the message, then the notifications are delivered according to the following rules:
If you specified the optional ReturnPath parameter in your call to the SendEmail API, then notifications go to that address.
Otherwise, notifications go to the address specified in the required Source parameter of SendEmail.
If you used the SendRawEmail API operation to send the message, then the notifications are delivered according to the following rules:
If you specified a Source parameter in your call to the SendRawEmail API, then notifications go to that address. This is true even if you specified a Return-Path header in the body of the email.
Otherwise, if you specified a Return-Path header in the raw message, then notifications go to that address.
Otherwise, notifications go to the address in the From header of the raw message.