Terracrypt

Email experiments: filtering out external images

2025-12-29T14:10:00Z

I had a realization the other day that, on almost every email in my inbox, my mail client has a "show external images" option. Most email I receive references externally loaded images via HTML. There are good reasons for this (not needing to send a copy of an image in every email on a newsletter) as well as nefarious reasons (the remote server can track where/when you load the image). So most mail clients I've used don't load them by default for obvious privacy reasons.

This got me thinking about the reverse, though: what email do I receive that does not include external images? And the answer is, mostly, email sent manually by a real human! I'm fairly certain I've never sent an email to another person in my personal life with an externally loaded image in it. When I have, it's been work email with a standard corporate email signature (that I'm sure was being tracked, natch). Mostly, when sending images to someone, they're sent as attachments to the email.

So I had a realization that, if I wanted to naturally filter email that was sent by hand from email sent from an automated system, this might be a decent proxy for that. Here's the sieve rule I landed on for now:

if body :regex "<img[^>]*src=\"https" {
  fileinto "Inbox.Automated";
}

(Yes, it's typically folly to regex on HTML. This is a simple enough match though that I hope it's fine!)

So far, after a day or so of usage, it's been shockingly effective. There's enough potentially important stuff in my Automated folder that I will need to check that fairly frequently, but the one email that's made it through this filter into my normal inbox is one sent by hand to a mailman list. Honestly, I'll take it! This makes the volume of email in my normal inbox much much more manageable, and I expect most mail that lands there will be things I actually do want to pay attention to.

Probably you'll want to have another rule that prevents you from running this for email from people in your contacts. I haven't done that yet, but that'll be a natural next step.

This is part of my December Adventure 2025 series.

Horton persistence progress

2025-12-27T12:03:00Z

I've gotten some work done towards supporting persistence in guile-horton over the last week or so, but I've hit a bit of a roadblock. Writing this up in part to explain what I've been working on and in part to think through it some more.

To support persistence, I need to switch all the actors in the system over to use the define-actor macro. The admin actor was previously using selfish-spawn, but define-actor has a #:self parameter that should serve the same purpose. And the old code was using an internal cell for the mutable name functionality, which needs to be changed.

However... running into one particular problem that I'm still having trouble figuring out. When I spawn an admin, that new object also spawns a profile with a reference to that admin. In order to support that, the admin needs to have a reference to itself; as mentioned above, I think I should be able to use a parameter on define-actor for that. But for some reason, the self parameter gets set to #<unspecified> when I try that. It's not clear to me why this might be happening from the docs, so I think I might need to do some source spelunking to figure it out.

Once I work that out, it looks like I'll run into this issue. It sounds like I should be able to work around that with a second object constructor, though it might be a bit messy.

This is part of my December Adventure 2025 series, which I haven't been as consistent with as I had hoped but has nudged me to work on this some at least! My adventure log for this year is here.

Making post tags actually visible

2025-12-21T11:22:00Z

I've got tags for all my blog posts, and tag-specific RSS feeds, but until now those tags/feeds haven't actually been visible unless you constructed the URL. So finally fixing that: now there's a list of tags at the top of each post, with a link to the tag-specific feed.

This isn't quite the ultimate behavior I was looking for - ultimately I'd like those links to go to human-readable tag-specific pages first, with a link to the RSS feeds from there. But I think that'll take a bit more work to get working. I have some machinery to generate human-readable tag pages for specific tags, but with the structure of my Haunt site it's a bit more complex to generate pages for every tag. I can do it, it'll just take some more thought.

I do have a page to act as my adventure log for this year, though! That's at the da2025 tag. It's still on my TODO list to make the RSS feed link on that page go to the per-tag feed ^^;

Hacking on my blogging workflow

2025-12-13T11:50:00Z

Starting December Adventure off with a little meta this year (and a bit late, whoops!). Since setting up this blog, it's always felt like a little too much friction to start a new blog post. It's not too bad, but it does involve creating a file in the posts directory with a given name, manually typing out the timestamp.

I'm always writing my blog posts in emacs anyway, and emacs is the most hackable of editors. So I figured, why not have a template to make things easier?

I'm a heavy user of org-capture to quickly add entries to my TODO list. Although my blog posts are markdown rather than org-mode (for now?), org-capture seemed flexible enough to do the job. And sure enough, it was!

It felt a little gross to do this, but I ended up setting a global variable for the post slug. I tend to use the slug as the filename of each post file, and I didn't want to be prompted for the slug twice. Org-capture can accept a function that controls the file path to capture to; having that function prompt me and save the result seemed like an okay solution.

(defun jfred/capture-blog-post ()
  (interactive)
  (let ((name (read-string "Post slug: ")))
    (setq jfred-capture-blog--slug name)
    (expand-file-name (format "%s.md"
                              name) "~/src/website/posts")))

After that, it was a matter of defining a plain org-capture template to start a new file when captured. I'll just show you all my capture templates so you have the new one in context:

(setq org-capture-templates
      '(("t" "Todo" entry (file "~/org/Inbox.org")
         "* TODO %?\n  %a")
        ("tn" "Todo - no link" entry (file "~/org/inbox.org")
         "* TODO %?")
        ("j" "Journal" entry (file+olp+datetree "~/org/journal.org")
         "* %?\nEntered on %U\n  %i\n  %a")
        ("b" "Blog post" plain (file jfred/capture-blog-post)
         "title: %^{title}
slug: %(format jfred-capture-blog--slug)
tags: 
date: %<%Y-%m-%d %H:%M:%S>
---
%?")
        ("m" "Meeting Notes" entry (file+olp+datetree "~/org/meetings.org")
         "* Meeting Notes - %?")))

(As an aside, I just realized while looking at these that the tn capture doesn't actually work and would be useful. Guess I'll fix that up soon!)

I can tell that the org-capture template system is really meant for templating org files, but it worked here. There's a template string representing a timestamp, but it defaults to the format that org-mode expects; if you want a timestamp in a specific format, you have to use more explicit formatting. But you can do that!

That's all for today. Today's the first day of my holiday break, so I hope to have more time to work on side projects for the rest of the month. My goal this holiday season is to get guile-horton finally supporting persistence. It's not very useful without it, but I did a few things that were perhaps a bit too clever when originally writing it, so it'll likely be annoyingly complicated to get that working. Fingers crossed!