I've lost my brain the last couple of days trying to find the best solution for handling my transactional woocommerce emails, so that customers and store managers (on G Suite at the same domain as my site) get notified of new orders, etc.
TL;DR: I have a Woocommerce and want the next e-mail behavior and I wonder what's the best way to achieve this:
Have woocommerce emails don't go to my customer spam folders and get
notified to store.manager#mydomain.com and myemail#mydomain.com
G-Suite email accounts.
Use the info#mydomain.com and "MyDomain" as the "from email and name" in WooCommerce. Whether the info#mydomain.com is an e-mail
alias of my G-Suite email or a server side e-mail I don't care. What
I don't want is to configure a new G-Suite email just to serve
transactional e-mails.
So I'll describe my original situation, problem and the solutions I've read about:
When I setup the Woocommerce e-mails in settings, using a #mydomain.com email account two things happened:
Customers would receive the e-mails on their spam folder.
Store managers did not receive any e-mails whatsoever.
We also have this context info that might be of help:
We are just starting as an e-commerce, so no big load of emails...
We use the cheapest G-Suite plan (with up to 5 accounts) with our domain in Google Domain, so I don't want to use one of those account just to handle the transactional e-mails.
So I found the alias option and setup different aliases to both send and receive e-mails. E.g: "info#mydomain.com".
I read the official Woocommerce email-FAQ, and a bunch of other links in the Wordpress Forums and Stack Overflow, I came to find this three courses of action:
Setup split delivery and let my transactional e-mail address run from C-Panel.
Use an SMTP Plugin and set it up to use the Gmail API.
Create a subdomain and set WooCommerce/PHPServer to send the emails and just use my G-Suite emails as recipients.
I've read tons, and find myself in a loop where I don't know what's the best, future proof option, but this is what I've tried for every option:
I desisted on the idea of split delivery as soon as I found the e-mail aliases option in GSuite.
I did activated it and it solved one of my two problems, customers were no longer getting my emails to spam, but the Gmail API won't let me change the "from address" nor even the "from name", unless I select the alias as the default e-mail address on Gmail, which is not something I want; and if the alias (set up as mailer) and recipient is the same, then GSuite won't show the email in the inbox, but in the sent folder (and marked as read). So If the store manager email (storemanagername#mydomain.com) has an alias used to send Woocommerce emails (info#mydomain.com) he won't be notified for new orders.
I configured a domain alias on my Google Admin settings as a subdomain (store.mydomain.com) (which generates a new email alias with that subdomain) then I created a subdomain on my hosting provider (pointed at nothing for the moment) and had my hosting setup the Google MX records for my subdomain. Without the SMTP Plugin it does nothing, regardless of which e-mail I put in the from and recipient fields on the WooCommerce settings. With the SMTP Plugin things kind of work, using the alias#subdomain.mydomain.com as the recipient, as emails do arrive to inbox (instead of the sent folder) but doubled the regular mail and a huge postmaster notice, about how the domain alias "subdomain.mydomain.com" doesn't exist.
As a related note: Google per default generates a test domain alias which is mydomain.com.test-google-a.com when I use the alias e-mail with this alias domain recipient in woocommerce and the regular G-Suite in the from field on Woocommerce things pretty much work, except that my customers still get the emails to their spam folders.
How would I setup mailgun or sendgrid to use info#mydomain.com as the sender e-mail address? Would that work better?
I'm not new to wordpress, but definitely I'm a noob at WooCommerce and email protocol, setup in general.
Do you think you might exceed the G Suite sending limits? That'd push you towards the SendGrid/Mailgun/etc. solution for outgoing info#mydomain.com mail, with G-Suite accepting the incoming mail however you'd like. Though if it's important to avoid "reply-to" type addresses, make sure to choose a provider/plan that supports running off your domain (SendGrid calls it "domain authentication", Mailgun calls it "domain verification", etc.).
That will likely also solve that initial problem you described in your point #2 (assuming it was due to mail being treated as local-to-the-web-server).
If you take that approach, make sure to triple-check your SPF/DKIM/DMARC setup. And depending on which provider you go with, some of their WordPress/WooCommerce integration plugins are...not great. I've been working on summarizing the providers and their plugins if it's of any help.
And I had a little trouble following who needs to get copies of what, but there's the woocommerce_email_headers filter if it would be helpful to BCC the store managers. You could even do it selectively.
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.
I have just today realised that the authorisation emails sent from my perfectly legitimate Firebase backend are being flagged as malicious by Microsoft Outlook's "Advanced Threat Protection"
There is no reason for this other than perhaps it was flagged during development due to me sending myself repeated confirmation emails in order to test the functionality.
This warning does not show up in regular hotmail/outlook accounts, but I am an Office 365 subscriber so it appears as though I am lucky enough to get this "advanced" protection which protects me from my own completely non-malicious website.
Should I contact Microsoft or Firebase for a solution?
Thanks a lot!
Update: I contacted Firebase support and received the following:
My name is XXXX from Firebase Support, thank you for reaching out to us, problems on Microsoft services such as this “Advanced Threat Protection” is not in my area or expertise, I would suggest to open a ticket with Microsoft for this issue, I see that there is already a topic on Stack Overflow, please be sure to check other Firebase community channels as well.
I understand that this isn't Google's problem to solve, but it would seem any Firebase app using email verification is going to run into trouble with Microsoft email systems. Which is a lot of corporate and government systems...
Any suggestions on how to get some attention paid to this from either Google or Microsoft?
Cause
This error is caused by having inconsistent domains in the email. By default, user management emails link to the default action handler, which is a web page hosted at a URL in your project's Firebase Hosting domain ([project].firebaseapp.com), rather than the the same domain you may be sending emails from (veritification#yourdomain.com).
Solution
Make this “action link” go directly to your website. This will solve the outlook warning, and also make it less likely you'll end up in spam filters in general. On your website, you have 2 options for how to handle the actual validation.
Both solutions below require your domain to be authorized.
This can be done under Authentication -> Sign-In Providers -> Authorized Domains
Option 1 - Use Custom Email Action Handlers (Hard option)
You can setup a custom email action handler so that these actions take place directly on your website, rather than on the firebase hosted page. This is a more integrated experience.
This can handle
Resetting passwords
Revoking email address changes—when users change
their accounts' primary email addresses, Firebase sends an email to
their old addresses that allow them to undo the change
Verifying email addresses
1. Create your custom email handler page
custom email action handler page - firebase docs
2. Update Email Template In Firebase
This can be done under Authentication -> Templates -> Email Address Verification -> Customize Action URL
Option 2 - Just Redirect (Easy option)
Link the email back to a page on your website, that will immediately perform a javascript redirect to the [project].firebaseapp.com authentication page, carrying through the URL parameters required to perform necessary verifications and changes.
For Example
action url for email template: https://www.yourdomain.com/account-action (firebase will attach the appropriate params to the url automatically)
Javascript redirect on your website goes to ”https://project-name.firebaseapp.com/__/auth/action?” + params
I recommend ensuring you implement the continueUrl in your verification email delivery so that the user can easily get back to your website.
If you're using Firebase hosting, and you're serving from their built-in your-project.web.app address, then you can simply use the other built-in, your-project.firebaseapp.com, as your site address instead -- no configuration needed.
The .web.app address is a bit sexier, but the various action emails are actually sent from the .firebaseapp.com, and Outlook is suspicious of the mismatch. Having users originate from the .firebaseapp.com address solves the issue.
I opened a GitHub issue about this: https://github.com/firebase/firebase-js-sdk/issues/5021][1]
I have a client who needs to migrate his email accounts to G Suite. For Webmail, I can use Horde, but it only allows export of one email account and a single email box at a time. This client has dozens of email accounts. Is there a way I can automate the process using phpMyAdmin or other tool?
Everything I have found recommends using Horde to export each box of each email separately. This is far too time-consuming.
Web Host: site5
CMS: WordPress
Any help would be greatly appreciated. Many thanks in advance!
cPanel stores its emails in the following location:
/home/$USER/mail/$DOMAIN ## all email accounts
/home/$USER/mail/$DOMAIN/$email_account ## specific email account
Those emails are, by default, stored in maildir format.
Gmail doesn't use maildir for their emails. It will not be possible to simply copy-paste the files for the migration.
Is there a way I can automate the process using phpMyAdmin or other tool?
phpMyAdmin is a tool, written in PHP that provides a Graphic Interface for you to interact with a MySQL Database.
phpMyAdmin is not associated with the emails stored in your cPanel account and can't be used for your purpose.
Everything I have found recommends using Horde to export each box of each email separately. This is far too time-consuming.
This could work, however, as you will need to see how (if possible) your Mail Client Application can be used to import those emails back to Gmail.
I would recommend that you do the following:
Install a Mail Client that will assist with the migration. I highly recommend that you use Thunderbird as it will handle the maildir "migration" for you
You will need another domain for the migration - it will be used to "obtain" the emails from your cPanel account. You can register a free domain from Freenom
Point the second domain to your cPanel account
Freenom Nameservers -> cPanel Nameservers
Add the domain in your cPanel account. If your Package doesn't allow multiple domains - add it as an Alias. We need to be able to create email accounts for that domain.
Create the exact same email accounts. If your old domain is original.com and your Freenom is free.tk
user#original.com -> user#free.tk
Your original.com's emails are present in
/home/$USER/mail/original.com/
Copy them to (after you have re-created all original.com's emails for free.tk!)
/home/$USER/mail/free.tk/
Add each email account for free.tk to your Mail Client.
Have your client switch over his emails for original.com to Gmail.
Add each Gmail account to your Mail Client.
Drag and Drop each free.tk email account's content to the corresponding Gmail account.
Note: This works in Thunderbird, I'm not familiar with other email clients.
This is far too time-consuming.
There's no fast way to migrate emails from a cPanel server to Gmail.
I've migrated multiple email accounts by following the above steps and didn't have any issues.
The only thing that you should be aware of is that during the time that your Client switches over to Gmail - his emails will not be transferred yet and will not be available in his/hers inbox.
The company I work for have a small Plone blog. But we have a problem with spam accounts. We use captcha on the site and Plone sends a mail to the users that they must confirm before they can edit the user profile. Still about 600 spam users are created every day. In the Plone user profile they paste all kinds of commercial links.
We are located in Denmark and the blog is in danish, therefore I have made a script to delete all users with a non danish mail adress. But even though most of the real users have a danish mail account I probably still deletes some real users when running the script.
The spam users register from a vide range of ip-adresses, so blocking ip's is not an option.
Does anyone have ideas to what to do about this problem?
Disable Plone comments/public user creation and use a third party commenting service such as Disqus.
They somehow trick recaptcha (if you find out, please let me know :)
But how do they do the email validation? They don't have to. Plone join_form has a hidden field for password which is filled by this bot and Plone saves it as the real password (check the REQUEST object comming from this bot)
So the bot doesn't need to check email for password. That's how they get in and activate those accounts. So fix the hidden password field from join_form.
Then, remove all users that have links in their profile description (as a real user you don't do that, do you?). Also don't let the users to input HTML within their profile description.
I own a small domain on GoDaddy and I currently use their email service and pay a monthly fee for it. But I was thinking on how would it work to one be the owner of the email account itself, and create email address without involving the registrar. I dont know if I'm explaining myself but my question is more or less how do the protocol works to be able to create/manage email accounts. i.e Obviously gmail, and every single other webmail provider creates the accounts programatically without involving any registrar. Hows does it works?
Thanks.
What you'll need to do is set up a 'MX record' for your domain. This tells other email servers where to send email for some given domain; then you also need an email server to actually receive this email. On a Linux system, this would be something like postfix or exim, or even sendmail (not really recommended these days though). Or you could use a third-party free hosting service, and point MX records to them - eg, google apps.