I haven't been able to find an answer to this, so forgive me if it's been asked somewhere before.
I'm working with non-profit who has a google workspace for non profits account. I'm working on getting our SPF/DKIM/DMARC records set up, and they work perfectly except for one situation.
We have two different domains, whedoncon.com, and thehellmouth.org. Some of our users have an email on both domains (i.e. user#whedoncon.com and user#thehellmouth.org are going to the same person). I can send emails individually from each domain, and they pass SPF, DKIM, and DMARC fine. The problem comes in when I set up the domains to be able to send from each other.
I've added the capability for user#whedoncon.com to be able to send mail as user#thehellmouth.org. The issue seems to be when I log in as user#whedoncon.com, and send a message as user#thehellmouth.org. Looking at the email headers, it seems that because I logged in as user#whedoncon.com, it sets the return-path to the whedoncon.com address regardless of what account I select to send out the email.
The problem with this, is it causes DMARC to fail whenever I send an email out as user#thehellmouth.org, even though SPF and DKIM both pass. It seems to be because the return-path is showing as user#whedoncon.com, but the DKIM is looking at hellmouth.org.
So, TL:DR, google seems to always default to the signed-in account for the return-path, and not the secondary account that it's actually sending from. Is there a way I can change the return-path so it matches the account the email is coming from, and not the account that I'm signed in as?
Google Workspace has a primary domain and users are assigned a primary address under that domain. When you have a domain alias, users are assigned an alias address under that alias domain.
The envelope sender address (also known as the return-path address) and the From: address for a message can be different or the same.
If users send email from their alias address, the return-path address will be their primary address, while the From: address will be their alias address.
To pass DMARC, a message must pass at least one of these checks:
SPF authentication and SPF alignment
DKIM authentication and DKIM alignment
SPF typically uses the message envelope sender address for authentication. DKIM uses the message From: address for authentication.
When the domain alias is setup correctly, both the SPF and DKIM authentication will pass. However, only DKIM alignment will pass, SPF alignment will not pass. But that is okay because DMARC does not require SPF alignment to pass as long ask DKIM authentication and DKIM alignment pass.
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.
For some less critical websites it seems common for a user to be able to reset their password if they have forgotten it. The fact that they can access the email account that they registered with is considered good enough.
In those cases the only advantage of the password seems to be that, if the user can remember it, they don't have to check their emails in order to access the website.
Although not having to check your email is a convenience it has to be weighed against the inconvenience of remembering a large number of passwords for all the websites that require them.
A user would register their email address and verify it by responding to a link sent to their email address. After that, every time they wanted to access the site they would enter their email address into the login form and then click the link in the email sent to them.
Is there an argument for less critical websites to allow access without a password in this way?
Our Active Directory logins are currently e.g. john.smith#mycompany.com (i.e. the same as our email addresses). A friend said they used a number for login (e.g. 38292#mycompany.com) for security reasons. The login being internal and not public facing.
Wondering what others think/do and what is considered best practice. Thank you.
• Yes, as your friend said it is a good practice to keep your internal login ids and email ids as login ids different for several reasons. One of them is that if you have several people by the same names or similar spelling then it can be very hectic and weary to trace down a user’s activity across large span of internal environment presence. So, its best to keep internal application login different than email address as it helps your internal security team to continuously monitor and prevent threats like spamming a particular mailbox, sending phishing mails, etc. Also, it keeps your organization’s internal infrastructure at bay from attackers as brute force attacks through email ids are not at all possible since employee id numbers aren’t public.
• You can do so by configuring email address attribute for your users for which you can set the one containing employee number as their primary email address and other one configured, i.e., email address(firstname.lastname) as your employees’ alias email address or proxy addresses.
• Once, that is set, then you need to enable users to sign in with email address as alternate login ID. This feature tells the Azure AD login servers to not only check the sign-in identifier against UPN values, but also against ProxyAddresses values for the email address. This can be done through the ‘homerealmdiscoverypolicy’ resource as given in detail in the below link for your reference: -
https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-use-email-signin#enable-user-sign-in-with-an-email-address
We need to authenticate our domain with Mailchimp, and get the below shown window when going to Website > Domains > Email Domains > Authenticate.
I wonder whether anyone has some idea here: This doesn't seem to be SPF authentication. Is there no such thing for Mailchimp? I cannot find anything in Mailchimp's docs, but I thought that an SPF record would be essential? Thank you.
Indeed this is not SPF; it's called delegation or, less charitably, cloaking. What happens is that you point a hostname in your domain at theirs, and then they are free to create SPF and DKIM records in their own DNS. This is done so that they are in control of the records rather than you, since getting end users to do DNS updates is often very difficult. It also means that the SMTP envelope sender of messages needs to use that same hostname so that the SPF and DKIM records match up.
While it's very convenient for them, this approach has become unpopular lately because it hides the involvement of a third party (hence the cloaking name) in the processing of personal data. OTOH they don't make any attempt to be GDPR compliant in other areas, so it's clearly not something that worries them, though it should worry you if you have any EU-based subscribers!
#user1154435,
SPF record is essential if you send email from your own mail system (e.g. corporate mail server)
SPF validates domain in return-path/bounce address which, in case of most ESPs, is their own email, so that they could handle bounces.
In order to pass DMARC validation check of emails, sent from your domain, you need either SPF or DKIM to pass the check, and Mailchimp, like many other ESPs, give you an option to configure DKIM signing / validation
I'm considering building a website user authentication system using only one-time-passwords: users would get one in the email each time a normal password is normally used e.g. for signup, sign-in, risky actions and account deletion.
Some problems that I see with it that don't seem critical:
Can't change password to invalidate all existing sessions - can work around by storing sessions server-side and having a way to invalidate them for the user
Anyone can check if a certain email is registered in the system - doesn't seem like a critical problem for a generic website
Anyone can request an OTP for any email - will be dealt with using API limits per remote connection and a limit of 1 unused OTP per hour
I'm not seeing this method mentioned or used in the wild though. Does it have any major drawbacks? Many thanks!
OTP-by-email only is safer than password-only (it's basically like forcing the user to change their password every X hours).
I want to both address some of your non-critical points, and highlight some drawbacks.
Non-critical
Invalidating sessions
You don't have to store all sessions, only the invalidated ones, and only for the max duration of a session.
Checking that a user (email) is registered
That actually is a problem - it tells you that the email owner uses this website, which is a privacy issue, however minor.
But moreover, it's an attack vector. An attacker can scrape your user list, or just go attack that user on other sites, presuming that this email exists and links to a real human. Moreover, they can issue excessive OTP requests on their behalf, which I'll address in a bit.
All that said, there's no reason which this problem would manifest just because of OTP. A user can request OTP, and you can always reply with "If the email address hello#world.com is registered, a one-time password has been sent to it". This only has a slight usability implication.
Anyone can request OTP for any email
If an attacker can flood your site (from different IP addresses) with requests for OTP for hello#world.com, either you block this user (namely, that user has been DoS'ed), or you the site will flood the user's mailbox, which can get that mail server to flag the site as a spammer.
This could also be done in normal sites with password-reset emails, but that's why you typically want your user list to be secret.
Bigger drawbacks
Usability
OTP-only login assumes that the device from which you're logging in is also logged into the mail account linked to this site. Otherwise, the user has to log into the mail account in order to log into your site.
Single-factor authentication
The security community is pushing towards multi-factor authentication, where password is usually the first factor. A good practice would be to at least allow 2FA to users who choose to.
Account lockout
If a user's email account is no longer accessible for whatever reason (e.g. they used their work or university email), they can't log in, or even change their email address to their new one.
Email activity
If the site is heavily used, then it will be sending a lot of emails, to various public email services, continuously, all the time.
This alone may cause the site to be flagged it as a spammer, or even ratelimited.
If it does get ratelimited, some users will not be able to log in.