Značky: #fax, #Network, #silly, #news

It's got a whole bunch of links to a whole bunch of useful things, things about

• Email strategy, design, accessibility, coding and QA;
• Email sending, data, learning career and community;
• And of course, links related to that thing I talk about all the time, deliverability! Teeing you up to learn more about ISP tools, deliverability vendors and associated suites of tools, authentication monitoring, other utilities, and certification vendors.

I reached out to Avi Goldman to ask him what inspired him to put Email Resources together. He said, "I'd been collecting resources for myself for a while and every so often I had an opportunity to share with other folks. I figured why not help people discover the right tools for them, especially when I had already compiled the list! I love being able to help the email community and publicize resources made by friends and folks I admire."

It's a sentiment that I appreciate and I'm very much thankful for Avi's effort here. I hope you'll feel the same way. Click on through here .

Značky: #neat, #sharing, #Network, #tools

I was talking to friends running an ESP platform the other day, helping them understand the difference between the available types of list unsubscribe support, what does it mean and how does it work. Might you find that interesting as well? Let's see.

List-unsubscribe: What is it? It's a hidden email header. Originally specified in RFC 2369 , the goal was to provide a hook that email clients could hook into, to display an unsubscribe option to subscribers in a way and place that was easy to find and common from message to message. I can't speak for the creators, but I imagine the goal is to make it easy for subscribers to unsubscribe, so that they don't turn to clicking the "report spam" button instead, out of frustration. TL;DR? Standardized method for declaring what an unsub button should do.

It's been around a while (the spec is dated 1998) but Gmail was the big adopter, rewarding good senders by displaying an unsub link in the Gmail UI, if the header was present. (Gmail actually sometimes displays the link even with no header present, for some big brands, to help drive display of the link more often. So if you see an "Unsubscribe" link in the Gmail UI, but there's no list-unsub header, that's why.) Sendgrid's got a good overview of the basics , and I published my own FAQ about this back in 2016 .

And then along came Apple's iOS 10, where they added (email based) support for list-unsub as well .

And as I've said before, distilling down guidance from Laura Atkins to just the TL;DR -- if you send marketing mail or if you're building a platform to serve up marketing mail, you NEED list unsubscribe support. The sending reputation of the customers sending from that platform are going to suffer without it.

That's the history. Now let's jump forward to today. There's a new-and-improved version of the standard outlined in RFC 8058 called "Signaling One-Click Functionality for List Email Headers" or what I tend to simply call "list unsubscribe post" because of what happens behind the scenes when the unsub button is pushed. The webmail makes a "POST" call back to the sending platform to pass the unsubscribe request. In theory, bots and security scanners won't make a POST request, preventing "false positive" unwanted unubscribes.

Tony Patti from Sparkpost put together a great overview (and a chart) in 2020 showing which ISPs support which method. It's something you should bookmark and use as your guide when building list-unsub and list-unsub post support into your sending platform. The one thing I'd update from that post is that I'm observing Microsoft's Outlook.com sending a list-unsubscribe POST response, but I think it might be malformed. It seemed to do it even when no list-unsubscribe-post header was present, and I'd recommend testing to make sure you can properly capture these unsubs requests.

It's clear to me that list-unsub-post is the future of embedded unsub functionality, but I don't think it's safe to implement it without also implementing the mailto: version, otherwise you'll lose the opportunity to receive opt-outs from Apple Mail users.

And finally, don't fear the unsubscribe. Chad White explained for the Litmus blog back in 2016 why List-Unsubscribe Concerns Are Overblown , and that guidance is still solid. Subscribers come and subscribers go. You ARE going to lose subscribers over time; they can't be locked down in any practical way -- trying to do so will only cause harm to a sender's reputation. Don't forget that list growth needs to be part of your marketing strategy. It's not simply that you "build a list" once and then you're done.

Značky: #ios, #wttw, #list-unsubscribe, #gmail, #Network

It's time for your periodic BIMI adoption status update.

A quick overview of what this is all about: BIMI is a standard being adopted by multiple internet services providers (ISPs) to allow the display of a sender's logo along side email messages, when displayed on a mobile device or in a webmail client. Some ISPs and mail clients have had a sender logo display function for a while now (one example is Gravatar ), but BIMI is an attempt to standardize and regulate this mechanism across the email ecosystem.

