This past week, Stack Exchange changed the method of linking from its "weekly highlights" email, and the new url encoding scheme is onerous for command line use (at least for me).

I subscribe to several of the stackexchange mailing lists, read the content in mutt, and use either urlview or urlscan to open links of interest in emacs using emacs-w3m. (BTW, I'm grateful to the developers of the Stack Exchange API and sx.el for enabling me to post this question from an emacs interface).

Prior to this week, the urls in the emails were short and sensible, and were easy to identify and use with my workflow technique, mainly because links to questions included the cleartext title of a page's question.

However, this week's edition of "Unix & Linux Stack Exchange Newsletter - Wednesday, January 24, 2018" changed all that, and has left me puzzling how to continue to navigate directly from the email to a specific Stack Exchange url. The new links are 728 characters long, beginning with the form http://sg-links.stackoverflow.email/wf/click?upn= and continuing with what I'm guessing is base64 encoding.


  1. Consider reverting, or otherwise making the links text-friendly.
  2. Advise how I might easily use the current links.
  • Could you/someone put the complete link on the question for the rest who don't join the mailing list? Perhaps they could help... – Meta Andrew T. Jan 26 '18 at 7:19
  • That shouldn't be necessary. I don't want to cause third parties, ie. extra people, extra work when the knowledgeable and responsible party (some party within stackexchange management) should be reachable via this medium. – user1404316 Jan 26 '18 at 9:49
  • The same (or a very similar) change recently happened with some "New <tag> question ..." emails I had subscribed to. One of them is for the biology stackexchange site. And copying huge URLs indeed sucks :( (I'm using alpine to read my e-mail). – bli Apr 16 '19 at 12:35
  • @bli: Try using the latest version of urlscan, as downloaded from their github page github.com/firecat53/urlscan . The debian package is woefully out of date, and one of the many improvements in the package is its handling of many of these long links. I'll see if I can post a self-answer and accept it, for the benefit of others. – user1404316 Apr 16 '19 at 16:40
  • I never used urlscan (at least, not knowingly: I'm not the admin of the server on which I read mail with alpine). My "workflow" is the following: log to the server with ssh, read mail with alpine, display full URL using the "edit URL" command, copy-paste the URL bits with the mouse to the URL bar of my graphical browser, scrolling with the arrows in the alpine URL editor to display further bits as necessary. The longer the URL, the more painful the process. – bli Apr 16 '19 at 17:06
  • 1
    @bli: I have 3 ideas for your case: 1) perform your ssh from within a tmux session and use the tmux copy feature to copy the url lines in one shot, then paste to an editor to validate it's correct, then paste to your gui browser; 2) ssh from emacs, etc; 3) ask others on stackexchange (let me know and I may even post there). – user1404316 Apr 16 '19 at 21:48
  • @user1404316 Thanks for your suggestions. It seems that setting "Prefer Plain Text" in "Setup/Config/Viewer Preferences" in alpine has the effect of getting the clean and simple direct URL instead of the "sg-links" thing in the mails I recieve from stackexchange. – bli Apr 22 '19 at 17:39

We broke text-only email and that was only fixed yesterday evening. I suspect you're attempting to parse the HTML version of the newsletter. Text newsletters sent as of today will have shorter links...

Example content (from the meta.SE newsletter):

The link in the "possible rollback war" flag should be to the revision history, not the post (https://meta.stackexchange.com/landing/r/newsletter?cta=question&id=306100)
Currently when the system raises the "possible rollback war" flag it links to the post. This means that when we investigate we have to click through to the post, then click to view the revision  ...
[feature-request] [moderator-tools] [automatic-flags] [rollback-wars]
asked by ChrisF (https://meta.stackexchange.com/landing/r/newsletter?cta=user&id=59303) 19 votes
answered by Monica Cellio (https://meta.stackexchange.com/landing/r/newsletter?cta=user&id=162102) 4 votes

Hope that works better for your workflow?

| improve this answer | |
  • I won't be able to check until I receive the next newsletter, which will be next Monday (SuperUser) or Tuesday (Unix). In both cases, I think I should be parsing the text version of the newsletter, as I'm using mutt, a text-only mail client, so I will compare the sample content you posted to what I will receive. Thanks for the quick reply. I will mark this closed and accepted when I receive the next newsletter and can confirm. Your suspicion about it being the HTML version may have been because I posted Thursday about Tuesday's newsletter, before when you say the issue was fixed. – user1404316 Jan 26 '18 at 16:17
  • I just received this week's "SuperUser" newsletter, and for that newsletter the links for the HTML version are still in the new, long, unreadable, encoded format. The links for the text version are short, but now only include the question's number, and no longer the text of the questiion. At this point, I can manage if I only use program urlscan because that filter interleaves page text with the short version of the links, but still can not use program urlview because that filter uses the long encoded links without displaying any page text. – user1404316 Jan 30 '18 at 20:58
  • Tomorrow I should receive a copy of the "Unix" newsletter and can give you feedback about that. – user1404316 Jan 30 '18 at 20:58
  • Sorry for the long delay, but it has given me an opportunity to review two weeks of unix, superuser, and emacs newsletters. All have the same unsatisfactory status. All arrive with both text and html versions. The html version's links are the extremely long type with ~400 characters of encoded stuff, and totally unusable for mutt/urlview|urlscan. The text version's links are shorter, but also fail because links are enclosed in parentheses, and the closing parenthesis is not separated from the end of the url with a space. – user1404316 Feb 9 '18 at 14:48
  • From the silence on this page, it seems that I am alone in caring or being affected by this, so I hesitate ask for accommodation, but at the very least could the text-version newsletters place a space between urls and the closing parentheses? Or, not put the url in parentheses? – user1404316 Feb 9 '18 at 14:52
  • @user1404316 You are not alone (see my comment to your original question). – bli Apr 16 '19 at 12:37
  • @user1404316 I've tweaked the text-only newsletters to include spaces between the parens. Hopefully that works out better for you – Dean Ward Apr 16 '19 at 18:35
  • @DeanWard: Thanks. I hope it's of benefit to others. As I mentioned in my responses today to user @bli, at some point in the intervening 14 months, I discovered that the developer version of urlscan handles the closed parens and other issues. Your fix will certainly benefit at least those restricted to using debian packages. – user1404316 Apr 16 '19 at 21:54

I've had satisfactory results ever since upgrading to the latest version of package urlscan as distributed directly by the developer on github (https://github.com/firecat53/urlscan). Prior to that, I had been using the debian-ized package, which at this writing is ten point releases and over three years out-of-date.

Still, I would prefer sensibly short url's, without all the additions that give me a creepy sense of being under surveillance for my silly stackexchange interests.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .