Flutter - No Long Receiving Firebase Emails [duplicate] - flutter

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.

Related

Send email from my custom mailgun SMTP address

Sorry if I have not understood something but (I believe) I have searched enough for this.
First things first: I have successfully set up my domain (mydomain.gr) which has been verified.
I have created a custom SMTP address (contact#mydomain.gr).
I have created a route which forwards everything sent at *#mydomain.gr to my personal Gmail address.
Test 1: If I send an email from an external address (something#something.eu) to contact#mydomain.gr it is forwarded to my personal Gmail. OK!
Test 2: If I send from contact#mydomain.gr to any external address (something#something.eu) I get the error Free accounts are for test purposes only. Please upgrade or add the address to authorized recipients in Account Settings. Of course the password is correct while sending. Otherwise another error is raised.
I think I have missunderstood some things...
So here comes my question:
How can I send email from my custom SMTP email address? (I do not wish to upgrade my account since this -free- Mailgun account will handle very small amount of emails. So, 10K are more than enough for me.)
OK. After some emails with the mailgun team I finally figure it out!
All I had to do was to upgrade my account (just enter credit card info). Now I can send email from contact#mydomain.gr to anyone.
Thank you mailgun!
I have also contacted Mailgun for the issue and get response back within few minutes:
This error occurs whenever utilizing either a sandbox domain or a free account without inviting users called Authorized Recipients.
Sandbox domains always require Authorized Recipients. With free plans, which are intended for test usage, all custom domains require Authorized Recipients. With upgraded plans, which are intended for production usage, custom domains no longer require Authorized Recipients.
Please take a look at the following Help Center article for more information about the Authorized Recipient process:
https://help.mailgun.com/hc/en-us/articles/217531258-Authorized-Recipients
Then I have add the Authorize Recipients and it works like a champ!

SendGrid Emails Getting Rejected as Spam

I'm making a user management system for my app, and I need to send users a "forgot my password" email with a token that lets them reset their account password. I signed up for SendGrid through Azure (to get the 25,000 emails per month free, which sounded like a great deal) and wrote some code to use it, but after testing my program a bit I was dismayed to find that only a couple of my emails actually went through.
After going onto the SG control panel, I found that 4 out of the 6 test emails I sent went through, and all of the others were rejected as being spam. I sent an email to mail-tester.com to see what it though my spam score was and it gave me a 4.3/10.
The email in question was a single sentence with a link to the password reset, without any images or other elements. I only sent those 6 emails out, so the volume of my emails definitely wasn't the issue. Still, I'm very puzzled as to why my messages are getting flagged as spam.
Without going to the trouble of making an elaborate authentication setup, are there any basic changes I can make to my system to make it get through to users?
In this case it's most likely because you are sending such a short message, with a link to 'reset your password' from a non-whitelabelled email address (the email address you're sending from cannot be verified against the actual domain), and the link may also be a different URL. It's probably getting pulled up as a potential phishing email.
You can rectify this by white labeling your domain and email links via the SendGrid dashboard, it's easy to do and should improve your deliverability.
Also check out this article from the SendGrid support team about White Labeling.
A question from 2015 which is sadly still relevant today as usage of SendGrid increases.
My organization has blocked all SendGrid mails except for those on the paid tier using fixed IP addresses with resolvable public DNS names (such as sendgrid1.sampledomain.tld) which we then whitelist.
There are now far too many domain impersonation, phishing and other spam mails coming in from SendGrid for us to allow everything from them - roughly 10 000 mails over a seven day period, which is far too many to manually report to SendGrids abuse department.
So my answer would be that switching to the paid tier of SendGrid is the better option if you like a better chance of your mails arriving intact at their destination.
I receive only Spam Mails from Sendgrid.
Goes direct to Spam folder and try to report Sendgrid everywhere I can. Maybe they get blocked by most mail servers and make them think about their policy in "hosting" all these Spammers.
In my case my emails are marked as spam because of the anchor label different to the href being actually called.
And that's because of the 'click tracking' setting of sendgrid.
So, if you have something like
yourdomain.com
sendgrid may replace the href and you end up with something like:
yourdomain.com
The sendgrid page being called tracks the click and then redirects the user to the url you originally set. But this sometimes results in your email being marked as spam.
Try to set 'click tracking' in sendgrid dashboard to off: settings | tracking | click tracking.
details here: https://sendgrid.com/docs/ui/account-and-settings/tracking/
Always start by setting up Domain Authentication, formerly known as domain whitelabel as #MartynDavies says. Found under Settings -> Sender Authentication in the UI. Should look like this:
https://sendgrid.com/docs/ui/account-and-settings/how-to-set-up-domain-authentication/
To identify problems have a look at Activity and choose to see deferred, drops, bounces, blocks and spam reports.
https://app.sendgrid.com/email_activity
Under Suppressions you can see details for Blocks and Bounces among others:
https://app.sendgrid.com/suppressions/blocks
https://app.sendgrid.com/suppressions/bounces
There you can see errors like:
550 5.7.1 SPF check failed. em1234.mydomain.com does not declare 11.222.33.44 as a valid sender
If it says Verified but you see errors like this then contact SendGrid support.
One thing that has worked is to upgrade from the Free plan to Essentials or Bronze via the Azure Portal. This made a lot of the emails marked as spam pass through.
I had a similar issue when trying to send a user verification email using SendGrid.
In my case, using a custom domain as the sender identity solved the issue.
Make sure to also verify the domain before using it.

Cannot send Email Confirmation to certain email providers

I have a Liferay 6.1.0ga1 Portal that requires email confirmation from new registered users.
Following my feedback from the Portal users, and testing with misc Email Providers I've noticed:
Users that use a gmail account for their account, have no problem at all
Hotmail users will receive the 'welcome to our portal' and 'Email confirmation' emails, directly into their junk folder
Yahoo users are receiving most of the sent emails (welcome email, reset pasword, etc) normally, but the email confirmation is never received, and cannot be found even in their Spam Folder. The same happens for every request for a new confirmation mail. In a certain case, the Confirmation email arrived a few hours later, but I cannot really reproduce this scenario.
This is becoming a blocker issue because yahoo users can't register to the portal.
Can anyone provide some ideas on what is causing this behavior, and how could I make sure that all users can receive their confirmation emails ?
Edit:
Could it be that certain email providers are using a strict policy, are blocking the Confirmation Email, because it includes an activation email? I've thought of some solutions like
- Creating a register Hook that informs the new users that they could set their account to accept mails from my Portal
- Creating a hook that will use another Email Template for email confirmation, e.g including the confirmation Token and excluding the activation url
You could take a look at this very old question: How do you make sure email you send programmatically is not automatically marked as spam?
So have you tried the mentioned options in the marked answer there?

How to set from mail address other than smtp authentication mail in java mail

I am specifying "FROM" address usinf setFrom() method, But i still receive mails having "FROM" address of SMTP authentication mail id. and want to set the "FROM" address dynamically. which keeps changing. What is the RFC282 standard to achieve this.
The solution from google is this
Gmail lets you send messages with another of your email addresses listed as the sender instead of your Gmail address. This feature helps you manage multiple accounts from the Gmail interface; it works only if you already own the email account linked to the alternate address
Select the Accounts and Import tab (or Accounts tab, if you're using Google Apps).
Under Send mail as, click Add another email address.
In the 'Email address' field, enter your name and alternate email address.
Choose one of two options:
Use Gmail's servers to send your mail (this is easier to set up)
Use your other email provider's SMTP servers (we recommend this option for professional mail accounts or domains). Note for Google Apps users: Depending on your domain2 type, this feature may be disabled by default. Talk to your administrator if you have any questions.
If you choose to use Gmail's servers:
Click Next Step >> and then click Send Verification. Gmail will send a verification message to your other email address to confirm that you own it.
Open your other account and either click the link in the message Gmail sent or enter the confirmation code in the Accounts section of your Gmail settings.
For more info, follow the below link
https://support.google.com/mail/bin/answer.py?hl=en&answer=22370.
The overhead involved is that any new from address needs a alias to be set in Gamil authentication mail account. Its not suits for enterprise salable app.
Other solution is You can install a mail server (hmailServer). This server allows you to set the custom from address
If any body knows other solutions, please suggest me.
It's up to your mail server. Often mail servers will prevent you from using any From address other than your actual login name. This helps prevent spam. Depending on your mail server, there may be ways to convince it that you should be allowed to use other From addresses.
These are two different things that you are talking about:
The id that you are mentioning is part of smtp handshaking protocol which usually is mapped to "Return-path" field in mime-header.
Whereas the id that comes in "FROM" field which actually is displayed in mail-list is been appended by the mail server when u compose the mail.
So if you can modify the mime header then make sure that "FROM:" field contains the id that yuou want to set not the smtp authentication id.
btw its rfc822
Have worked for rediffmail technical team in order to develop and enhance smtp, pop and imap protocols
Its depends on your mail server and configuration setting

Verifying a user in "Email Submission" use case

I'm building a system that allows people to submit text and photos via email in addition to standard access on the website. I'm trying to weight the security advantages of two strategies in particular for verifying submissions from a user. Here they are as follows:
To based auth: Create a secret email address per user and present this to the user for submission. This strategy has the advantage that people can send from multiple devices that might be setup with different mail accounts
From based auth: Only accept emails from addresses that are registered in the user database. The idea being that it is impractical/difficult to impersonate registered users based on the sending address.
Can you think of other possible solutions? Which strategy of the ones proposed makes the most sense to you?
I would suggest that you not use From based authentication, at least not without some additional credentials (a passphrase, etc)
It's way too easy to forge, and certainly not difficult if you know someone's email address.
If you echo the email back to the user for confirmation, you can make things a little more difficult, but realize that your service can end up being used as a sort of spamming relay. (I could send 100 upload requests to you, with a forged FROM address, and you'd go ahead and spam the real person with 100 confirmation requests)
The better option is to check the registered email address but add the need for a code within the email subject known to the user. This way if they forge the email from address, they would still need a key to authenticate the incoming email.
I would go with "from" + confirmation, to avoid forging.
I.e. receive the email, but send a response with auth token in the subject line (or in the body) back to the "from" address. The user either will need reply, or click a link to confirm the submission.
And you post the content only after confirmation.