Adoption by senders seems a bit slow; but the spec only went public in 2019, which isn't that long ago. Also, it suffers a bit from the "chicken and egg" problem -- it's hard to convince senders to adopt the standard if receivers haven't adopted support for the standard. But now with two of the top three B2C mailbox providers (Yahoo and Gmail) having BIMI support, I'm guessing that we'll start to see more adoption of BIMI by senders.

Here's the current status of BIMI Support at large ISPs, email hosting and webmail providers:

1. Gmail: Yes, supports BIMI! Requires VMC. ( Find more info here .)
2. Yahoo (ex-Verizon): Yes, supports BIMI. Does not require VMC. ( More info here .)
3. Fastmail : Yes, supports BIMI! ( More info here .)
4. Considering BIMI Support: Comcast and Seznam.cz. ( More info here .)
5. Microsoft: Has no support for BIMI.

Gmail. In July 2020, Google announced their intent to support BIMI . In July 2021, Google announced that they were rolling out BIMI support over the coming weeks . Per the BIMI spec, Google requires that senders implement a Verified Mark Certificate (VMC), available from DigiCert or Entrust (and possibly others). It sounds like obtaining this VMC will require that a sender have trademarked their logo , which could be a significant barrier for smaller or hobbyist senders.

Yahoo (AOL/Yahoo/Verizon). Has support for BIMI. For a logo to display, the following conditions must be met: A BIMI record exists which points to a valid logo in SVG format, a DMARC policy of quarantine or reject is in place, the mailing is sent to large number of recipients (bulk mail), and they see sufficient reputation and engagement for the email address. They have a dedicated support page for BIMI and also have a contact address for questions/issues ( click here and search for "BIMI" on the page).

Microsoft Outlook.com (Hotmail). Microsoft has not announced any support for BIMI. A competing system called "brand cards" has likely been abandoned; multiple folks have told me that they have been unable to get enough information on how to implement a "brand card." There's no opportunity here at the present time, unfortunately. If that changes, I'll post an update.

So what should you do now? Here's what I would recommend large marketing senders do:

1. Make sure all email you send is authenticated with both SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) authentication. (All mail -- not just bulk or newsletter mail. Your ESP , corporate email platform (or both) should be able to help you do that.)
2. Implement DMARC, perhaps working with a vendor like dmarcian , Agari , Valimail , ProofPoint or Red Sift . (Disclaimer: I work for Kickbox , and we've got DMARC monitoring in our deliverability tool suite as well. I am a happy user of it myself!) Partnering with a vendor to provide monitoring and reporting helps you know whether or not it is safe to move on to the next step -- ensuring that you're not going to accidentally tell ISPs to block your legitimate mail.
3. Move to a restrictive "p=reject" DMARC policy after your DMARC reporting shows that you properly authenticate all of your mail streams. Don't do this just for the future logo opportunity -- do it because it makes it harder for bad guys to send fake mail pretending to be from your email domain name.
4. Trademark your logo and obtain a Verified Mark Certificate. Wondering what this whole VMC thing is all about? Here's a primer . Ready to obtain a VMC? You could go directly to DigiCert or Entrust, or look for help from Mailkit via their NOTAMIQ service or Red Sift.
5. Learn how to create the BIMI logo file. You can find more information here .
6. Understand that things are still developing. More ISPs could announce support in the future, and how they, or existing ISPs, will enforce the spec could evolve. Stay knowledgable and be flexible and be able to evolve.

Značky: #gmail, #microsoft, #bimi, #seznam, #comcast, #Network, #brandimage, #brandavatar, #verizon, #yahoo, #fastmail

Ohio broadband provider Buckeye Broadband is reporting that its bex.net email service is offline. If you're a sender, I recommend pausing all sends to bex.net (and any other domains pointing at mx*.buckeyecom.net, if possible) until you see an all clear message from the ISP posted here .

Toledo's 13ABC Action News reports that the issue is due to a ransomware attack .

Značky: #bex.net, #news, #isp, #Network, #downtime

Značky: #Network, #silly, #video, #telegram

This can be sub-optimal for senders, because this amounts to an email message with sections both " above the fold " and "below the fold" -- meaning that first bits of the content will display in the inbox upon initial view, and the second bits of the content won't display until the user tells Gmail to display it all by way of clicking in the appropriate place.

In my initial research on this topic, I found that everybody in the world advertises 102KB as the HTML limit before you hit the cut-off. Meaning, the common guidance says that if your HTML message source is significantly more than 102 kilobytes in size, clipping is likely to occur. Keep your HTML smaller than 102KB and then Gmail won't clip your email message. And folks are mostly right about that...read on.

I decided to do my own testing today and found the actual limit to be around 105KB (for me, anyway), and I noted that the limit can vary based on how your email message is encoded. Does your platform encode email messages using Quoted-Printable, Base64, or just leave the source of the email unencoded? All three methods are fairly common. Quoted-Printable and Base64 are broadly used to encode fancier email messages containing content with alternate character sets that can't reliably encoded in 7-bit ASCII . This encoding helps protect messages so that when decoded, they display properly for the recipient, but that encoding will increase the amount of space needed to store an email message in transit. Point being, you'd think that this means that with, say, a Base64-encoded message, the effective Gmail clipping limit could be lower than the advertised limit. I tested all three encoding methods to see if that were true. And I was surprised to find that it was not quite true! A Base64 encoded message actually had to have HTML source of more than 110KB in size before clipping occurred, a wiggle room of around 5KB more versus a Quoted-Printable encoded or unencoded message.

Doing the math to account for encoding differences is beyond my ability (my attempt to work it all out failed miserably), so instead, I will suggest that you don't need to worry about the intricacies of encoding and just aim for a limit of 102KB for your HTML source. That way, your content is likely below the cut-off limit for any type of common email encoding.

Here's two other fun facts to keep in mind:

This 102KB (or 105KB or whatever) limit is based on the HTML source, not the overall file size of the whole email message's raw source. Meaning that if you sent an email message using multi-part MIME with both a text part and HTML part, the limit would apply to the HTML part only , not a combination of the HTML part plus the text part plus the email headers. I personally confirmed this through a series of tests with differently sized text parts and HTML parts.

And finally, there are some situations where email messages "clip" at Gmail even if the content is significantly smaller than 102KB in size. Why? Smart folks figured out that this is because of Gmail tripping over unencoded extended characters in HTML source (think accented characters, the copyright symbol, and so on).

Značky: #Network, #gmail, #google, #clipping

For more information or to apply, click here .

Značky: #oracle, #Network

I have meditated upon my crystal ball, dear reader, to ask it to tell me what 2022 will look like in the realm of email deliverability, and here's what it has guided me to share with you.

First, Apple's MPP functionality really punched a big hole in the usefulness of open tracking, and 2022 is when this really will affect everybody hoping to track the email they send. Some email send platforms are taking note of MPP and changing how they do things; figuring out how to help you suppress those false opens and guiding you toward different measures and metrics to rely on in place of opens. But not all are doing the work to keep up. Is your send platform offering you ways to exclude the Apple false positive opens from your reporting? And if not, why not? This is going to be a very important question to ask in 2022. MPP took a bit of time to catch on, but rollout is broad now and it's going to be nigh universal next year. If it hasn't hit you yet, just wait. It won't be long.

Next, I'm going to toot my own horn here and say that Deliverability as a practice is thriving . It's not getting any easier to get to the inbox without help in the form of tools and consulting expertise. Good for me, since that's my day job! But it also means that those who said that said deliverability could be automated down to nothing were wrong; you do still need specialist guides (guides as in people) to navigate these trouble waters-- tools, too, but not just tools. And don't just take my word for it! Look at all of the deliverability consultant job postings we keep seeing ( including ones posted here ). Not only is email not dead, it is thriving, and deliverability is along for the ride, doing great.

A year ago I mentioned (among other things) that BIMI might be considered the next big thing . I am starting to see BIMI adoption grow, but I'm still seeing a lot of senders who haven't implemented BIMI. The VMC requirement is a significant barrier to entry, so it perhaps will not take off like the rocketship I initially thought it would, but BIMI adoption is going to continue to grow in 2022, and savvy senders should implement it, if they're able to. At worst, it's forward looking, waiting for other ISPs to catch up (as mostly on Gmail, Yahoo and Fastmail support the standard today). I do think that will happen, though.

There you have it, my mostly off-the-cuff comments about what I think the coming year will hold. Occasinoally I'm right, and often times I'm wrong. What do you think I've missed? Feel free to share your thoughts and feedback with me!

And regardless of what this year holds, I wish luck, happiness, health and success for all of you. Thank you kindly for being a reader of or subscriber to Spam Resource.

Značky: #Network