We are trying to deliver marked-up content via gmail and other email clients, currently we are trying to send emails from (x#gmail.com) to (x#gmail.com) using microdata format which means that the sender and receiver address is same. However when we do perform this with the Google Dev Console it works just as fine, when we are doing the same using AWS SES or Pinpoint service the marked up content doesn't appear as part of the mailer.
On inspecting the SPF and DKIM, the checks are successful also viewed the raw HTML, and the markedup content is part of the HTML however seems like its not parsed.
Related
My company migrated their CRM starting to use Odoo, and then I proceeded to configure the external mail server (gmail), the #catchall parameter, and then define the odoo mail templates.
So far I have no problems, and everything works as I expect, so the mails are correctly and received.
However, I have a problem with viewing the emails ... let me explain.
Sent an email through Odoo, I see it correctly in html format, so by accessing the gmail email account via browser and opening the message, also in this case it is correctly formatted and displayed as html.
However, the recipient of the e-mail upon receipt loses the html formatting and therefore receives the e-mail displaying it in plain-text.
On the gmail settings I have already configured to send messages in html, I tried to disable it and then re-enable it but nothing happens.
Do you have any suggestions or advice?
I also have the same problem. We have tried several configurations both in the Google account and in the server. It only happens with GMail mail. Using any other service does not happen.
There's an answer here that I still can't implement, but it could be of help.
GMail displays plain text email instead HTML
A known reason for the issue was the appending of a footer in Google. Odoo has recently released a fix for all versions from 14.0 onwards: https://github.com/odoo/odoo/pull/108499. However, if they encounter other cases, Odoo Enterprise customers can open a support ticket and users of the Community edition can submit a Github issue.
I am using Azure logic apps to auto-reply email using outlook.com connector.
When I use plain text in the reply it works fine like following:
It works as intended and replies to the new email with the text.
But when I use HTML in the comment it gives error:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Is it possible to include HTML in the email reply action for outlook.com in logic apps?
So I added the inline microdata to the first two articles of our newsletter (schema.org type Article) and tested it with the Email markup tester. It showed no errors and the data was analyzed correctly. When I send the newsletter to my gmail address, I don't get the summary box that I should get with microdata enabled emails. Any help?
The online version of my email can be found here: https://yz.emsecure.net/optiext/optiextension.dll?ID=Ji6eGRCbfS1Th6QKQlY_yrcy7KZDmJiS0s8nTPf1pfoyKcwEDzcXggWWbz7%2BVVizUZgCNG0A6DKOdWA721tJJr&_SHOWMAILHEADER=TRUE
Based on the documentation:
You can easily test if your markup is working correctly end-to-end by sending emails to yourself. All emails where the sender and the recipient are the same account ignore the registration requirements and can be used for self-testing.
DKIM or SPF authentication is still required for self-testing.
Once the markup is tested end-to-end with this technique and you are ready to launch your integration to production, check Registering with Google for the next steps.
But I found a related SO post - Testing microdata in Gmail doesn't work that functionality is still missing from Gmail. You can use Apps Script, App Engine to test it as this post suggested
i have an idea about system where users respond to website's messages using the emails they received.
Is it even possible to have multiple imaginary emails with hash in the e-mail's name field(f.e., 1h2149g0as1gasd9123#mysite.com ) and those all imaginary e-mails just forward content to messaging#mysite.com e-mail. And afterwards we are able to parse the contents and know for which conversation the message was sent.
The emails are hosted in Google service. Could not find any information about this in internet.
Such option would be excellent, because there would be no need of including the identificator in e-mail's content which might be deleted if no quoted text is in replied e-mail.
I'm open to any other suggestions that would fit in this situation.
When using Google's service, you can add tags after the e-mail address using a +. For example...
test#domain.com
test+12345#domain.com
test+wuishw78#domain.com
will all go through to test#domain.com, and you can then look at the address.
Note this is not supported by all e-mail systems, so while this works on Google's hosted e-mail, it may not work on others.
I am using the SES email library from amazon to send text messages by sending them through 5556665555#vtext.com for example, or just an email itself. However, recently some of the text messages have headers that show the from address as something like this:
0000013a94c84b04-4f0a3d49-483f-4dfb-8b8c-87a33698a35f-000000#amazonses.com even though the same email ends up in my email with regular from address. What could be the culprit/solution? This had worked fine previously with no change to how headers are dealt with ( I am using amazons SES library and haven't mucked with internals). The code is the exact same when I send it to a regular email address or an SMS gateway address.
UPDATE
I have realized that vtext changes from address to the ReturnPath Header, giving me the long drawn out address. I have tried setting the opt variable to contain 'ReturnPath', 'me#me.com' so when I call $ses->send_email($this->source,$this->destination,$this->message,$this->opt); it does pass it in, however, this is being ignored anyways. How can I force SES to respect the ReturnPath header, or alternatively, have the correct From address show up.
What is troubling is that ReturnPath is used for bounce reporting, so if this hack for verizons broken system is in place, I will no longer receive bounces.. but that is the best I've got at this point.