Browse Source

Merge pull request 'add a guide to explain email' (#10) from new_design into master

Reviewed-on: https://code.craig-james-stewart.co.uk/pmb00cs/craig.stewart.zone/pulls/10
master
pmb00cs 6 months ago
parent
commit
7348797ee1
  1. 2
      blog/feed/entries/atom
  2. 2
      blog/feed/entries/by_tag/sysadmin.xml
  3. 10
      guides/building-a-git-repo/finalising.html
  4. 6
      guides/building-a-git-repo/installdb.html
  5. 4
      guides/building-a-git-repo/installgitea.html
  6. 6
      guides/building-a-git-repo/installmail.html
  7. 6
      guides/building-a-git-repo/installweb.html
  8. 8
      guides/building-a-git-repo/other-considerations.html
  9. 18
      guides/building-a-git-repo/secure-start.html
  10. 4
      guides/index.html
  11. 73
      guides/what-is-email/delivery.html
  12. 69
      guides/what-is-email/index.html
  13. 69
      guides/what-is-email/mx.html
  14. 65
      guides/what-is-email/notcomplex.html
  15. 87
      guides/what-is-email/smtp.html
  16. 69
      guides/what-is-email/submission.html

2
blog/feed/entries/atom

@ -1,4 +1,4 @@
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.8.7">Jekyll</generator><link href="/blog/feed/entries/atom" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" /><updated>2021-01-03T13:43:53+00:00</updated><id>/blog/feed/entries/atom</id><title type="html">My Blog</title><subtitle>The Personal Blog of a Geek</subtitle><entry><title type="html">Happy New Year</title><link href="/blog/2021/01/03/happy-new-year.html" rel="alternate" type="text/html" title="Happy New Year" /><published>2021-01-03T13:42:00+00:00</published><updated>2021-01-03T13:42:00+00:00</updated><id>/blog/2021/01/03/happy-new-year</id><content type="html" xml:base="/blog/2021/01/03/happy-new-year.html">&lt;p&gt;I don’t have much to say for this post. But 2020 was a hell year for most of us, and despite the hope that is now present thanks to various developments I doubt anything is going to improve substantially for at least a few months. So I just wanted to say to anyone paying attention, we’ve survived 2020, we can get through the first few months of 2021, and lets all hope the light we can now see is the end of the tunnel, and not an oncoming train.&lt;/p&gt;</content><author><name>Craig Stewart</name><email>craig@craig-james-stewart.co.uk</email></author><category term="comment" /><summary type="html">I don’t have much to say for this post. But 2020 was a hell year for most of us, and despite the hope that is now present thanks to various developments I doubt anything is going to improve substantially for at least a few months. So I just wanted to say to anyone paying attention, we’ve survived 2020, we can get through the first few months of 2021, and lets all hope the light we can now see is the end of the tunnel, and not an oncoming train.</summary></entry><entry><title type="html">Further thoughts on Identity</title><link href="/blog/2020/09/20/further-thoughts-on-identity.html" rel="alternate" type="text/html" title="Further thoughts on Identity" /><published>2020-09-20T17:55:00+01:00</published><updated>2020-09-20T17:55:00+01:00</updated><id>/blog/2020/09/20/further-thoughts-on-identity</id><content type="html" xml:base="/blog/2020/09/20/further-thoughts-on-identity.html">&lt;p&gt;Some time ago I wrote a blog post asking the question &lt;a href=&quot;/blog/2019/06/16/who-are-you-really.html&quot; title=&quot;Who are you really?&quot;&gt;“Who are you really?”&lt;/a&gt; It didn’t come to any real conclusion, it only expressed the fact that it was a topic I had been thinking about. I didn’t immediately stop thinking about it, but it drifted out of the forefront of my thoughts to the point that I still haven’t really got a good conclusion. But I have been reminded of the topic recently by an article on LWN about &lt;a href=&quot;https://lwn.net/SubscriberLink/831401/4170e588cdfdfc7f/&quot; title=&quot;Key signing in the pandemic era&quot;&gt;issues Debian is facing with key signing&lt;/a&gt;. Now the issues that Debian is facing very much reflect the issues I had that led to my previous blog post. How do you trust an identity? What value does that identity hold in itself, and what value can you ascribe to associated details.&lt;/p&gt;
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.9.0">Jekyll</generator><link href="/blog/feed/entries/atom" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" /><updated>2021-01-23T19:34:09+00:00</updated><id>/blog/feed/entries/atom</id><title type="html">My Blog</title><subtitle>The Personal Blog of a Geek</subtitle><entry><title type="html">Happy New Year</title><link href="/blog/2021/01/03/happy-new-year.html" rel="alternate" type="text/html" title="Happy New Year" /><published>2021-01-03T13:42:00+00:00</published><updated>2021-01-03T13:42:00+00:00</updated><id>/blog/2021/01/03/happy-new-year</id><content type="html" xml:base="/blog/2021/01/03/happy-new-year.html">&lt;p&gt;I don’t have much to say for this post. But 2020 was a hell year for most of us, and despite the hope that is now present thanks to various developments I doubt anything is going to improve substantially for at least a few months. So I just wanted to say to anyone paying attention, we’ve survived 2020, we can get through the first few months of 2021, and lets all hope the light we can now see is the end of the tunnel, and not an oncoming train.&lt;/p&gt;</content><author><name>Craig Stewart</name><email>craig@craig-james-stewart.co.uk</email></author><category term="comment" /><summary type="html">I don’t have much to say for this post. But 2020 was a hell year for most of us, and despite the hope that is now present thanks to various developments I doubt anything is going to improve substantially for at least a few months. So I just wanted to say to anyone paying attention, we’ve survived 2020, we can get through the first few months of 2021, and lets all hope the light we can now see is the end of the tunnel, and not an oncoming train.</summary></entry><entry><title type="html">Further thoughts on Identity</title><link href="/blog/2020/09/20/further-thoughts-on-identity.html" rel="alternate" type="text/html" title="Further thoughts on Identity" /><published>2020-09-20T17:55:00+01:00</published><updated>2020-09-20T17:55:00+01:00</updated><id>/blog/2020/09/20/further-thoughts-on-identity</id><content type="html" xml:base="/blog/2020/09/20/further-thoughts-on-identity.html">&lt;p&gt;Some time ago I wrote a blog post asking the question &lt;a href=&quot;/blog/2019/06/16/who-are-you-really.html&quot; title=&quot;Who are you really?&quot;&gt;“Who are you really?”&lt;/a&gt; It didn’t come to any real conclusion, it only expressed the fact that it was a topic I had been thinking about. I didn’t immediately stop thinking about it, but it drifted out of the forefront of my thoughts to the point that I still haven’t really got a good conclusion. But I have been reminded of the topic recently by an article on LWN about &lt;a href=&quot;https://lwn.net/SubscriberLink/831401/4170e588cdfdfc7f/&quot; title=&quot;Key signing in the pandemic era&quot;&gt;issues Debian is facing with key signing&lt;/a&gt;. Now the issues that Debian is facing very much reflect the issues I had that led to my previous blog post. How do you trust an identity? What value does that identity hold in itself, and what value can you ascribe to associated details.&lt;/p&gt;
&lt;p&gt;This leads me to lean more and more towards the idea that we place too much value on a single physical body as the “true” identity, and all other aspects are chained to this. To an open source project the value of the identity isn’t in a warm body, but in the contributions they make. Now the discussion within the debian project appears to be headed that way, and this I think is the correct way to handle that. But this also raises a question of trust. Our society has largely developed systems of trust based around individual interactions, and it is easier to build trust if these interactions are face to face. Many would probably argue that this means I am wrong to like the movement away from chaining online digital identities to physical people, but I would like to suggest that fewer of our face to face interactions are the sort that should build trust, or are with the entities that we should be trusting. Banking is done increasingly online, and even when it isn’t the person at the bank you deal with is likely to have very little discretion to alter the possible outcomes much. Trusting the bank clerk works in the bank’s favour, but a trustworthy bank clerk doesn’t mean the bank is trustworthy. Similarly supermarkets, ISPs, Utility providers, etc, are all large organisations that manipulate our ingrained trust mechanisms to make it easier to take our custom, but they don’t build trust in us based on the individual interactions we have, but rather through data-mining done by credit reference agencies, and information about us on public record. This I think demonstrates that our current trust mechanisms have failed individuals, and we need to build new ones, and we may as well do so in a way that allows us to separate our identities, such that they can be trusted for what they are, and not who we are, or who we were.&lt;/p&gt;

2
blog/feed/entries/by_tag/sysadmin.xml

@ -1,4 +1,4 @@
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.8.7">Jekyll</generator><link href="/blog/feed/entries/by_tag/sysadmin.xml" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" /><updated>2021-01-03T13:43:53+00:00</updated><id>/blog/feed/entries/by_tag/sysadmin.xml</id><title type="html">My Blog</title><subtitle>The Personal Blog of a Geek</subtitle><entry><title type="html">Migrating my blog workflow to WSL</title><link href="/blog/2020/08/02/migrating-to-wsl.html" rel="alternate" type="text/html" title="Migrating my blog workflow to WSL" /><published>2020-08-02T21:30:00+01:00</published><updated>2020-08-02T21:30:00+01:00</updated><id>/blog/2020/08/02/migrating-to-wsl</id><content type="html" xml:base="/blog/2020/08/02/migrating-to-wsl.html">&lt;p&gt;I’m a Linux systems administrator. This means I am not as skilled at supporting and maintaining windows based systems as I am Linux systems. As such my personal laptop has Debian installed, and I have a number of Debian servers (some hosted at a VPS provider, some at home). I also have a Desktop that I built myself, using high spec components (at the time). As the desktop was intended to be used for gaming I bought a Windows license for it. At the time the intent was to install Debian, and then create a KVM virtual machine to run Windows in. However out of impatience, laziness, and hubris (I could always fix it later right?) I installed windows directly onto the system drive. And now the hinge on my laptop lid is broken. As my blog is split across two git repositories (one private, and one public) and publishing new posts involves a workflow that requires me to use a number of linux based systems this is a sub-optimal state of affairs.&lt;/p&gt;
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.9.0">Jekyll</generator><link href="/blog/feed/entries/by_tag/sysadmin.xml" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" /><updated>2021-01-23T19:34:09+00:00</updated><id>/blog/feed/entries/by_tag/sysadmin.xml</id><title type="html">My Blog</title><subtitle>The Personal Blog of a Geek</subtitle><entry><title type="html">Migrating my blog workflow to WSL</title><link href="/blog/2020/08/02/migrating-to-wsl.html" rel="alternate" type="text/html" title="Migrating my blog workflow to WSL" /><published>2020-08-02T21:30:00+01:00</published><updated>2020-08-02T21:30:00+01:00</updated><id>/blog/2020/08/02/migrating-to-wsl</id><content type="html" xml:base="/blog/2020/08/02/migrating-to-wsl.html">&lt;p&gt;I’m a Linux systems administrator. This means I am not as skilled at supporting and maintaining windows based systems as I am Linux systems. As such my personal laptop has Debian installed, and I have a number of Debian servers (some hosted at a VPS provider, some at home). I also have a Desktop that I built myself, using high spec components (at the time). As the desktop was intended to be used for gaming I bought a Windows license for it. At the time the intent was to install Debian, and then create a KVM virtual machine to run Windows in. However out of impatience, laziness, and hubris (I could always fix it later right?) I installed windows directly onto the system drive. And now the hinge on my laptop lid is broken. As my blog is split across two git repositories (one private, and one public) and publishing new posts involves a workflow that requires me to use a number of linux based systems this is a sub-optimal state of affairs.&lt;/p&gt;
&lt;p&gt;So the work flow as it is involves the private git repository, which contains my site as a jekyll site. This is checked out on my laptop, and I make edits using vim. I use jekyll to serve a version of this site on localhost whilst I am making changes to ensure I am happy with how it looks (well as happy as I can be given the design, I still need to work on that). These changes are then built to a directory that is a copy of the public repository also checked out on my laptop, but on a non-default branch. I then commit these changes, push them to my git server and raise a pull request. Once the pull request is merged the changes are pushed to the servers. Now I recognise that this is a slightly clunky workflow, and I could probably improve it with a little effort. But it works for me, on Linux, that I am used too. Now that my laptop is broken (actually I’ve fixed it, but the fix is temporary at best) I should probably get this workflow working somewhere that is usable.&lt;/p&gt;

10
guides/building-a-git-repo/finalising.html

@ -47,13 +47,13 @@ My Blog
<div class="wrapper">
<p>First off gitea will try to validate the SSL certificate we are using for postfix, but this is a self signed cert, and not valid for “localhost” so we need to patch the config file to not validate this certificate.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo sed -i.bak '/mailer/a\
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo sed -i.bak '/mailer/a\
SKIP_VERIFY = true' /etc/gitea/app.ini
</code></pre></div></div>
<p>Then we need to make gitea a service that will start when we start the server.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cat &lt;&lt; EOF | sudo tee -a /etc/systemd/system/gitea.service &gt; /dev/null
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cat &lt;&lt; EOF | sudo tee -a /etc/systemd/system/gitea.service &gt; /dev/null
[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
@ -93,7 +93,7 @@ sudo systemctl start gitea
<p>And finally we are using fail2ban to block IP addresses that are making too many failed logins over SSH from being able to brut force passwords, but now we have set up a server that allows logins over HTTPS, so we should block those too.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cat &lt;&lt; EOF | sudo tee -a /etc/fail2ban/filter.d/gitea.conf &gt; /dev/null
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>cat &lt;&lt; EOF | sudo tee -a /etc/fail2ban/filter.d/gitea.conf &gt; /dev/null
# gitea.conf
[Definition]
failregex = .*Failed authentication attempt for .* from
@ -115,12 +115,12 @@ sudo service fail2ban restart
<p>We should now have a working git server. If you set up an Admin user when configuring gitea in the previous steps then we are set. If not you should register a user now, as the first registered user will become admin. The only remaining step before our server is ready is to automate the renewal of our SSL certificate.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo crontab -e
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo crontab -e
</code></pre></div></div>
<p>This will create an empty crontab for root, and open it in the default editor. As an invalid crontab will stop cron from working properly this command will validate what you save before installing it to cron. You will need to add a line like the below to the end of the file and save it.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>21 05 * * * /usr/bin/certbot renew --manual-auth-hook /root/certbot/auth.sh --manual-cleanup-hook /root/certbot/clean.sh --renew-hook /root/certbot/renew.sh --manual-public-ip-logging-ok --quiet
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>21 05 * * * /usr/bin/certbot renew --manual-auth-hook /root/certbot/auth.sh --manual-cleanup-hook /root/certbot/clean.sh --renew-hook /root/certbot/renew.sh --manual-public-ip-logging-ok --quiet
</code></pre></div></div>
<p>This will need to be on a single line without the quotes, and will run the certbot command at 05:21 every day, which will check the expiry of your certificate, and renew it and restart apache if it is about to expire. Feel free to change the time it runs, Lets Encrypt won’t want everyone trying to get certificates at the same time.</p>

6
guides/building-a-git-repo/installdb.html

@ -47,18 +47,18 @@ My Blog
<div class="wrapper">
<p>Now we have a webserver for allowing incoming connections, and a mail server for sending out emails, we need a database for gitea to store information. For this we will use <a href="https://mariadb.org/" title="MariaDB">MariaDB</a>.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install mariadb-client mariadb-server
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install mariadb-client mariadb-server
sudo mysql_secure_installation
</code></pre></div></div>
<p>This will install MariaDB, and then run a script to make the database more secure. Initially the root password is blank, so simply press enter when asked, you will then be asked if you want to set a root password, which we shall do. You should then set a secure password (I still recommend using a password manager to generate and store secure passwords for you) for the root user. Once you have set, and confirmed the new root password you should select yes for all the remaining options. The password you set is not actually used, as MariaDB sets the root user to authenticate using unix sockets, but if we dump all the databases and import into an older version, or MySQL, having this password set will still allow us to use the database should we need too. We will now need to create a database and user for git.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo mysql
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo mysql
</code></pre></div></div>
<p>This will get us to a database prompt as our database root user, where we need to issue the following commands.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>CREATE DATABASE gitea;
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>CREATE DATABASE gitea;
CREATE USER 'gitea'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON gitea.* to 'gitea'@'localhost';
FLUSH PRIVILEGES;

4
guides/building-a-git-repo/installgitea.html

@ -47,7 +47,7 @@ My Blog
<div class="wrapper">
<p>We have most of the prerequisites installed for gitea, and we could download the binary and run it as we are, but we want this to be a daemon (a process that runs in the background, and doesn’t need an interactive shell open to run in) so we need to create a system user for it, and set it up as a service. We will also need to create the config files, and directory structure that Gitea expects. (most of the following is taken from the documentation at <a href="https://docs.gitea.io/en-us/" title="Gitea Documentation">Gitea’s documentation pages</a> with a few minor tweaks)</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install git
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install git
sudo adduser \
--system \
--shell /bin/bash \
@ -87,7 +87,7 @@ sudo -u git /usr/local/bin/gitea web -c /etc/gitea/app.ini
<p>The remaining Settings are your choice, click install Gitea and the config file will be created and Gitea will be configured. Once done the gitea process will stop, and we need to make the config secure.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo chmod 750 /etc/gitea
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo chmod 750 /etc/gitea
sudo chmod 644 /etc/gitea/app.ini
</code></pre></div></div>

6
guides/building-a-git-repo/installmail.html

@ -49,12 +49,12 @@ My Blog
<p>As with the web server we’re not planning to do anything too complex with our mail server, but this is much more significant in this case. We do not need to accept smtp connections from outside, or root mail to local folders, indeed doing so would be a bad thing if we didn’t also have a way of reading those emails. So my choice of mail server in this case is also based upon what I am familiar with, and there are alternatives that could almost certainly do the job just as well. With that in mind we shall install <a href="http://www.postfix.org/" title="The Postfix Home Page">Postfix</a>.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install postfix
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install postfix
</code></pre></div></div>
<p>This will bring up a menu asking what sort of mail service we want, the various options will all start with different configurations that best match the option you pick. As we are configuring this server to send emails to the internet the best matching option is “Internet Site”. When you pick this option you will be asked to put in a domain name, this should be the FQDN of the server “git.example.com” in this guide (don’t actually use “git.example.com” as you could upset people). In theory we now have a working mail server, in practise we don’t allow outside connections, and we need to tell the mail server where to deliver mail for local users. For this we are going to edit the main aliases file.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo truncate /etc/aliases --size=0
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo truncate /etc/aliases --size=0
cat &lt;&lt; EOF | sudo tee -a /etc/aliases &gt; /dev/null
# See man 5 aliases for format
postmaster: user@example.com
@ -68,7 +68,7 @@ echo "user@example.com" &gt; ~/.forward
<p>This will empty the default aliases file, and then put some defaults that are needed into it and generates the alias database that postfix uses with those entries in, and then make sure our local user’s emails will also get forwarded. This assumes the email address “user@example.com” exists, you should use a valid email address in it’s place. We will also need to ensure that emails generated for our user get forwarded to a valid email address. This is all we need to do to get our mail server working. However with the settings as they are now we will not use TLS encryption to send emails if it is available, fortunately this is easy to fix.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo postconf smtp_tls_security_level=may
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo postconf smtp_tls_security_level=may
</code></pre></div></div>
<p>Our mail server is now set up for use. Note that what we are using here is overkill for what we want, but is also terribly poor for an actual mail server that accepts and delivers emails. However as we have blocked incoming connections to port 25 using iptables in <a href="secure-start.html" title="Starting With a Secure Base">Starting With a Secure Base</a> this shouldn’t be a problem for us.</p>

6
guides/building-a-git-repo/installweb.html

@ -53,7 +53,7 @@ My Blog
<p>Now we are ready to install and configure our web server software. I am going to use <a href="https://httpd.apache.org/" title="The Apache HTTP Server Project">Apache HTTPD</a> as it is what I am most comfortable with, however it shouldn’t be too difficult to adjust these instructions to use <a href="http://nginx.org/" title="nginx">nginx</a> or any other web server you wish to use. We’re not doing anything too complicated. I’m also going to be using <a href="https://certbot.eff.org/" title="certbot">certbot</a> to get free SSL certificates from <a href="https://letsencrypt.org/" title="Let's Encrypt">Let’s Encrypt</a>.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install apache2 certbot
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install apache2 certbot
sudo a2dissite 000-default.conf
cat &lt;&lt; EOF | sudo tee -a /etc/apache2/sites-available/git.example.com.conf &gt; /dev/null
&lt;VirtualHost *:80&gt;
@ -112,7 +112,7 @@ sudo apache2ctl restart
<p>Before we get our free SSL cert we want to control how it validates that we own the domain we are requesting a certificate for, and then we want to request our certificate.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo mkdir /root/certbot
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo mkdir /root/certbot
cat &lt;&lt; EOF | sudo tee -a /root/certbot/auth.sh &gt; /dev/null
#!/bin/bash
mkdir -p /var/www/acme-challenge
@ -136,7 +136,7 @@ sudo certbot --manual-auth-hook /root/certbot/auth.sh\
<p>This last command will ask you for an email address that will be used to send reminders if your certificate is about to expire, we will prevent that later on in the guide, or if there are urgent problems, I suggest using a valid email address for this reason. It will also ask you to agree to Let’s Encrypts terms, and if you are OK with your IP address being logged. Assuming that you agree and accept that your IP will be logged (the IP of your server that is) then you will get an SSL certificate. So now we need to enable some modules for apache and restart it so that our reverse proxy works.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo a2enmod proxy proxy_http ssl headers remoteip
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo a2enmod proxy proxy_http ssl headers remoteip
sudo apache2ctl restart
</code></pre></div></div>

8
guides/building-a-git-repo/other-considerations.html

@ -55,7 +55,7 @@ My Blog
<p>So you have a user account that you ssh too, and that account is using a secure password (hopefully). However ssh keys are a more secure way of authenticating against a host. To set up ssh key based authentication on your local host you need to generate an ssh public and private key pair, how will depend on your platform of choice. Then when you log into your server you will need to create an authorized_keys file using the folowing comands</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>mkdir ~/.ssh
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>mkdir ~/.ssh
touch ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh
@ -67,7 +67,7 @@ chmod 600 ~/.ssh
<p>The clock on any computer can drift away from the actual time, and for most purposes as long as the time the computer thinks it is progresses forwards, and is reasonably close to the current time nothing is going to go wrong. However keeping the clock accurate isn’t particularly difficult, and there are circumstances where it may be important that it is, especially with something that may be coordinating a distributed software repository. If you have followed this guide you may have noticed that we allowed something called NTP in our iptables rules right at the start. NTP is a protocol for keeping the clocks of computers in sync. Fortunately for us this includes networks like the internet. Volunteers open up their accurate clocks to use by the rest of the internet in pools, and we are going to take advantage of that by installing ntp.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install ntp
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install ntp
</code></pre></div></div>
<p>It’s that simple, our computer will now keep it’s clock accurate</p>
@ -76,7 +76,7 @@ chmod 600 ~/.ssh
<p>If you’ve fully followed this guide you should now have a working git server, however software is not perfect and over time bugs will be found and fixed in the packages running on our server, and in the gitea binary we are running. It would be a good idea to be notified when these changes are available to install so that we can keep our server up to date. For the debian packages I use apticron to inform me via email when updates are available.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install apticron
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo apt-get install apticron
cat &lt;&lt; EOF | sudo tee -a /etc/apt/apt.conf.d/10periodic &gt; /dev/null
APT::Periodic::Enable "1";
APT::Periodic::Update-Package-Lists "1";
@ -87,7 +87,7 @@ sudo sed -i 's/EMAIL="root"/EMAIL="user@example.com"/' /etc/apticron/apticron.co
<p>This will send an email to user@example.com once a day if there are any updates available. You should substitute user@example.com for a valid email address. Unfortunately as we have installed gitea from binary this will not update gitea. You will need to download the latest binary and replace the one on disk when it becomes available, if you follow <a href="https://blog.gitea.io/" title="Gitea Blog">the gitea blog</a> they announce new releases. At the time of writing the latest version was 1.13.0, but if when you follow this guide a newer version is available you should use that instead. To update gitea when a new version is available you need to stop gitea, and replace the binary on disk and restart gitea.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo service gitea stop
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>sudo service gitea stop
VERSION=1.13.0 wget -O gitea https://dl.gitea.io/gitea/$VERSION/gitea-$VERSION-linux-amd64
sudo rm /usr/local/bin/gitea
sudo chown root:root gitea

18
guides/building-a-git-repo/secure-start.html

@ -47,34 +47,34 @@ My Blog
<div class="wrapper">
<p>So to start we need a hosted server, I’m using a virtual private server from <a href="https://www.linode.com/" title="SSD Cloud Hosting &amp; Linux Servers - Linode">Linode</a>, but any suitable hosting provider will do. Linode includes a number of Operating Systems you can install with one touch, and I’m using their Debian 9 image, so installing Debian is outside the scope of this guide. Our first steps once the server is built should be to make sure that it is reasonably secure, so first turn off access to the root user over ssh using a password (I’m not happy that the default setting has this set to yes, but given the base image doesn’t include any none system user accounts it’s a compromise) by editing /etc/ssh/sshd_config and changing the line</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>PermitRootLogin yes
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>PermitRootLogin yes
</code></pre></div></div>
<p>to</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>PermitRootLogin no
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>PermitRootLogin no
</code></pre></div></div>
<p>and restart the ssh daemon</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>service ssh restart
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>service ssh restart
</code></pre></div></div>
<p>Then add a user so that you can get onto the server without having to login as root.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>useradd user
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>useradd user
</code></pre></div></div>
<p>This will prompt you for the new user’s password, this should be a good strong password, I suggest using a password manager for this, I use <a href="https://keepass.info/" title="KeePass Password Safe">KeePass</a> (also you don’t have to use “user” as the username, that’s just an example).</p>
<p>Now is a good time to install some packages for security, fail2ban to stop our user password being cracked by brute forced, iptables to protect us from opening services unexpectedly, and iptables-persistent to allow the rules we set to persist over reboots.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>apt-get install fail2ban iptables iptables-persistent
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>apt-get install fail2ban iptables iptables-persistent
</code></pre></div></div>
<p>The default settings for fail2ban on debian protect ssh, but we will add new settings later, iptables default settings are quite permissive however so these will need changing. The following commands will set what I expect to be a reasonably secure set of rules, blocking lots of incoming and outgoing network connections we don’t want, whilst allowing those that we do.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>iptables -F
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>iptables -F
ip6tables -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
@ -126,13 +126,13 @@ ip6tables-save &gt; /etc/iptables/rules.v6
<p>Because we built our server from an image provided by our hosting provider we need to ensure that everything is up to date.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>apt-get update
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>apt-get update
apt-get upgrade
</code></pre></div></div>
<p>Up till now we have been logged in as root, and run all our commands as root, but once we log off we cannot log back in as root, we saw to that earlier. We can log in as our user, and use the command su to escalate our session to root, but that isn’t the most secure way to manage our server, so next we need to install sudo, and configure it to allow our user to run commands as root.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>apt-get install sudo
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>apt-get install sudo
usermod -aG sudo user
</code></pre></div></div>
@ -140,7 +140,7 @@ usermod -aG sudo user
<p>Now that we have everything up to date, and an unprivileged user now is a good time to log off, and restart the server to make sure all the running processes are using the up to date packages, this is an important step if their were kernel updates.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>shutdown -r now
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>shutdown -r now
</code></pre></div></div>
<p>This will restart the server, and log us off. After a couple of minutes you should be able to ssh to the server as the user we have set up, and granted sudo rights too.</p>

4
guides/index.html

@ -45,10 +45,12 @@ My Blog
<div id="content">
<main class="page-content" aria-label="Content">
<div class="wrapper">
<p>These guides are intended for people who understand what they are doing with web hosting, and have experience of managing linux servers. I do not offer guarantees of completeness or security on the end results. Follow them at your own risk.</p>
<p>I have written a guide on how to set up a git server, and an explainer on how email works.</p>
<p><a href="building-a-git-repo" title="Building A git Repository Server">Building A git Repository Server using Gitea on Debian</a></p>
<p><a href="what-is-email" title="An Overview of Email, and how it works">An Overview of Email, and how it works</a></p>
</div>
</main></div>

73
guides/what-is-email/delivery.html

@ -0,0 +1,73 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" href="/styles/default.css">
<link rel="stylesheet" href="/styles/blog.css">
<title>Getting a message</title><link type="application/atom+xml" rel="alternate" href="/blog/feed/entries/atom" title="My Blog" /></head>
<body><div id="wrapper">
<div id="header">
<h1>
Getting a message
</h1>
</div>
<div id="layout">
<div id="navigation">
<p class="link">
<a href="/index.html">
Home
</a>
</p>
<p class="link">
<a href="/about.html">
About Me
</a>
</p>
<p class="link">
<a href="/contact.html">
Contact Me
</a>
</p>
<p class="link">
<a href="/guides/">
Guides
</a>
</p>
<p class="link">
<a href="/blog/">
My Blog
</a>
</p>
</div>
<div id="content">
<main class="page-content" aria-label="Content">
<div class="wrapper">
<p>So <em>bob</em> has sent his message to <strong>fairynet</strong>, and <strong>fairynet</strong> has managed to get the message to <strong>dragonnet</strong>. But how does <em>penny</em> get that message?</p>
<p>Well the last MTA that accepts mail for <strong>dragonnet</strong> will hand that message to a Mail Delivery Agent (MDA), it is this program that is responsible for storing the messages in a mailbox for <em>penny</em> and allowing <em>penny</em>’s MUA to collect those messages. Up until know the process has been one where the message get’s pushed to the next hop, but once the MDA has placed the message in <em>penny</em>’s mailbox the message must be pulled out for <em>penny</em> to read it.</p>
<p>There are two main ways for a message to get from the mailbox to the user’s MUA. The MDA is responsible for handling whichever the user uses.</p>
<p>One is Post Office Protocol version 3 (POP3). Using this the MUA accepts the messages and stores them locally (earlier versions of Post Office Protocol exist, but are not in wide use anymore).</p>
<p>The other is Internet Message Access Protocol (IMAP). Using this the MUA reads the messages, but they are stored in the mailbox controlled by the MDA.</p>
<p>In both cases the MUA connects to the MDA and pulls the messages when it is ready for them rather than the MDA pushing the messages out.</p>
<p>If <em>penny</em> chooses to respond the whole process starts again, <em>penny</em>’s MUA submits the response to <strong>dragonnet</strong>’s MSA, a series of MTAs get the message to <strong>fairynet</strong> and <strong>fairynet</strong>’s MDA puts the message in <em>bob</em>’s mailbox for <em>bob</em>’s MUA to retrieve.</p>
<div id="guide-navigation">
<a href="submission.html">Sending a message</a> | <a href="./">Main Page</a>
</div>
</div>
</main></div>
</div>
</div>
</body>
</html>

69
guides/what-is-email/index.html

@ -0,0 +1,69 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" href="/styles/default.css">
<link rel="stylesheet" href="/styles/blog.css">
<title>An Overview of Email, and how it works</title><link type="application/atom+xml" rel="alternate" href="/blog/feed/entries/atom" title="My Blog" /></head>
<body><div id="wrapper">
<div id="header">
<h1>
An Overview of Email, and how it works
</h1>
</div>
<div id="layout">
<div id="navigation">
<p class="link">
<a href="/index.html">
Home
</a>
</p>
<p class="link">
<a href="/about.html">
About Me
</a>
</p>
<p class="link">
<a href="/contact.html">
Contact Me
</a>
</p>
<p class="link">
<a href="/guides/">
Guides
</a>
</p>
<p class="link">
<a href="/blog/">
My Blog
</a>
</p>
</div>
<div id="content">
<main class="page-content" aria-label="Content">
<div class="wrapper">
<p>This guide is going to be an attempt to explain what email is, and how it works in a way that should be understandable to those with no previous technical understanding. This is not intended as a technical guide for running an email service, but more a primer on what email is.</p>
<p>I’m going to break this up into separate pages so as to make it easier to read and digest.</p>
<p><a href="notcomplex.html" title="Email isn't that complicated">Email isn’t that complicated</a></p>
<p><a href="smtp.html" title="Moving a message between computers">Moving a message between computers</a></p>
<p><a href="mx.html" title="Finding where to send the message">Finding where to send the message</a></p>
<p><a href="submission.html" title="Sending a message">Sending a message</a></p>
<p><a href="delivery.html" title="Getting a message">Getting a message</a></p>
</div>
</main></div>
</div>
</div>
</body>
</html>

69
guides/what-is-email/mx.html

@ -0,0 +1,69 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" href="/styles/default.css">
<link rel="stylesheet" href="/styles/blog.css">
<title>Finding where to send the message</title><link type="application/atom+xml" rel="alternate" href="/blog/feed/entries/atom" title="My Blog" /></head>
<body><div id="wrapper">
<div id="header">
<h1>
Finding where to send the message
</h1>
</div>
<div id="layout">
<div id="navigation">
<p class="link">
<a href="/index.html">
Home
</a>
</p>
<p class="link">
<a href="/about.html">
About Me
</a>
</p>
<p class="link">
<a href="/contact.html">
Contact Me
</a>
</p>
<p class="link">
<a href="/guides/">
Guides
</a>
</p>
<p class="link">
<a href="/blog/">
My Blog
</a>
</p>
</div>
<div id="content">
<main class="page-content" aria-label="Content">
<div class="wrapper">
<p>So we know how <strong>fairynet</strong> talks to <strong>dragonnet</strong> to send a message. But How does <strong>fairynet</strong> know where to send the message too?</p>
<p><strong>fairynet</strong> has to lookup where <strong>dragonnet</strong> is, and it does this by asking the Domain Name System (DNS for short) where <strong>dragonnet</strong> emails get delivered, this is a special type of DNS record called a Mail eXchange (or MX) record. <strong>dragonnet</strong> may not accept it’s emails directly. It may have another system accept it’s messages, to protect it from malicious actors, or from junk messages, or simply because it’s too small to handle the load of dealing with lots of separate connections for accepting messages.</p>
<p>So <strong>fairynet</strong> finds out the <strong>dragonnet</strong> emails need to be sent to <strong>mailfilternet</strong> from the DNS MX records, and gets an address for <strong>mailfilternet</strong>.</p>
<p>Now <strong>fairynet</strong> will still have the same conversation as we lined out on the last page, but it has it now with <strong>mailfilternet</strong>, and <strong>mailfilternet</strong> will have been told where it needs to find <strong>dragonnet</strong> to deliver the messages onward, and so now <strong>mailfilternet</strong> will go through the conversation with <strong>dragonnet</strong> itself.</p>
<p>The programs that handle these conversations are known as Mail Transfer Agents (MTA’s) and they all follow this pattern. If they have been told of a host that takes email for a certain domain they’ll send it on to that host, otherwise they’ll look for the DNS MX records for that domain. In reality there could be lots of transfers from one host to another before a message is finally delivered.</p>
<div id="guide-navigation">
<a href="smtp.html">Moving a message between computers</a> | <a href="./">Main Page</a> | <a href="submission.html">Sending a message</a>
</div>
</div>
</main></div>
</div>
</div>
</body>
</html>

65
guides/what-is-email/notcomplex.html

@ -0,0 +1,65 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" href="/styles/default.css">
<link rel="stylesheet" href="/styles/blog.css">
<title>Email isn't that complex</title><link type="application/atom+xml" rel="alternate" href="/blog/feed/entries/atom" title="My Blog" /></head>
<body><div id="wrapper">
<div id="header">
<h1>
Email isn't that complex
</h1>
</div>
<div id="layout">
<div id="navigation">
<p class="link">
<a href="/index.html">
Home
</a>
</p>
<p class="link">
<a href="/about.html">
About Me
</a>
</p>
<p class="link">
<a href="/contact.html">
Contact Me
</a>
</p>
<p class="link">
<a href="/guides/">
Guides
</a>
</p>
<p class="link">
<a href="/blog/">
My Blog
</a>
</p>
</div>
<div id="content">
<main class="page-content" aria-label="Content">
<div class="wrapper">
<p>So if you view the <a href="https://en.wikipedia.org/wiki/Email" title="Email - Wikipedia">wikipedia page on email</a> it is long, and some of it’s sections have their own dedicated pages. There is a lot of information, and links to even more information. All of it related to email. For a new comer this is a daunting sight, and gives the impression that email is complicated.</p>
<p>Much of this information is supplementary however, talking about things that surround email, and not actually central to what email is. If we take out the supplementary information we’re still left with a lot, but this can be broken down, and separated out into the specific parts of email that it applies to, and fundamentally email isn’t very complicated.</p>
<p>At it’s heart email is a way to send a message from one user, on one computer system, to another user on another computer system. It really is that simple, there are lots of details on how to make this concept work, but basically email is like post but for computers instead of towns or cities. One user creates a message on the computer system they are on, and send it to another user, on another computer system, and email is how that message gets from being written to being read.</p>
<div id="guide-navigation">
<a href="./">Main Page</a> | <a href="smtp.html">Moving a message between computers</a>
</div>
</div>
</main></div>
</div>
</div>
</body>
</html>

87
guides/what-is-email/smtp.html

@ -0,0 +1,87 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" href="/styles/default.css">
<link rel="stylesheet" href="/styles/blog.css">
<title>Moving a message between computers</title><link type="application/atom+xml" rel="alternate" href="/blog/feed/entries/atom" title="My Blog" /></head>
<body><div id="wrapper">
<div id="header">
<h1>
Moving a message between computers
</h1>
</div>
<div id="layout">
<div id="navigation">
<p class="link">
<a href="/index.html">
Home
</a>
</p>
<p class="link">
<a href="/about.html">
About Me
</a>
</p>
<p class="link">
<a href="/contact.html">
Contact Me
</a>
</p>
<p class="link">
<a href="/guides/">
Guides
</a>
</p>
<p class="link">
<a href="/blog/">
My Blog
</a>
</p>
</div>
<div id="content">
<main class="page-content" aria-label="Content">
<div class="wrapper">
<p>The main way email messages are moved around is a protocol called Simple Mail Transfer Protocol (SMTP for short). All this really is, is a conversation between two computers that follows a predictable pattern.</p>
<p>The conversation need the receiving computer to be listening out for the conversation to start, if it is the sending computer will connect to the receiving computer and start the conversation.</p>
<p>If we imagine two computers, <strong>fairynet</strong> and <strong>dragonnet</strong>, and two users <em>bob</em> and <em>penny</em>, <em>bob</em> is sending <em>penny</em> a message. But <em>bob</em> is a user of <strong>fairynet</strong> and <em>penny</em> is a user of <strong>dragonnet</strong>. If we start when <em>bob</em> has written his message and sent it on <strong>fairynet</strong> and look at how <strong>fairynet</strong> sends that message to <strong>dragonnet</strong> we’ll get the outline of the conversation between the two systems.</p>
<p>First <strong>fairynet</strong> connects to <strong>dragonnet</strong>, <strong>dragonnet</strong> says “Hi I’m <strong>dragonnet</strong></p>
<p><strong>fairynet</strong> needs to identify itself, and also know how <strong>dragonnet</strong> handles messages and says “Hi I’m <strong>fairynet</strong></p>
<p><strong>dragonnet</strong> responds “Here is what I can do” this will also give a list of the commands <strong>dragonnet</strong> will handle, we’ll cover some of these later.</p>
<p>Now <strong>fairynet</strong> has to say who it has a message from, so says “I have a message from <em>bob</em> at <strong>fairynet</strong></p>
<p><strong>dragonnet</strong> is a little terse at this point and just says “OK”</p>
<p>So <strong>fairynet</strong> now tells <strong>dragonnet</strong> who the message is from “I have a message for <em>penny</em> at <strong>dragonnet</strong></p>
<p><strong>dragonnet</strong> remains quite terse, and says “OK”</p>
<p>It’s at this point that <strong>fairynet</strong> gives the message to <strong>dragonnet</strong> by basically reading it out to them. If <strong>dragonnet</strong> is happy it again says “OK”.</p>
<p>The connection remains open so <strong>fairynet</strong> can send any other messages it has for <strong>dragonnet</strong>, if there are no more messages <strong>fairynet</strong> says “goodbye” and the connection is closed.</p>
<p>This conversation is an analogy, each of the messages above have a very specific format, but this shows how the conversation flows in an understandable way.</p>
<p>At each of the steps where <strong>dragonnet</strong> responds it could, instead of the response we’ve given, respond with an error. These could be temnporary errors, in which case <strong>fairynet</strong> will keep hold of the message and try again later, or permanant errors, in which case <strong>fairynet</strong> will give up and tell <em>bob</em> his message couldn’t be delivered. If <strong>fairynet</strong> holds the message for too long without being able to send it then it will also give up and tell <em>bob</em> his message couldn’t be delivered.</p>
<div id="guide-navigation">
<a href="notcomplex.html">Email isn't that complicated</a> | <a href="./">Main Page</a> | <a href="mx.html">Finding where to send the message</a>
</div>
</div>
</main></div>
</div>
</div>
</body>
</html>

69
guides/what-is-email/submission.html

@ -0,0 +1,69 @@
<!DOCTYPE html>
<html lang="en"><head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" href="/styles/default.css">
<link rel="stylesheet" href="/styles/blog.css">
<title>Sending a message</title><link type="application/atom+xml" rel="alternate" href="/blog/feed/entries/atom" title="My Blog" /></head>
<body><div id="wrapper">
<div id="header">
<h1>
Sending a message
</h1>
</div>
<div id="layout">
<div id="navigation">
<p class="link">
<a href="/index.html">
Home
</a>
</p>
<p class="link">
<a href="/about.html">
About Me
</a>
</p>
<p class="link">
<a href="/contact.html">
Contact Me
</a>
</p>
<p class="link">
<a href="/guides/">
Guides
</a>
</p>
<p class="link">
<a href="/blog/">
My Blog
</a>
</p>
</div>
<div id="content">
<main class="page-content" aria-label="Content">
<div class="wrapper">
<p>So we know how a message is moved around between computers, to get from one computer system to another. But how does <em>bob</em> get his message to <strong>fairynet</strong> to start with?</p>
<p>As well as having an MTA that sends messages on to other computers, and gets messages from other computers if <strong>fairynet</strong> accepts emails, <strong>fairynet</strong> will have whats called a Mail Submission Agent (MSA) that is very similar to an MTA, except it allows users to authenticate.</p>
<p>The MSA accepts connections from Mail User Agents (MUAs) in use by users. These could be software like Microsoft Outlook, running on the users computer at home, or they could be programs running on a webserver for a webmail service like Google’s Gmail.</p>
<p>The MSA and MUA talk a version of SMTP that includes sending a user identifier such as a username, and a shared secret such as a password. This makes the conversation more sensitive.</p>
<p>To protect this conversation the MSA could either listen on an encrypted channel, so the SMTP conversation is encrypted before it starts, or it could allow encryption to be started after the connection is established using a command called “STARTTLS”. This command is part of the SMTP specification, and as the MSA and MTA provide very similar functions they are often the same program, if “STARTTLS” is available and understood by the MTA it can be used to protect the message over the network, but each MTA that handles the message will see the message without the protection of encryption.</p>
<div id="guide-navigation">
<a href="mx.html">Finding where to send the message</a> | <a href="./">Main Page</a> | <a href="delivery.html">Getting a message</a>
</div>
</div>
</main></div>
</div>
</div>
</body>
</html>
Loading…
Cancel
Save