I'm trying to figure out how to send a plain text version of my email, alongside the html content generated by dynamicTemplateData and my dynamic template.
Including text as a sibling to dynamicTemplateData results in a broken email.
It looks like SendGrid is including a text/plain email alongside the text/html content, but it's empty.
Does anybody know how to inject a text/plain version of my email?
Twilio SendGrid developer evangelist here.
When you preview your dynamic template, you can check it out in Desktop, Mobile and Plain Text versions. You can set SendGrid to automatically create a plain text version of the email from your HTML variant, or you can choose to write your own plain text version.
See the screenshot below for more detail:
Related
I've got a webhook which is parsing emails sent by SendGrid's Inbound Parse, and if any error occurs with processing the email, I want to send the original email as an EML attachment to a notification email address.
I've been using Busboy to parse the multipart/form-data received by the webhook and I receive the full plain cleartext of the email contents itself. Everything is fine there.
When I go to send the email using #sendgrid/mail and set the original email as an EML attachment file, this is where I get issues.
I've tried a variety of content encodings and mimetypes, but haven't found one that works yet as a EML file. I've tried text/plain, message/rfc822 and application/octet-stream with plain text (which results in error from SendGrid API), and base64 encoded text.
In fact, it gets weirder. When I send the email attachment as text/plain with filename ending in .txt, everything seems to be good. When I download the attachment and rename to .eml then it views perfectly in my Mail app.
However, when I send the email attachment as text/plain, message/rfc822 or application/octet-stream with filename ending in .eml, this is where I get inconsistencies. In the email I sent I can see that the filename now ends with .eml.eml and opening the file in my Mail app shows me base64 encoded text (decoding the text gives me the original email contents that I had to encode in order to allow the endpoint to send as an attachment). Viewing the file contents in a text editor looks like this:
Content-Type: text/plain
MIME-Version: 1.0
VGhpcyBpcyB3aGVyZSB0aGUgYmFzZTY0IGVuY29kZWQgZW1haWwgdGV4dCBnb2Vz
My current conclusion is that the SendGrid /v3/mail/send API endpoint is treating attachments with .eml extension in the filename differently and encapsulating the base64-encoded contents within another .eml wrapper. It doesn't seem possible to set an attachment's content to a plain text string as I get a 400 Bad Request from the endpoint if its not base64 encoded.
I haven't been able to find any official documentation about this particular behaviour on this endpoint. The closest I got was this GitHub issue (dated 2018), but it doesn't seem to solve my issue.
when I try to send emails with phpmailer, it send inline images as attachment. I mean before opening email for example in yahoo or gmail , they show that this email has attachment and when I open the mail, it shows images inline and in their right position with no problem,
but I see many emails with inline images that show emails as one that don't have any attachment.
by the way for embedding images to phpmailer I use this method: addEmbeddedImage(filename,cid)
what can I do to solve this problem?
thanks for you help
If you attach images to an email, they are attachments, no matter what. If you use them by referring to their cid values from within your HTML, they will render inline as well, but they will still be shown as attachments, because they are. If you refer to images using remote URLs, they will render inline as well (providing you allow your mail client to do so), and they will not show as attachments - that is what the other messages you're seeing will be doing. Generally speaking, referring to images remotely is preferable to embedding/attaching.
I have a html file (generated via knitr package in R). It has a image which is encoded as data uri so there is no need for image attachments. Here is the link to that sample.html
http://jsfiddle.net/ebwsozav/
Sending it as an attachment, hasnt been issue but now we want to send this html to be embedded into the content of the email.
Using mutt, mutt -e "set content_type=text/html" -- person#gmail.com < sample.html.
Upon opening the email, I realised that the image couldnt be seen, though the html tables and other content could be.
Screenshot attached here
I read that gmail blocks images.
Could this the reason and is there a way to circumvent this problem ?
Update
Outlook cant view it.
Gmail in Android not able to view.
But surprise,surprise
Gmail in iOS system is able to view the image.
I read that gmail blocks images.
Partially correct. Gmail filters data URIs from being displayed in its interfaces, but it allows you to download/forward the original message (including the data URI) to a mail client that doesn't filter it. It does block (all) images on messages flagged as spam.
is there a way to circumvent this problem ?
Not exactly. You have to either use a regular URL or attach the image. It is intended for there to be no way to use data URIs in their interface.
Earlier versions of the Notes client would automatically turn a sent URL into a clickable link for the recipient (regardless of mail client) but with 6.5 (and presumably later) this no longer happens; that is, the URL is sent as plain text. The Notes UI allows it to be done via the Create->Hotspot->Link Hotspot menu but this gets tedious.
I'm looking for a way to create a Link Hotspot in LotusScript. My research to date leads me to believe that this isn't possible but there may be a hack of some kind.
The automatic conversion of urls into clickable links is a user preference.
In 6.5 it is set via File/Preferences/User Preferences/Basics. In 8 it is set via File/Prefences/Basic Notes Client Config.
I don't think you can create a url link hotspot explicitly using lotusscript. You can create a doc link, but there is no obvious way to turn it into a url link.
You could try an approach where the form is set to render passthrough html on the client and then construct the relevant html for a link.
Update in response to comment.
The scenario is that we want to to control what a user receiving mail sees. We have a few cases we should think about.
The recipient is using Notes and received the mail directly via notes to notes routing.
The recipient is out on the internet using any client and allows email in a rich format.
The recipient is out on the internet using any client and only allows email in plain text.
In the first case the user will see links if they turn on the option for that. You could also create pass-through html in the rich text and that will render on the Notes client assuming the form option is set in the design. If it's straight email and you don't really need any other rich Notes features you could also construct a MIME message.
In the next two cases you just want to send properly formatted MIME messages. In the first of those cases the user will accept rich formatting and therefore you can construct the message as simple html and include links that way. In the second case the user will not, and you have to make do with plain text. Luckily most mail clients will automatically turn urls received in plain text messages into links for you. This may be an option as in the Notes client.
It is best practice when sending rich mail content to also include a MIME section for plain text. That way you don't need to care what version the user prefers.
You need to cheat and create a MIME entry to get your links. Going that route you also can take the opportunity to make it look really nice. The sample code is on this site
I have a form that Legal will use to track trademark claims. They want to be able to attach logos to this for for easy reference. It's easy enough to create a file attachment, but is there any way to show a preview of the attached image?
The solution has to be usable in a browser enabled form.
Attachments are stored in base64 format. You'd need to somehow post that data to the server, encode it correctly, and send it back to the client as a jpg. It's a bit of work, but i'm sure it's doable.
You could add a link column (named preview) to your form library that leads to an .aspx page in the layouts directory, where you read the form xml and generate a preview of the document including the attachment previews.
This way you are able to handle the different attachment formats (e.g using C# code) and bypass the limited functions of the form service.
You could add a "edit this form" button to that page that redirects to the original formservice url.
Most browsers support base64 decoding, so you could very easily just point to the base64 data directly.
You might want to checkout base64 in internet explorer: http://dean.edwards.name/weblog/2005/06/base64-sexy/