Added a couple of blogs and tidy categories

Jonathan Hodgson 2 years ago
parent 72c1b072cc
commit 39791363fa
  1. 2
  2. 2
  3. 288
  4. 200

@ -3,7 +3,7 @@ title: 3 Simple Steps to Improve Your Freelance Business's Security
date: 2020-04-09
description: All too often, security advice is aimed at large companies who can afford to spend hundreds or thousands of pounds on security procedures. In this blog, I will try and lay out some advice for freelancers and small businesses can follow, without breaking the bank.
- Security Advice
- Security
All too often, security advice is aimed at large companies who can afford to spend hundreds or thousands of pounds on security procedures. What follows is hopefully advice that anyone can follow.

@ -6,7 +6,7 @@ description: |
can protect your own site against them.
date: 2020-09-05
- Security Advice
- Security
- Websites

@ -0,0 +1,288 @@
title: "Advent of Code: Day 1"
- Advent of Code
description: Day one of the Advent of Code
date: 2021-12-01
So, it's December all ready. I haven't written anywhere near as many blogs this
year as I would like to. Hopefully the [Advent of
Code]( this year will give me some things to
write about and make this years list of blogs look better.
This is the first year I am doing the Advent of Code so don't really know what
to expect. However, with day 1 done, I think I'll probably enjoy it.
If you're reading this, it is no longer day 1. I will refrain from publishing
the solutions until at least the day after they go live. However, if previous
years are anything to go by, you should still be able to view the puzzles and
have a go for yourself:
I am going to use the project puzzles this year to try and learn C. I have used
it a little bit but certainly wouldn't call myself proficient. This is supposed
to be a way for me to get better so if you're looking for well formed C code by
someone who knows what they are doing, you should probably look elsewhere.
My solutions are available here:
## Part 1
The first part of today's challenge involved taking a list of numbers and
counting the number of times a number is higher than the previous number.
The example they gave is with this list of numbers:
I put those in a text file called example.txt.
### Bash
I started by implementing it in bash. Why? Because I know bash and wanted to
make sure I had understood the problem before trying to battle with C.
#!/usr/bin/env bash
while read line; do
if [ "$line" -gt "$last" ]; then
increasing="$(( increasing + 1 ))"
done < <(cat "$file")
echo "$increasing were increasing"
There is not a huge amount going on here. If you are at all familiar with bash,
you can probably see what is going on here. I initially set up variables to hold
the file name (passed in as the first argument), a counter for the number of
times we increase from one line to the next and the value of the last line we've
seen that I initially set to a large number.
Then we enter the loop. It is worth noting that the loop had to be of the form:
while read line; do
# Do stuff
done < <(cat "$file")
Rather than:
cat "$file" | while read line; do
# Do stuff
The reason for this is that pipes are executed in a sub shell meaning they can't
change variables in the initial shell. In other words, with the second method,
we wouldn't be able to update the increasing and last variables from inside the
Inside the loop, I check to see if the current value is larger than the previous
value and if it is I increment the `increacing` variable by 1. I then set the
`last` variable so it can be used for the next iteration.
Finally, once all the lines have been done, I print out the number of lines that
were increasing.
### C
So, in a surprise to nobody, my C implementation is not as short as the bash
one. However, it wasn't as bad as I thought it would be.
Step 1 was trying to work out how to read a file in to c one file at a time.
Given that I knew the format of the lines, I was able to use fscanf to get each
of them.
Although the syntax is slightly different, the logic is very similar between the
Bash and C implementations.
#include <stdio.h>
int main( int argc, char *argv[] ){
if( argc == 2 ) {
unsigned int last = ~0;
unsigned int increasing = 0;
unsigned int value;
// Read the values into an array
FILE *fp=fopen(argv[1], "r");
while (!feof (fp)){
fscanf(fp, "%d\n", &value);
if ( value > last )
last = value;
printf( "%d were increasing\n", increasing );
return 0;
} else {
printf("You need to provide a file\n");
return 1;
## Part 2
The extension for part 2 was to change the program so that rather than comparing
lines with the previous line, the sum of 3 consecutive lines should be compared.
199 A
200 A B
208 A B C
210 B C D
200 E C D
207 E F D
240 E F G
269 F G H
260 G H
263 H
So, the sum of the numbers marked with A would be compared to the sum of those
marked with B. Then B with C and so on.
I think the intended way of doing this is to first create an array type
structure of sums then use the code from part 1 to work out how many of these
sums are increasing. However, a short cut can be taken. The sum of the next
group of numbers is always going to be the sum of the previous numbers plus the
next digit, minus the first. It follows therefore that we can compare the groups
by comparing the differences of every 3 numbers rather than adjacent numbers.
So, for example
$$ A = 199 + 200 + 208 $$
$$ B = 200 + 208 + 210 $$
We can confirm that group B increases from group A because 210 is greater than
In order to do this, I want to be able to easily reference individual entries by
their index so rather than doing the comparisons on the first pass through the
file, I first create an array. I can then compare an entry with the entry 3
before it.
### Bash
#!/usr/bin/env bash
readarray -t "arr" < "$file"
for i in $(seq 3 "$length"); do
prev3="${arr[$((i - 3))]}"
if [ -n "$curr" ] && [ "$curr" -gt "$prev3" ]; then
increasing="$((increasing + 1))"
echo "$increasing were increacing"
You'll see that bash has a nice built-in for turning a file into an array.
However, any bonus points it it might get for that, it looses by having the
worst syntax ever for getting the length of that array. Who thought that
`${#arr[@]}` would ever be a good idea‽
### C
#include <stdio.h>
int countLines(char filename[]){
FILE *fp;
fp=fopen(filename, "r");
long int lines =0;
if ( fp == NULL ) {
return -1;
while (EOF != (fscanf(fp, "%*[^\n]"), fscanf(fp,"%*c")))
return lines;
int main( int argc, char *argv[] ){
if( argc == 2 ) {
// 1 less because file ends with trailing new line
int lines=countLines(argv[1]);
int values[lines];
int line=0;
FILE *fp=fopen(argv[1], "r");
int increasing = 0;
// Read the values into an array
while (!feof (fp)){
fscanf(fp, "%d\n", &values[line]);
if ( (line >= 3) && (values[line] > values[line-3]) ){
fclose(fp); // closing file
printf( "Increasing: %d\n", increasing );
return 0;
} else {
printf("You need to provide a file\n");
return 1;
So this is obviously longer than the bash version but mainly because there isn't
a nice way of putting a text file into an array. I have to first iterate through
the file to determine how many lines there are, then allocate that much space for
the array, then re-run through the file to get the values.
Initially, I then had a third loop where I iterated through the newly created
array to determine if there was an increase. However, I then realised I could do
that whilst populating the array.

@ -0,0 +1,200 @@
title: "Multipart Emails in Neomutt"
- Mutt
description: Mutt now supports multipart email. I guess it will be easy to set it up right?
date: 2022-05-27
It recently came to my attention that mutt now supports sending multipart
emails. I thought that this would mean that in half an hour or so I would have
html emails working. Turns out, I was wrong. What instead happened was weeks of
trial and error and reading RFCs.
I now have a system I am happy with. I write an email in markdown and mutt
(along with some surrounding scripts) will convert that markdown to html, attach
inline images and create a multipart email.
## A note about HTML emails
If you do need to send HTML emails, please spare a thought for your recipient;
it is not just "weird" terminal email client users that could suffer. According
to the [National Eye Institute](,
one in twelve men are colour blind; so please don't use only colour to
distinguish items. Additionally, many people suffer from vision-loss blindness,
who are likely to use screen readers or braille displays. Complex layouts or
heavy use of images are going to give these people a poor experience.
That being said, HTML emails can be used for aesthetic purposes, whilst still
providing a plain text version for those who want it. That is the method I
suggest adopting if you need html emails, and the method this blog post will
## Multipart / Related emails
To begin with, we need to understand a little bit about how emails are
structured. Below is an example tree structure of a standard email.
Multipart Related
├─>Multipart Alternative
│ ├─>Plain Text Email
│ └─>HTML Email
└─>Inline Image Attachment
Non-Inline Attachment
Starting at the lowest level, we see a plain text email and an HTML email. These
are both wrapped in a multipart **alternative** wrapper. This tells email
clients receiving the email that they are alternative versions of the same
document. The email client will normally choose which to display based on the
mime type and user preferences.
The multipart alternative wrapper and an image attachment are then wrapped in a
multipart **related** wrapper. This tells the email client that the contents are
related to one another, but not different version of the same document. This is
where inline images are attached.
Finally, there is another attachment that is outside of the multipart related
wrapper. This will show up as another attachment but cannot be displayed inline.
## Neomutt Configuration
The conversion from markdown to html will be handled by an external script. It
will create files and instruct mutt to attach them.
We can start with the following:
macro compose Y "<first-entry>\
<enter-command>source /tmp/neomutt-attach-macro<enter>
We specify a macro to run when `Y` is pushed. First, we select the first entry.
This is in case we have attached anything manually, the first entry should be
the markdown file.
We then pipe the selected entry (the markdown file) to an external script, in
this case a bash script called `convert-multipart`. Finally we source a file
called `/tmp/neomutt-commands`. This will be populated by the script and will
allow us to group and attach files inside neomutt.
## Converting to HTML
Let's start with a simple pandoc conversion.
#!/usr/bin/env bash
cat - > "$markdownFile"
echo -n "push " > "$commandsFile"
pandoc -f markdown -t html5 --standalone --template ~/.pandoc/templates/email.html "$markdownFile" > "$htmlFile"
# Attach the html file
echo -n "<attach-file>\"$htmlFile\"<enter>" >> "$commandsFile"
# Set it as inline
echo -n "<toggle-disposition>" >> "$commandsFile"
# Tell neomutt to delete it after sending
echo -n "<toggle-unlink>" >> "$commandsFile"
# Select both the html and markdown files
echo -n "<tag-entry><previous-entry><tag-entry>" >> "$commandsFile"
# Group the selected messages as alternatives
echo -n "<group-alternatives>" >> "$commandsFile"
The above bash script will create an html file using pandoc, and create a file
of neomutt commands. This instructs neomutt to attach the html file, set its
disposition, and group the markdown and html files into a "multipart
alternatives" group.
Neomutt's attachment view should look something like this.
I 1 <no description> [multipa/alternativ, 7bit, 0K]
- I 2 ├─>/tmp/neomutt-hostname-1000-89755-7 [text/plain, 7bit, us-ascii, 0.3K]
- I 3 └─>/tmp/neomutt.html [text/html, 7bit, us-ascii, 9.5K]
## Inline attachments
The next part of the puzzle is inline attachments. These need to be attached and
then grouped within a multipart related group.
To reference the file from within the html email, each inline image needs a
unique cid. I use md5 sums for this. They are not cryptographically secure, but
for the purposes of generating unique strings for images in an email, they are
grep -Eo '!\[[^]]*\]\([^)]+' "$markdownFile" | cut -d '(' -f 2 |
grep -Ev '^(cid:|https?://)' | while read file; do
id="cid:$(md5sum "$file" | cut -d ' ' -f 1 )"
sed -i "s#$file#$id#g" "$markdownFile"
We loop through all the images in the markdown file, and replace the paths for
cids (assuming they are not already cids or remote images).
As the markdown has changed, we need to attach the new one and detach the old.
if [ "$(grep -Eo '!\[[^]]*\]\([^)]+' "$markdownFile" | grep '^cid:' | wc -l)" -gt 0 ]; then
echo -n "<attach-file>\"$markdownFile\"<enter><first-entry><detach-file>" >> "$commandsFile"
To attach the images, we loop through the original file and add to the file
neomutt sources. Neomutt will be instructed to attach, set the disposition, set
the content ID and tag the image.
grep -Eo '!\[[^]]*\]\([^)]+' "${markdownFile}.orig" | cut -d '(' -f 2 |
grep -Ev '^(cid:|https?://)' | while read file; do
id="$(md5sum "$file" | cut -d ' ' -f 1 )"
echo -n "<attach-file>\"$file\"<enter>" >> "$commandsFile"
echo -n "<toggle-disposition>" >> "$commandsFile"
echo -n "<edit-content-id>^u\"$id\"<enter>" >> "$commandsFile"
echo -n "<tag-entry>" >> "$commandsFile"
if [ "$(grep -Eo '!\[[^]]*\]\([^)]+' "$markdownFile" | grep '^cid:' | wc -l)" -gt 0 ]; then
echo -n "<first-entry><tag-entry><group-related>" >> "$commandsFile"
Finally, if there were any images attached, we select the first entry (the
multipart alternative we've already created), tag it and mark everything tagged
as multipart related.
I 1 <no description> [multipa/related, 7bit, 0K]
I 2 ├─><no description> [multipa/alternativ, 7bit, 0K]
- I 3 │ ├─>/tmp/neomutt-markdown [text/plain, 7bit, us-ascii, 0.3K]
- I 4 │ └─>/tmp/neomutt.html [text/html, 7bit, us-ascii, 9.5K]
I 5 └─>/tmp/2022-05-27T15-02-20Z.png [image/png, base64, 0.5K]
At this point, the user is free to attach additional, non inline documents as
normal. This email should be good for both text based and graphical email
For the full source changes, see [this commit](