I'm trying to send some html in a generated email that looks something like this:
X-Sender: XXXX#xxxx.com
X-Receiver: XXXX#xxxx.com
MIME-Version: 1.0
From: XXXXXXX#xxxx.com
To: XXXXX#xxxx.com
Date: 9 Dec 2010 10:55:52 -0800
Subject: Test email
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
<p>Click on the link below</p><p>Click Here</p>
The email sends but for some reason the link tag doesn't show up. I'm thinking it has something to do with the the content type. Any ideas? Thanks in advance.
You could try this Content-Type: "Content-Type: text/html; charset=ISO-8859-1\r\n"
It should allow your HTML to be handled properly.
Related
I am using the TinyMCE 5.8.1 editor against existing data, where the textarea has MIME content:
"MIME-Version: 1.0
Content-Transfer-Encoding: binary
Content-Type: text/html; charset=UTF-8
Dear Steven San, etc etc"
As soon as I call tinyMCE.init the format gets changed, and saving the data the textarea now shows different MIME content:
"MIME-Version: 1.0
Content-Transfer-Encoding: binary
Content-Type: text/plain; charset=UTF-8
Dear Steven San,  etc etc"
All of the HTML formatting seems to be stripped, and the Content-Type changes from text/html to text/plain.
I'm struggling to find anything about this in the TinyMCE documentation, or via google.
How do I stop, or control this apparent stripping of html formatting?
p.s. for new documents, everything is working fine, and storing as text/plain.
I'm trying to self-test my email schemas.
My mail is sent with:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
The original script tag <script type="application/ld+json"> is rendered as <script type=3D"application/ld+json">, when I View Original the marked up email.
This fails the markup tester, but when I manually remove the 3D, it passes the test.
Q1 - Does Google support quoted-printable encoding?
Q2 - Why does the test fail?
Note: On a Rails application I use the Mandrill API to send the email.
1.) Yes, quoted-printable is supported.
2.) You're testing the markup after it had been encoded. You should decode the raw email, then test it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
We use Mailgun to send out emails and recently I noticed quite a few emails each day are being rejected by Gmail.
Here's the type of message we receive:
550
5.7.1 [184.173.153.6 11] Our system has detected that this message is
5.7.1 not RFC 2822 compliant. To reduce the amount of spam sent to Gmail,
5.7.1 this message has been blocked. Please review
5.7.1 RFC 2822 specifications for more information. f15si23385851vdu.1 - gsmtp
The RFC 2822 spec is a massive document so I haven't read it front-to-back but from looking at resources around the web our emails don't fall into any of the common pitfalls that would trigger this type of response from Gmail.
Here's an example email header:
Received: by luna.mailgun.net with HTTP; Mon, 29 Jun 2015 21:06:59 +0000
Message-Id: <20150629210659.18668.39318#(domain)>
X-Mailgun-Variables: {"variation": "original", "campaign_code":
"(customValue)"}
Reply-To: (name) <(email)>
X-Mailgun-Track: false
X-Mailgun-Tag: (customTag)
To: (email)
From: (name) <(email)>
Subject: (subject)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="12f0bd630f2145a3afcd98b621a3b1f2"
--12f0bd630f2145a3afcd98b621a3b1f2
Content-Type: text/plain; charset="ascii"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
(text content)
--12f0bd630f2145a3afcd98b621a3b1f2
Content-Type: text/html; charset="ascii"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>(title)</title>
<style type="text/css">
(css)
</style>
</head><body style="(css)" >
(content)
</body>
</html>
--12f0bd630f2145a3afcd98b621a3b1f2--
What are we doing wrong?
One obvious rfc2822 violation in your example is the missing Date header .
from rfc2822, Section 3.6:
The only required header fields are the origination date field and
the originator address field(s).
It turned out we were using two different domains for the From and Reply-to which I guess is a no-no.
I have written the following two methods for sending requests for signatures.
From template: https://github.com/wadewegner/docusign-sample/blob/master/src/DocuSign/DocuSignClient.cs#L215
From binary: https://github.com/wadewegner/docusign-sample/blob/master/src/DocuSign/DocuSignClient.cs#L152
Both work great and I can see they are out for signature:
The trouble is receiving the email requesting the signature is spotty at best. Early on in my testing it seemed I'd (mostly) get the email, but a couple days in and I haven't received any of the emails you see in the image above.
I'm using a developer sandbox. Is there some kind of restriction?
Also, it seems sending to a different email address from the one I registered is particularly problematic. Are there even more restrictions?
Thank you!
Edit: adding additional info requested.
REQUEST #1 (posting document):
POST https://demo.docusign.net/restapi/v2/accounts/892965/envelopes HTTP/1.1
X-DocuSign-Authentication: <DocuSignCredentials>...</DocuSignCredentials>
Accept: application/json
Content-Type: multipart/form-data; boundary="BOUNDARY"
Host: demo.docusign.net
Content-Length: 91206
Expect: 100-continue
--BOUNDARY
Content-Type: application/xml; charset=utf-8
Content-Disposition: form-data
<envelopeDefinition xmlns="http://www.docusign.com/restapi"><emailSubject>DocuSign API - Signature Request on Document</emailSubject><status>sent</status><documents><document><documentId>1</documentId><name>test.pdf</name></document></documents><recipients><signers><signer><recipientId>1</recipientId><email>wade.wegner#gmail.com</email><name>Wade Wegner</name><tabs><signHereTabs><signHere><xPosition>100</xPosition><yPosition>100</yPosition><documentId>1</documentId><pageNumber>1</pageNumber></signHere></signHereTabs></tabs></signer></signers></recipients></envelopeDefinition>
--BOUNDARY
Content-Disposition: form-data; name=test; filename=test.pdf; filename*=utf-8''test.pdf
<truncating binary>
REQUEST #2 (from template):
POST https://demo.docusign.net/restapi/v2/accounts/892965/envelopes HTTP/1.1
X-DocuSign-Authentication: <DocuSignCredentials>...</DocuSignCredentials>
Accept: application/json
Content-Type: application/xml; charset=utf-8
Host: demo.docusign.net
Content-Length: 421
Expect: 100-continue
<envelopeDefinition xmlns="http://www.docusign.com/restapi"><status>sent</status><emailSubject>DocuSign API - Signature Request from Template</emailSubject><templateId>29CB97E5-DCE1-4C14-91A8-A8317BCD29AD</templateId><templateRoles><templateRole><name>Wade Wegner</name><email>wade.wegner#gmail.com</email><roleName>Signing Role</roleName><clientUserId>1</clientUserId></templateRole></templateRoles></envelopeDefinition>
The ClientUserId causes a recipient to be an embedded recipient. If you provide a value then DocuSign will not send emails. The expectation is that you are going to handle the communication with the signer. This allows you to embed the signing experience within your own website or application.
I think without a trace of your JSON it's hard to figure out where the problems are. One problem could be that you create the envelope in the "created" instead of "sent" state. Another problem could be that you are providing a "clientUserId" which signals to our system that you are embedding the signing experience.
Why don't you get the status on the envelopes where you think you didn't get the e-mail and see what it looks like.
-mb
Is it alright to send HTML-only emails without the text/plain part when doing HTML only actions like clicking a link to view replies or some other "alert" type notification? For example, clicking a link to activate your email or clicking to see new comments.
Date: Wed, 07 Mar 2012 10:30:54 -0800 (PST)
From: email#site.com
Subject: Test Mail
To: <email#site.com>
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
VGhpcyBpcyBdfJDFKdjfkdsFpbCBmcm9tIGxvY2FsaG9zdCB3aXRoIGZzbdrb3BlbigpIGF0IDEz
eGVvbmNyb3NzLmNvbSI+eGVvbmNyb3NzLmNvbTwvYT4gPGk+bGluazwvaT4hPHA+VGhpcyBpcyBt
b3JlIHRleHQ8L3A+
Instead of using multipart to create two copies of the same email.
Date: Wed, 07 Mar 2012 10:30:54 -0800 (PST)
From: email#site.com
Subject: Test Mail
To: <email#site.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4f57a7d259baf"
--4f57a7d259baf
Content-Type: text/html; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: base64
VGhpcyBpcyBdfJDFKdjfkdsFpbCBmcm9tIGxvY2FsaG9zdCB3aXRoIGZzbdrb3BlbigpIGF0IDEz
eGVvbmNyb3NzLmNvbSI+eGVvbmNyb3NzLmNvbTwvYT4gPGk+bGluazwvaT4hPHA+VGhpcyBpcyBt
b3JlIHRleHQ8L3A+
--4f57a7d259baf
Content-Type: text/text; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: base64
VGhpcyBpcyBdfJDFKdjfkdsFpbCBmcm9tIGxvY2FsaG9zdCB3aXRoIGZzbdrb3BlbigpIGF0IDEz
MzExNDQ2NTgKCkFsc28gd2l0aCBhIGdvb2dsZS5jb20gdXJsIGFuZCB4ZW9uY3Jvc3MuY29tIGxp
bmshVGhpcyBpcyBtb3JlIHRleHQ=
I would like to save the bandwidth if there isn't a very good reason to include the text version.
If you're looking to save bandwidth, I don't think you should be using base64 encoding as it makes your data 33% larger (on average). In my understanding, text/plain (not text/text) should always be provided in a human-readable format (like quoted-printable).
I don't think there are many e-mail clients that can't read HTML nowadays, still I think your decision should reflect how important it is for the end-user to be able to read (and understand) your e-mail / alert and not (minor) bandwidth limitations. I've no experience with AOL, but I think it had some issues with e-mail links a few years ago, perhaps that counts as a bonus points for the plain text alternative.
Also, don't forget that the actual links need to be displayed in plain text versions.