Tag: email

Posted on in Linux, Server

Let’s do Dovecot slowly and properly – Part 1: PLAIN as day

This post follows up on the fifth installment in my Let’s do Postfix series. We’re not really done setting up Postfix but a) it’s about time we had a better way of accessing incoming mail than ssh’ing into our server and using cat to read and b) we are at a juncture where the two will soon start depending on (SASL) and interacting with (LMTP) each other

This tutorial presumes knowledge of Postfix and the setup we’re aiming for is one that complements the Postfix one that we’ve set up in previous installments. As with the Postfix series I want to arrive at a working setup from the very first post but knowing full well that it’s not an ideal or final setup. The advantage (over importing somebody else’s full featured setup) is that we’ll actually understand what we have on our hands (and it’s shortcomings). This makes it a lot easier to build and improve upon it and fix it should the need arises.

A note on safety: The setup we’ll end up with today is not going to be confidential in any way, shape, or form. It will expose both the contents of the account’s emails and whatever password you choose to the entire internet. Therefore you should obviously use either a test account or a brand new one that has nothing important on it yet. As for passwords you should pick one for testing that you have not used nor intend to use for any non-testing purposes. That said, un-confidential is not the same as unsafe. Any public facing service is a potential attack vector but this setup is – to the best of my knowledge – no more of one than a more properly confidential setup.

(more…)

Posted on in Python

Squeezing the sponge: How to implement a buffering SMTP Handler in Python

…when he needs what you have gleaned, it is but squeezing you,
and, sponge, you shall be dry again.
– Hamlet

One of the first things I implement in most Python projects is some quick stream logging so as not to dot too many print statements across the code. At some point file logging usually  follows as a feature so it can run by itself and I can check up on it from time to time.

Recently I got ambitious and added email logging to poca, my podcast client project. Which isn’t difficult as the logging module has an SMTPHandler built-in that you just stick on your logger and now your logs are airborne. It’s almost xkcd-like. The way it works though is that an email is sent off instantly every time something is logged, just like stream logging only over port 25. This was not what I wanted. To be specific I was looking for something that

  • Would gather up log entries as my script runs it course
  • At the end of the script it would evaluate if there was anything worthwhile sending
  • If so, send it; if not, save, don’t send

The way to do, as suggested by the logging module author himself, is to subclass the BufferingHandler which does a fine job of soaking up the entries and keeping them until its time to release them. He has written an example of how to do this himself and put it on Github.

I had, however, a further requirement. When a podcast feed fails, it’s not necessarily cause for alarm or notifying the user. Maybe the server’s in maintenance mode for a few minutes, maybe builders unplugged the cable for an hour, maybe you did. You only really need email logging to tell you when a podcast feed consistently fails because then it’s probably either a software failure or the feed is offline, either of which requires user intervention. Vinay Sajip’s script doesn’t allow for that. Also, using unicode is easier if we keep a clear distinction between body and headers which Sajip’s approach seems to fudge a bit.

My requirements meant that I would have to not just buffer entries in memory but save them over time and only release them when there was a sufficient number (and of sufficient severity) to worry about.

(more…)

Posted on in Linux, Server

Let’s do Postfix slowly and properly – Part 5: Relaying from the local network

When running your own SMTP the real spam challenge is not to avoid getting targeted by spammers – it is is to avoid getting used by spammers.

Mind you, you don’t want spam in your inbox but a) that’s what filters are for and b) spammers (mostly) use confirmed lists of recipients, they don’t probe domains for addresses. When they do probe, they probe for access to relay, to use your server to distribute their junk. If they’re successful you’ll have far bigger problems than having to delete a couple emails a day (i.e. your IP and domain winding up on blacklists; also your ISP may disapprove). That is the reason I have saved relaying until now. Opening yourself up to receiving unwanted mail is at lot less problematic than opening yourself up to having your server hijacked by spammers. Postfix is by default set to be rather restrictive in who it lets send out mail so while we have been messing about with receiving mail, the mail sending settings have stayed default and safe.

This will be a short post, as we will only get to know how to relay mail based on the mynetworks setting. ‘Relay’ is fairly synonynous with ‘sending’ but AFAICT it only refers to sending between SMTP servers. A user sends an email. An SMTP server relays it to another SMTP server. This post is about relaying from a local network.

(more…)
Posted on in Linux, Server

Let’s do Postfix slowly and properly – Part 4: Virtual domains

To reiterate what I said in the first post in our Postfix series, a virtual setup is one in which email accounts are independent of system accounts. We therefore have to tell Postfix what accounts we have on any given domain, where to put email for an account etc. in contrast to local delivery where users are defined by the system and delivery is by default to a file in /var/mail. In order to create this kind of setup we will have to jettison most of the settings we have worked on so far. On the plus side it will still feel very familiar as virtual and local settings often follow the same basic pattern and nomenclature. In addition, as I have said before, having familiarized ourselves with a local setup helps us understand how to properly distinguish between the two kinds of setup.

(more…)
Posted on in Linux, Server

Let’s do Postfix slowly and properly – Part 3: Opening up to the outside

I promised that in this third part of the series we would finally get to make our SMTP server accessible from the outside, gettting a bit closer to something that actually  resembles a real mail server. I am going to make good on that promise.

There are three aspects to this change. First, we will need to set up our router so that our SMTP server can communicate with the outside world. Secondly, we will need to create a listing for our SMTP server so that other SMTP servers know where to look when they have email for our domain (the MX host setting). Finally we will of course have to adjust our Postfix configuration.

(more…)
Posted on in Linux, Server

Let’s do Postfix slowly and properly – Part 1: A simple local mail receiving server

About a year ago I wrote a scathing comment about Ars Technica’s too-slow guide to self-hosted email. I wanted it now-now-now and not over the course of four weeks. Well, I guess it’s time to eat humble pie because my setup didn’t survive transfer to the new machine. Seeing as I hadn’t acquired any deep understanding of the setup apart from a purely abstract grasp of email fundamentals I didn’t have any way to fix it.

In short, I’m going to go in the complete opposite direction and take it slow this time. We are going to setup an MTA that will accept email and that we can use to send email. Only when we thoroughly understand that will we move on to Dovecot and the like. We are going to take it step-by-step, making sure that we understand what we’re doing and why we’re doing it and sometimes even what we’re not doing.

In the course of this first piece in a series, we will get some sort of email up and running – and get that warm feeling that we have accomplished something –  but consider it more of a proof-of-concept or a learning experience than anything like the final thing.

(more…)