From FyshyWyky
Revision as of 00:02, 3 November 2006 by Athan (talk | contribs) (Lots of expansion of text, and skeleton of sections.)
Please note that whilst every effort is made to ensure the accuracy of the information on these pages it is entirely possible that things like the specific configuration of parameters of services have changed since the page you're looking at was last edited.

Some doubt can possibly be alleviated by checking the 'last updated' date/timestamp at the bottom of the page, or looking at the history for it (linked at the top of the page).

If in any doubt at all about a setting that might be affecting your use of a service please send a query to The Fyshy Admin, with all pertinent information.


Fysh.Org Mail Services

Introduction hosts the primary Mail eXchanger (MX) for itself and any other domain configured to deliver locally on it. In addition we have agreements with operators of other servers to provide secondary MX capability. If you have a domain that you would like us to host then please email The Fyshy Postmaster with details for us to configure things correctly.

We currently use exim4 as the MTA that handles all email. This is configured to allow relaying only for authorised users and also employs a number of Anti-Spam Countermeasures to help protect our users from the deluge that is the norm on the Internet today.

In addition we provide both POP3 and IMAP access for remote retrieval of email, both of which are accessible using SSL/TLS encryption. Users can opt to use a MUA locally through a shell login if they prefer.

SMTP is the official hostname for our SMTP service. Any domain expected to deliver locally should specify that hostname as its primary MX record. Likewise you should list that hostname in secondary MX records when we're configured to relay for a domain.

Additionally users may relay outbound email via the same hostname from arbitrary hosts on the internet so long as they make use of SMTP AUTH. To do so you will first have to [set up a password] specifically for this.

Reading Mail

POP3 is the official hostname for our POP3 service. You should authenticate the connection with your account username and password. To reduce the risk of this being snooped please be sure to enable any 'SSL' or 'TLS' options in your client.

IMAP is the official hostname for our IMAP service. You should authenticate the connection with your account username and password. To reduce the risk of this being snooped please be sure to enable any 'SSL' or 'TLS' options in your client.


We offer access to email held on via HTTP using Squirrelmail. The address for this service is [1], or if for some reason you're unable to use encrypted HTTP (HTTPS) use [2] but please be aware that this will cause your username, password, and any email read to be transmitted in plain text over the Internet, allowing for easy interception by malicious third parties.

Maillists is available for hosting multi-user maillists using MailMan as the software. There is a list of those hosted maillists that allow public viewing of details. Please contact The Fyshy Postmaster if you wish to request a new list be set up for you. Note that if you have a domain hosted to deliver on then we can setup the new maillist within that domain.

Reading Mail Locally

Many Fysh.Org users prefer to read their email by logging in to and then using a Mail User Agent directly there. The main supported program for this is Mutt, although users should be able to get Emacs to read mail as well. Note that whilst Pine is installed support for it is minimal due to the lack of updates in Debian, which is in turn due to the license of Pine precluding the distribution of binaries.

Email Spam

If you're really unenlightened as to what it is then the Wikipedia Email Spam page may prove useful.

In short it's unsolicited email being sent either to promote some product or in an attempt to distribute malware. So, unsurprisingly, the majority of people using email do not wish to read such emails, and would prefer to never receive them so as to not even have to spend a minimal amount of time deleting them.

MTA Counter-Measures employs some measures at the MTA level to reduce the amount of spam that ends up in our users' inboxes.


The single measure we find reduces spammer the most is to make use of Spamhaus' SBL-XBL RBL. This is basically a list of hosts known to send email spam. Whilst there is some risk of false positives in such things in our experience this either never happens with the SBL-XBL, or at so low a rate as to be unnoticeable.


The other primary anti-spam counter-measure that we employ is called Greylisting.

Any time an email is sent to a domain delivered on it is checked against our Greylisting lists. The data that is checked is the tuple "<originating IP> <mail from address> <mail to address>". If we have never seen email from the tuple before it is put in the greylist listing, with the time and attempts so far recorded, and then a temporary failure is returned to the sending MTA. With well behaved MTAs this is no problem as they will simply retry delivery at intervals, usually shortly after the initial attempt and then at increasingly larger intervals until they finally give up if no successful delivery is achieved. So, if the remote MTA then retries the email, but we consider it too soon (within 5 minutes) we'll again note the attempt, the email stays on the greylist listing, bump the attempt count and update the time of last attempt. When the MTA subsequently retries at an interval of more than 5 minutes since the last attempt we will see that the item of email is on our greylist list and allow the email through. Additionally the tuple, delivery attempt count and last delivery time are moved to the whitelist listing. Alternatively if there is no attempt to retry delivery the tuple will be expired from the greylist list after 8 hours, removing the data held for the attempt. This is what happens to a great majority of spam attempts, due them being sent by programs that are not full MTAs such that they never retry deliveries (they just move on to their next target address instead).

Now, if an email is received where the data matches a tuple already on the whitelist then we will accept the email immediately, once more updating the delivery count and time of last attempt. So long as an email passes through our system matching a given tuple that tuple will stay on the whitelist list for 60 days after the last successful delivery. Thus for any tuple that represents email that you regularly receive greylisting will only affect the first email, and probably only its first attempted delivery.

Problems With Greylisting There are a few problems with greylisting. The primary one is to do with the way some maillists send out a copy to each list member. Instead of setting the 'mail from address' to the person who sent the email to the list they set this to a unique mail address per recipient, and indeed per email sent through the list. Such email addresses might look like:

Obviously in this case the email with the second from address isn't going to match the same tuple as the first and thus will not be passed through due to listing in the whitelist. If you find you are on such a maillist and the delays caused by greylisting for every email from the list are causing you problems please forward us the full headers from at least 3 example emails that came from the list so that we can determine which sending hosts to add to our hardcoded 'whitelisted hosts' list. From then on, unless the sending hosts for the maillist change, any email for that list will skip entirely over our greylisting checks.

Of course the other problem is that if we've not seen a tuple for an incoming email yet it will be delayed at least 5 minutes, quite possibly more depending on the retry behaviour of the sending host (they might not retry, after the initial attempt, for something like 30 minutes). If you really feel this is too onerous for you to bear we can look into making your email skip the greylisting checks entirely. Note that currently we can only do this on a per-domain basis for the receiving domain. If there is sufficient demand we'll adjust the MTA configuration so that we can do so on a per-user-per-domain basis.

There are also some misconfigured or badly coded MTAs in use which don't retry email at all. In this case we'll again need to find out the IP(s) of the sending host(s) so we can add them to our 'whitelisted hosts' list for greylisting.

User Counter-Measures