With network maintenance coming up on one Marketo pod, I was asked whether any features wouldn’t be affected during the maintenance period.
First instinct: Nope. Everything uses the network, after all: outbound sends, SFDC sync, inbound LPs and forms, API calls and webhooks, etc. But one feature was unclear: unsubscribes driven by the List-Unsubscribe-Post SMTP header. Don’t think anyone looked into this before (like, anywhere).
As you probably know, MAPs like Marketo comply with major email providers’ List-Unsubscribe requirement for optimal inboxing. They include a List-Unsubscribe-Post=One-Click header, plus a List-Unsubscribe header with a unique <https:> URL. Optionally, the old-school <mailto:> URL can also be included. Here’s an example:
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://click.example.com/u/NDEwLVhPUi02NzMAAAGhsh1UUD4gY6H_B7Njx0Jc6yQJgFRnh79OM35fojpoyZioqvs37SuRJd8HZ1U99J58MdA5RZg=?emailAddress=NDEwLVhPUi02NzMAAAGhsh1UT80EfvxIOM_0IIgrb6o4XgtlEXp3uUVXGC4TOThaLUIpcA6xLX0YEMvmhz1c22mwu49ropgwa6olwA>, <mailto:GE4C2YJQNZRVAM3RIZIFE4TMJ5VGM3TQKZTT2PI=.315939.132780.9@unsub-sj.mktomail.com>Then, when someone clicks the Unsubscribe link in Gmail et al., the underlying client infrastructure (e.g. Gmail itself) sends an HTTP POST to the URL.[1] Marketo receives the POST request, flips Unsubscribed to true, and of course you see it in the Activity Log.
Works perfectly in daily operation, but I was curious what would happen if click.example.com didn’t respond affirmatively, either due to network downtime or explicit HTTP 4xx/5xx error. Would the client retry the HTTP POST method after some period of time, and when would it give up? Would it fall back to the SMTP method?[2]
Unfortunately — in line with my immediate Nope — my tests showed the client would never retry. Yet they would claim the person unsubscribed, which isn’t great:
They’re neither wrong nor right
List-Unsubscribe-Post is standardized in RFC 8058, which makes no mention of retries one way or the other. So it’s unfortunate for us on the MOps side, but you really can’t scream about it.
Dealing with it
One of our clients was concerned enough to have us implement a workaround. (Other clients weren’t so moved.😉) What we did: redirected the branding domain to a simple static webpage with webserver logs turned on and a message “Temporary maintenance: please refresh this page after 11am Pacific today.”
That lets us (1) replay all the unsubscribes ourselves after the maintenance period and (2) replay regular email clicks to see if there were enough missed clicks to merit a follow-up email to that group.
Notes
[1] If you’re curious, the POST looks like this:
POST /u/NDEwLVhPUi02NzMAAAGhuFmGynE1xSHPBcMa7aLZ4Ay0RYBJ-1qqgHq0fauXbb_GWMG25zB7jBG_mB0xvVrYDFKadNI=?emailAddress=NDEwLVhPUi02NzMAAAGhuFmGykdqCBuzmrzNKKwgr6KsTU73Wa3KuMuCm2Y4h2_v8IBCklTna92hF8EcH1pG51rSNsdN2SPdUzuVsw HTTP/1.1
Host: click.example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)
Content-Length: 26
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
List-Unsubscribe=One-Click[2] Ironically more resilient, since transient SMTP delivery failures are retried!