chapter
chapter copied to clipboard
Send both html and plain text in emails
Tasks:
- [ ] Require both plain text and html when sending email
- [ ] Update the sendgrid logic to use both
- [ ] Provide plain text versions of all emails
Original issue
@naomi-lgbt raised the concern that html emails are more likely to be marked as spam. To improve deliverability we should consider sending text only emails.
Pros
- Email should be more likely to arrive
Cons
- We embed various links into our emails, so it'll be a little messy.
I'm not sure if text vs HTML is as relevant as in the old days, but since fCC likely sends a lot of emails, I'll defers to if that's still a thing.
The most important elements I'm aware of are having an SPF and DKIM that's designated to send email from the sending server. We already have some notes in the FAQs about this, but for anybody using a 3rd part email service, those services should be requiring the domain's DNS records to be properly validated.
The most likely way to end up in spam is to send emails from a random web server / VPS with no SPF or DKIM and generic configuration, like (from localhost, or from root) and anybody hosting their own servers surely has run into this problem and likely either knows how to properly configure, or else relays through a 3rd party.
The most important elements I'm aware of are having an SPF and DKIM that's designated to send email from the sending server. We already have some notes in the FAQs about this, but for anybody using a 3rd part email service, those services should be requiring the domain's DNS records to be properly validated.
Oliver and I paired up this morning and are working on a Sendgrid integration for production environments - which will ensure that our emails aren't blocked (we already have the SPF, DKIM, and DMARC configured for our Sendgrid account).
I'm not sure if text vs HTML is as relevant as in the old days, but since fCC likely sends a lot of emails, I'll defers to if that's still a thing.
I'm honestly not sure either, but I know when I first migrated our email newsletter Quincy was very adamant about ensuring the content-type was text and not html, so it might still be a concern.
GitHub sends a multipart email that includes both the plaintext and HTML version, so I have to assume that's something which will work for people in most parts of the world. Is there someone more involved with the fCC email that would know if fCC is sending both text and HTML using this multipart header pattern?
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_62d6eda1bea04_1adfd77890670"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: sender
X-GitHub-Recipient: recipient
X-GitHub-Reason: comment
List-ID: freeCodeCamp/chapter <chapter.freeCodeCamp.github.com>
List-Archive: https://github.com/freeCodeCamp/chapter
List-Post: <mailto:[email protected]>
List-Unsubscribe: <mailto:[email protected]>, <https://github.com/notifications/unsubscribe/xyz>
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: [email protected]
----==_mimepart_62d6eda1bea04_1adfd77890670
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
text content here
--
Reply to this email directly or view it on GitHub:
https://github.com/freeCodeCamp/chapter/issues/1263#issuecomment-1189378582
You are receiving this because you commented.
Message ID: <freeCodeCamp/chapter/issues/1263/[email protected]>
----==_mimepart_62d6eda1bea04_1adfd77890670
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
HTML content here
...
----==_mimepart_62d6eda1bea04_1adfd77890670--
I just checked an email from eBay and they use the same mixed plain and HTML pattern.
Content-Type: multipart/alternative; boundary="baWN13ZZbnj0=_?:"
--baWN13ZZbnj0=_?: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit
..... content here in plain text...
--baWN13ZZbnj0=_?: Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
.... HTML content here....
--baWN13ZZbnj0=_?:--
We specifically use text in our email blast:
Received: from MTY4MzI4ODQ (unknown) by geopod-ismtpd-canary-0 (SG) with HTTP id WCzHdhazSMiNzhgRz1BR3Q Fri, 10 Jun 2022 03:19:49.625 +0000 (UTC)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Date: Fri, 10 Jun 2022 03:19:49 +0000 (UTC)
From: Quincy Larson <[email protected]>
Mime-Version: 1.0
Message-ID: <WCzHdhazSMiNzhgRz1BR3Q@geopod-ismtpd-canary-0>
Subject: Learn to code your own Android app [free 12-hour Flutter course]
X-SG-EID: qqKWfKH8S6ww5f4Z/Fwe+77sswn9ye6zQUjvjMl/IwfG7uaAjBWAQlWPtd/UQb+OQ6FQ6w1MYG3IYX7hPJvayyfeWk4afp3iNC9QFnuEdijK73SA34hiXs7xHIbJj/7STbHZE4X0JnSkidtuFGKQM4TTKUYsp12iKQ+mTnX9nfChvtg2VaNIKE/NzXkfLR1qUJeYMyEDdtR5PO85qKPvm+1eWbIMIUnQfwaTMztCYJtrxQQJx0z/IjfbrSaBSwBbRQYeZCkHslJWzcvTnEA8Aw==
To: [email protected]
X-Entity-ID: pyT0OFmtKpSAhaUvIDgXrw==
I'm not a worldly person, so I'm looking at it through my personal lens, where plain text email was solving issues from 10-20 years ago.
I'd be interested in the reason for text-only. Reasons I can think of from many years past included spam, low bandwidth or featurephones on the recipient's end.
When I was messing around with https://github.com/freeCodeCamp/chapter/issues/2089 it reminded me of this discussion.
@naomi-lgbt what do you reckon to Jim's suggestion of multipart emails? It seems to be the best of both worlds, but this definitely not my strong suit.
I believe HTML emails are still more likely to get caught in the spam detection, but as long as we're careful we should be fine.
I'm still of the mind to go for the multipart and adjust if needed.
GitHub and others with broad, global audiences seem to use multi-part emails with text and HTML mixed content.
The biggest issue with spam is not having SPF and/or DKIM records set and I believe for MVP you'll be using Sendgrid.
In order to setup Sendgrid, and other transactional email services, they typically require DKIM signatures in the DNS for validation, which tends to keeps things out of spam as long as you're not doing anything spammy.
We do have the SPF, DKIM, and DMARC records all configured, yes.
Okay, cool. Multipart does sound like the way to go. I'll edit the title and OP to reflect that.