I am trying to set up an email verification system as part of a side project web application I am working on. The system uses rails to send email on a linux server via a mailer. I am using my personal email address, which happens to be a gmail address, as a test case. Style information for the HTML email is embedded in a <style> tag in the <head> of the HTML email. This appears to be right, although it's difficult to tell that it's exactly correct, since the style data is pretty long. (This same style data works on a web version of the application and I'm embedding it into the email message - I will eventually create a separate stylesheet just for emails, that contains only the relevant styles, but for now, I'm using my web stylesheet for simplicity)
None of the styles appear to be shown in the email as I expect. I noticed that the email that I receive has a little question mark next to the name, indicating that the email is not authenticated with google. The message headers also contain the following:
ARC-Authentication-Results: i=1; mx.google.com;
spf=neutral (google.com: 45.56.123.196 is neither permitted nor denied by best guess record for domain of no-reply#myapplication.io) smtp.mailfrom=no-reply#myapplication.io
I'm wondering if the lack of SPF verification is causing google to not show the style data for the HTML version of the email? I can't seem to find another rationale for it. I don't have another email address that doesn't use gmail as a client (both my work and other personal emails utilize gmail), so it's not as though I could test to see if it wasn't routed through google if it would be resolved.
The mailer previews for rails seem to show that the HTML email should work, but gmail doesn't show it the same way as the mailer previews (in fact, not even close). I'm not quite sure what I can do to troubleshoot this, so any suggestions on what I can do to help solve this problem are welcome.
SPF should not be issue for style related issues. You can make sure this by sending email from gmail domain (sender domain in SMTP configuration) and your own gmail address. If it works then problem should not be in SPF.
But you would face issue when your email landed in SAPM, in this case external URLs won't work as Gmail will restrict external API calls for security purpose, so if you loaded any image or any other assets then it won't work. That's why images in emails were not opening in SPAM emails.
Note: Gmail will remove whole style in case your style tag has syntax error. So please make sure you don't have any syntax errors. You have lot of online tools to validate syntax errors.
FYI: It's better to solve SPF issues as well, otherwise your email would land in SPAM as most of ESPs are expecting to pass SPF, DKIM and DMARC.
Related
I have implemented the reset password link for my app (using exactly the same firebase code provided at https://firebase.google.com/docs/auth/web/manage-users). It works well when I tried it using a gmail account that I have registered previously on the app (I received the reset password link on gmail and able to change for a new password). However, when I tried it with other email domains (like professional work or school domains e.g #mycompany.com or #school.edu), it does not seem to receive the email (not in junk/spam too). It is very weird because I do receive the 'email verification' link (from firebase) using other domains when I registered using the app but not when I tried to reset the password? Any ideas on how to approach this problem?
As an FYI, currently in Jan 2023, Microsoft 365 business blocks these emails from ever reaching the target mailbox, even if you change the SMTP settings in firebase.
They still appear in your own SMTP sent section, they just never get delivered by MS
Open firebase console goto Authentication then click on Templates > Password Reset then copy given email address (it seems like, 'noreply#YOUR-PROJECT-NAME.firebaseapp.com') then open your Gmail account and paste that email id in search section the tap on 'view message > move to not spam'
This will surly help you
Thanks
Meet Patel
If the code is the same and you don't get an error message, it is extremely likely that the email gets blocked somewhere along to the way to the target mailbox. You'd have to reach out to the system administrator and see if they can find the message somewhere in their spam filters, and ask them to modify the configuration of those to no longer block these messages.
As ganey stated, the problem is that certain email filters such as MS 365 do not accept mails that contain links that are not in pair with the sender domain.
The solution is to add a customized action url that points to the same domain as your sender domain.
Then you need to redirect from that url to the url generated by firebase.
Note:
If you do this in react or another SPA, don't forget to append the query params.
I am trying to set up emails on my WordPress website using the WP Mail SMTP plugin and the Gmail API. (WordPress version 5.5.1; WP Mail SMTP Version 2.4.0)
The website I am trying to set this up on, https://souheganvalleychorus.org/ is part of a GSuite for non-profits domain.
I have followed the WP Mail SMTP setup instructions on:
https://wpmailsmtp.com/docs/how-to-set-up-the-gmail-mailer-in-wp-mail-smtp/
with meticulous care. However, when I get to the final step, where I click on the WP Mail SMTP plugin's setup page, and click on "Allow plugin to send emails using your Google account", get prompted with some dialog boxes, choose the email address that I used to set up the Gmail API, it finally comes back with a webpage that says simply:
Unauthorized
Back {a link}
the URL for this page is:
https://souheganvalleychorus.org/wp-admin/options-general.php?page=wp-mail-smtp&tab=auth&code=4/4AEw2mlaJPMgOg7boWHzLLDIJdg0Gwb98vGyJfrteQXcOE5cnL1HMj5wX6QSRZQ0x2rhrbxlzqKPBsF7uokdWCg&scope=https://mail.google.com/
I have been pulling my hair out trying to figure out what is happening, and what I can do to fix it. The 'Unauthorized' provides absolutely no additional information.
I have previously set up the WP Mail SMTP plugin to use the Gmail API, on another website (also a GSuite for non-profits domain, but a different one), and succeeded in that case. I seem to recall having had some problems setting that one up, too, but don't remember how I resolved the issue. When you do something (especially with such an arcane interface as the Google API interface) once in a blue moon, you tend to forget the details. I have tried to compare the two Gmail API setups, and can find no difference that would explain the failure in the current case.
I sure would appreciate anyone's help in resolving this. Until I do, I can't send email from the website. I've also tried using WP Mail SMTP's "Other SMTP" option, with the Gmail SMTP credentials, but that fails to authorize, so I'm stuck...
Help! (and thanks!)
Lately a new error has popped up, which didn't exist before.
I have a Firebase project mapped to a custom domain.
The structure I'm using is as follows:
firebase-project.example.com is DNS-pointing to Firebase, that's the custom domain, it is tied to the Firebase project (Firebase Hosting).
But the structure I'm offering to the clients is as follows:
www.example.com/firebase-project which is hosted on my own server.
When I have Firebase generate the verification email, I present them a verification link in the email which contains this structure
https://www.example.com/firebase-project/auth/email?mode=verifyEmail&oobCode=SOME_AUTOGENERATED_CODE&apiKey=FIREBASE_API_KEY
The page rendered by https://www.example.com/firebase-project/auth/email contains an iframe, which loads the following URL
https://firebase-project.example.com/__/auth/action?mode=verifyEmail&oobCode=SOME_AUTOGENERATED_CODE&apiKey=FIREBASE_API_KEY
That should (and effectively used to!) verify the email on Firebase Hosting, and present the "ok, verified" message provided by Google inside the iframe, all neatly surrounded by the branded https://www.example.com/firebase-project/auth/email webpage.
But as of lately the iframe shows the following message:
Error encountered
The page is displayed in a cross origin iframe.
and I can't verify the email.
These cross-origin issues usually get fixed by adding the apropiate access-control-allow-origin headers. Where do I need to set the header, and to which value?
I have tried sending Access-Control-Allow-Origin: firebase-project.example.com and also Access-Control-Allow-Origin: * with the www.example.com/firebase-project/auth/email response, but that does not work.
Could a crossdomain.xml hosted somewhere help me with the issue?
If I inspect the page, and manually copy the iframe-url and paste it in the address bar, then the email will get verified.
No console messages (errors) are displayed at any time.
www.example.com as well as firebase-project.example.com are in the list of authorized domains for that project.
firebase-project.example.com ist using Firebase Hosting and
therefore has access to the /__/auth/action functionality. It is able to
verify the email address.
www.example.com is not hosted on Firebase / Google Cloud, and
therefore has no /__/auth/action functionality. It can't verify the email address without the help of firebase-project.example.com.
Sadly, the Firebase Admin SDK does not offer any support for letting the backend at www.example.com verify the email address for the given oobCode, which is why I was forced to use an iframe.
This is what the result should look like, instead of just a white page confirming the verification:
And the iframe is implemented as follows:
<iframe src="https://firebase-project.example.com/__/auth/action?mode={## mode ##}&oobCode={## oobCode ##}&apiKey={## apiKey ##}"></iframe>
The Firebase Console Email verification template looks like this
Else I see myself forced to create a redirect to firebase-project.example.com which results in this page (which actually seems to be predestined to be embedded in an iframe)
There is exactly zero security gain in preventing the embedding inside a page of an authorized domain.
Also, notice the message "You can now sign-in...". My approach shows the Sign-In link conveniently above the iframe. Without it, the user must now type "www.example.com/firebase-project" into the address bar. It makes so much more sense with an iframe; a more efficient and user-friendly approach.
I am using contact form 7 one of my wordpress site that using vantage app theme. But problem with sending contact mail. when I am trying to send mail get following message
"Failed to send your message. Please try later or contact the administrator by another method."
Thanks
The only problem is you can send emails from you hosting domain email accounts only.
so check your to email address that is comes under you domain name
I hope this will solve your problem
This is almost certainly due to your particular hosting setup. There are a host of issues that can stop the sending of emails. It depends entirely on your local Server & WordPress configuration.
You will need to investigate this issue for your particular local configuration. See Contact Form 7 Email Issues.
By the way it's not due to "hosting php version or maybe mysql version" - it's due to basic stuff that you can address by working through the issues in the link.
I faced the same issue some time back. Are you using any WordPress caching plugin? like WP super-cache? I resolved this issue by following below steps on WP Super-cache.
Go to WP Super-Cache Admin panel
Go to “Advanced Tab”
Search for “Add here strings (not a filename) that forces a page not to be cached.”
Add '/contact/' (your Contact Form Page name)
Save Strings.
I was able to fix this problem after I spoke to my client's hosting company. The host claimed that the only requirement they had for emails to be passed through their system was that either the To: or the From: field contain an email address under the hosted domain name. They uploaded a test script (an ordinary PHP mail script) where the From: field was set with an address within the domain and the To: field was set to an outside email address. That script worked. I confirmed that I had the To: field in CF7 set to an email address within the appropriate domain but the form didn't function. Then I set the From: field to an email address within the domain and the form finally functioned. It appeared, therefore, that the host was incorrect about the To: field's address being within the domain being sufficient.
Into the "Form"(inside the mail menu) section you've to give the domain name of your site. And inside the message body use the short codes which will appear into the top of the mail menu.
And when you create a form field such as "name" / "email" / "phone no" etc, then give a name to them. Those name turns into a short codes like
[your-name]-Name, [your-mail]-Email(those are defaults, you can give any name according to your choice) etc, copy the short code and paste into the message body, don't write it only copy and paste.
Hope this will help you.
This suggestion depends on how your hosting provider deals with mail headers:
So, I have made all tests (javascript conflicts, etc.) and decided the problem could only be from my host. I contacted them and they told me that in email header, the "From:" SHOULD be exactly the same as the email I configured to receive the messages from my visitors.
As far as I understood, by default "Contact Form 7" uses visitor email to put it in "From:" but some host providers do not allow that.
My host provider don't even allow mail() function so I had to install WP MAIL SMTP.
So, resuming, I just added this to all my forms in "Additional headers":
From: your#domain.com
This means, you have to insert one email with same domain name as your website, otherwise your hosting might not send the email.
I lost a couple of hours with this...
Maybe is another plugin incompatible with contact form7 plugin.
Deactivate all plugin one by one and try send email.
I fixed the problem. webadmin email account was not setup. Once I setup the email account it is working fine.
I know there are ways to detect browsers based on CSS rules but I don't know if the same tricks would work for Outlook. The way I think it could work is have CSS rules that show and hide urls so that when a recipient clicks on a link I can tell which email program it came from.
I can't see how this would be possible. Browser detection is done via Javascript (not CSS). And if the user is using a non-web-based email client (such as Outlook), clicking on a link will trigger the default browser to open and load the link. The information the browser sends to your server will have no knowledge of what application caused the browser to launch.
I think your only option would be to have different links for each client and rely on the goodness of the users to click the correct link.
I also think you'd have a fairly high success rate of guessing the client based on a few factors that ARE available after the link is clicked such as:
The device type
The Browser
The Operating System
The email address (if it's gmail.com or hotmail.com you know 99% of them used the web client - or for a better match mix it with the device type)
Then you could make generalisations such as:
Accessed from Windows and not a gmail/hotmail/yahoo webmail address - probably used Outlook
Accessed from OSX and not webmail address - probably used Mail
Accessed from either and a webmail address - probably used Browser
Rules like that could probably give you some pretty meaningful statistics.
If your challenge is to see what email client the person is using, there are simpler solutions than showing and hiding links. The easiest way would be to embed an image, add a query string to it like so:
http://www.yoursite.com/image.png?email=youremail#email.com
You would then catch this serverside and get the user agent string.
The issue with this is with webmail clients like GMail and Hotmail. In these instances the user agent string would be the same as the web browser. Here you would detect the user's webmail client by inspecting the email address, eg. hotmail.com.
There are edge cases such as Google Apps for Business, but this should catch most cases.
Most email senders such as Mailchimp will do mail client analytics for you.