Mail

From FyshyWyky
Revision as of 09:48, 15 September 2020 by Athan (talk | contribs) (Add section about us handling a domain's email.)
Jump to navigationJump to search
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.

 

Introduction

river.fysh.org hosts the primary Mail eXchanger (MX) for fysh.org 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.

Having us handle email for your domain

We're happy to handle email for your domain directly on fysh.org. Email The Fyshy Postmaster with details, including any requirement for extra accounts for picking up email to particular aliases on the domain.

Note that you'll be given control of the aliases file for your domain, but please follow these guidelines:

We currently use 'DB' files

We currently use Berkely .db files for historical reasons. As a consequence you cannot make use of wildcards in aliases, other than a single "*" overall wildcard as a catchall. This also means that order in your aliases file doesn't matter. There is a tentative plan to review aliases for all locally delivered domains and change this.

Be careful about a domain "*" wildcard catchall

Spammers have an unfortunate habit of plain guessing at local parts for domains. This can be them simply selling lists to others that put all the local parts they've ever seen on every domain, or some error in their scraping of email addresses.

As such using a "*" wildcard will likely result in you receiving more spam when without it these attempts would just bounce with "User unknown".

Final delivery is to <account>@fysh.org

In order to cause actual local delivery the target of an alias must be <account>@fysh.org. Using just <account> will keep email directed within your domain and will not lead to an actual delivery.

Make use of :blackhole: not :fail:

If you have an alias that you've decided to abandon and want to fail silently please use ":blackhole:" as the target. If you don't need it to fail silently then simply remove the alias so that attempts get "User unknown".

Likewise do NOT specify custom ":fail:" messages to spammers. Just use ":blackhole:" instead. This both avoids potentially causing backscatter to spoofed from addresses and also makes automated processing of our logs easier.

SMTP

mail.fysh.org 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. NB: To use SMTP AUTH you must be using an encrypted connection, this is an attempt to not have SMTP AUTH passwords sniffed on random WiFi connections and abused to send spam. To use SMTP AUTH you will first have to set up a password specifically for this.

Configure your Email Client with the following details:

Parameter Value
Mail/SMTP Server Name mail.fysh.org
Port 25 (NB: You may also use the SMTP Submission Port, 587, for this. If your client expects TLS right from the start of the connection use port 465. )
Secure Connection Enable 'STARTTLS' or 'TLS', preferably at least version 1.2 if given the option.
Authentication Your river.fysh.org username and the password you set up specifically for this, not your shell login password. Note that we currently support 'CRAM-MD5', 'PLAIN' and 'LOGIN' authentication against this extra password.

Using Maildir instead of mbox

For historical reasons much of the configuration on Fysh.Org still targets the use of mbox style email folders, both over IMAP/POP3 and locally on river.fysh.org. However there are multiple reasons why we are migrating away from this as of October 2019.

  1. Default IMAP namespace targets the user's home directory, and as such will attempt to treat every single file and folder inside of it as an IMAP folder. This then creates a .imap/ directory at the location of each found file or directory and populates it with dovecot-related files for keeping track of the index and UID values of any email items. This both makes a mess and also greatly slows down IMAP 'LIST' operations (which also can cause 'permissions denied' errors).
  2. If a user often saves email to, or deletes email from, or even just updates the status of an email, in an mbox file this causes the entire file to then be included in the next incremental system backup. If someone has a 1GB INBOX and receives only 1 new email a day (or deletes on a day, or marks one a day as read when it was unread previously) then that entire 1GB goes into the next incremental backup. This is wasteful of space. Using Maildir format for this means only one small new file is written, or an old one deleted/updated.

As such the only officially supported email storage scheme is now Maildir, storing in ~user/Maildir/ . Whilst the migration is on-going the defaults for MTA/MDA final delivery, MUAs and mail.fysh.org IMAP/POP3 access will still be using mbox and /var/mail/user as INBOX. However we have implemented per-user overrides to this to either force the user to ~user/Maildir, or something else that is appropriate where they are not actively already using IMAP with folders directly in their home directory.

Using Maildir format for email is recommended over the default of mbox. You get a separate file per email making deletion/update operations much quicker and can easily setup sub folders for use with IMAP. There is a particular way of doing this that best interacts with our IMAP service. Be sure that any local email client you run on river.fysh.org can deal with Maildir format mailboxes, or simply use IMAP, before implementing the changes below.

Use Procmail to save in Maildir format

The first thing you need is to either create a minimal ~/.procmailrc file containing at least the following, or see Mail#Procmail for the location of a full example file. An example at /etc/skel/procmailrc-example should be available on river.fysh.org

MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/

The key thing here is that you're saving email into ~/Maildir, and any mention of a folder ends with a slash (/). This tells Procmail to save in Maildir format instead of mbox.

If you have email filtered into separate inboxes using Procmail then for optimal interaction with IMAP you'll want their names to start with a dot (.). So, for instance, you might have:

######################################
# The Fysh List
######################################
:0
* ^TOfysh@fysh\.org
.fyshlist/

:0
* ^FROMfysh-.*@fysh\.org
.fyshlist/
######################################

Note the leading dot and the trailing slash on the target of each rule. This leads to these folders being seen as sub-folders of INBOX in IMAP.

Reading Mail

NB: If you have been using "sanemail.fysh.org" as the server in any SMTP, POP3 or IMAP setup you no longer need to, just use "mail.fysh.org" as per the instructions below. The hostname has been redirected (and thus also gained IPv6 connectivity).

POP3

mail.fysh.org is the official hostname for our POP3 service. You should authenticate the connection with your account username and password. This service is only available over encrypted connections, so please be sure to enable any 'TLS' (preferred) or 'SSL' (if TLS is not available) options in your client. See Fysh SSL Certificates for details of the certificate we use.

Parameter Value
Server Name mail.fysh.org
Port 110 1
User Name Your river.fysh.org username
Password Your shell login password, not the SMTP AUTH one.
Secure Connection Use TLS if available (or SSL if your client only offers that).
Use Secure Authentication OFF 2

1 - If port 110 is blocked from your site, then try port 995 instead, with TLS or SSL for 'Secure Connection'.

2 - APOP authentication is no longer supported.

IMAP

mail.fysh.org provides our IMAP service. You should authenticate the connection with your account username and password. This service is only available over encrypted connections, so please be sure to enable any 'TLS' (preferred) or 'SSL' (if TLS is not available) options in your client. See Fysh SSL Certificates for details of the certificate we use.

Parameter Value
Server Name mail.fysh.org
Port 993
User Name Your river.fysh.org username
Password Your shell login password, not the SMTP AUTH one.
Secure Connection Use TLS if available, else SSL.
Use Secure Authentication OFF (the server doesn't support this)
Prefix Leave blank to use the configuration we have set up for you. See the notes below.
  1. If you don't use a prefix, and have previously been using IMAP with the default namespace such that it placed any additional folders in your home directory then you will continue to use that configuration for the time being. We will likely be in touch in order to migrate you to a saner configuration.
  2. Where we know you store additional email folders within a sub-directory of your home directory we have overridden the default IMAP configuration to ensure your IMAP clients only see that sub-directory's contents, rather than your whole home directory. If you're not using Maildir for your INBOX then this will continue to be /var/mail/<user>.
  3. If we have converted you to using Maildir format then IMAP access with no prefix will be using ~user/Maildir/ for both INBOX and additional folders.

If you remember a symbolic link 'hack' in order to have INBOX show up properly with the old Maildir prefix, then don't worry, that is no longer necessary.

Webmail

We offer access to email held on mail.fysh.org via HTTP using Roundcube. The address for this service is https://roundcube.fysh.org/.

See Fysh SSL Certificates for details of the certificate we use. For historical reasons it uses the squirrelmail.fysh.org certificate listed there.

URL https://roundcube.fysh.org/
Username/Password Your river.fysh.org shell login details.

Reading Mail Locally

Many Fysh.Org users prefer to read their email by logging in to river.fysh.org and then using a Mail User Agent directly there.

Mutt

The main supported program for this is Mutt. This supports default mbox style mailboxes along with Maildir, and also has built-in IMAP and POP support.

Emacs

Users should be able to get Emacs to read mail as well. No configuration advice is offered here.

Alpine (Pine)

Pine has been replaced by Alpine (a symbolic link means if you run 'pine' you'll actually get alpine). Alpine is based on Pine, but is properly open source and doesn't have the "no binary redistribution" licensing problems that affected Pine.

Alpine does not directly support Maildir format, but you can simply use IMAP instead if needs be. Set 'Inbox Path' to something like (change 'athan' to your username):

mail.fysh.org/user=athan

And the Folder to:

Maildir/INBOX

ELM

ELM is no longer installed; 'elm' will now run a script to convert your elm aliases and give you a ~/.muttrc that will work, and then run mutt.

Maillists

fysh.org 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 mail.fysh.org then we can setup the new maillist within that domain.

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

mail.fysh.org employs some measures at the MTA level to reduce the amount of spam that ends up in our users' inboxes. At the time of writing these are applied in the order listed here.

NB: None of these measures are employed if one of the following conditions is true:

  • The email is being submitted to us on port 587, the Mail Submission port which requires all senders to be authenticated.
  • The connection is otherwise authenticated and thus trusted.
  • Email being sent by mail.fysh.org itself, i.e. locally generated email.
  • Any email addressed to either 'postmaster' or 'abuse' at the target domain. Whilst a lot of spam gets through due to this we feel it is more important to remain contactable on such addresses despite anti-spam measures.


Mail From Dialup/DSL Hosts

We use a list of regexes which match hostnames known to be used solely for Dialup or ADSL by home users, and block all attempts by such hosts to send email to mail.fysh.org. The premise is that such hosts should be able to send email perfectly well via their ISP's outbound mail server(s) and the most likely reason for them attempting to send email directly to us is that it's a spambot doing so. As tempting as it is we do not put such regexes as:

.*\.cn$

in that file, i.e. to block all email originating in China, because we realise that our users may wish to correspond with people sending email from anywhere in the world and do not restrict it.

Any email rejected due to the sending host matching one of the patterns we test on will receive the message 'rejected because we have blacklisted your host (tried using your ISP's email server to smarthost/relay?)' as part of the rejection code.

NB: Users with a fysh.org shell account login can still send email to/via mail.fysh.org from a dialup or ADSL connection, provided that they have authenticated themselves first, which is necessary anyway to relay through mail.fysh.org.

Realtime Black Lists

The single measure we find reduces locally-delivered spam the most is to make use of the Spamhaus Zen RBL. This is basically a list of hosts known to send email spam, plus all known "dialup" IPs (i.e. home dialup, DSL or Cable connections that should be sending email through their ISP's email server). Whilst there is some risk of false positives in such things in our experience this either never happens with the Zen DNSBL, or at so low a rate as to be unnoticeable.

If you believe an email that should have been delivered on mail.fysh.org wasn't due to the sending host being erroneously included in an RBL we use please send an email to The Fyshy Postmaster with full details, preferably the full headers and relevant body of the original email and/or the bounce that was generated.

Sender Verification

Anyone sending email should be doing so from an address that email can be successfully sent to. The sole exception to this is the 'null envelope sender' address of <> which is used to avoid bounce loops. Thus we employ a check where we attempt to verify that the envelope-from of incoming email is an address we could send email back to. The results of these checks are cached so that we don't hammer another email server if a single sender occurs repeatedly.

If the sender is genuine, and correctly configured, this check will cause no problems. If the sender is a spammer and happens to be utilising a from address that isn't valid (they sometimes seem to use a random local part in a valid domain, or simply an email address that is no longer valid) then the email will be rejected.

We are aware of some of the downsides to this action and have chosen to continue it.

Greylisting

As of 2019-10-17 ~12:53 BST we have turned off greylisting entirely. As no issues were reported or observed in the following 2 weeks this was then made permanent.

User Counter-Measures

There are several ways in which mail.fysh.org users can apply additional filtering to their email to further counter spam, in addition to those measures applied at the MTA level. All of these will require some familiarity with Linux/Unix systems as you'll need to login to your shell account and edit files at the very least.

Procmail

Procmail is a general filter for email. As well as deciding to put email matching given criteria into separate folders you can use it to safely forward email, CC it to another person, or return it as if undelivered to the sending address. You can also combine it with anti-spam filters such as Spamassassin and Bogofilter to cut down on the amount of spam you receive.

Any email delivered to a user on river.fysh.org will be run through procmail if the user has a .procmailrc file in their home directory. Please see 'man procmail', 'man procmailrc' and 'man procmailex' once logged in for the documentation on how to use it.

NB: The procmail 'TO' directive, whilst matching things like To, Cc and even X-Envelope, does not match Exim's Envelope-To header. This is a header added during final delivery on river.fysh.org denoting the specific email address to which the email was sent to cause that delivery. Please bear this in mind when constructing rules that need to match emails which you are only receiving due to being BCC'd on them. A prime example of this is any email from Fysh-Announce.

Do NOT Make use of EXITCODE=67 to cause a bounce if you've decided you don't want the email. The likely outcome of this will be back-scatter to a spoofed from address and/or you just getting a "we couldn't deliver that" bounce back to you. Simply direct the email into /dev/null.

There is an example usage of procmail available on river.fysh.org in /etc/skel/procmailrc-example . This should work as-is, so long as you make sure (as detailed in the file) to have ~/Maildir/ already exist as a directory. Simply run the command 'mkdir ~/Maildir/' if needs be. As of 2016-04-01 (and not an April Fool) that file implements:

  1. filtering spam into a sub-folder using spamassassin
  2. a fixup for a quirk to do with the 'From ' (no-colon) email header.
  3. de-duplication of messages with the exact same Message-ID header (such as if you were CC'd on a message that was also sent to an email list you're on).
  4. Ensuring proper headers are in place for PGP/GPG encrypted/signed messages.

Furthermore it has examples for:

  1. Temporarily disabling email delivery
  2. Excepting email from even being run through spamassassin.
  3. Discarding email without causing a bounce.
  4. Filtering extra 'me' email addresses into your INBOX.

Exim Filters

As we use exim (version 4) for the MTA on mail.fysh.org you can make use of Exim Filters in your .forward file.

Spamassassin

Spamassassin is an automatable means of determining if an item of email is spam or not. It runs a whole battery oh tests on both the headers and body, including attachments, of a test email, with each test contributing, positively or negatively, to the final score. If the score is over the configured threshold then the email will be marked as spam. This method is useful because it is a lot more powerful than a simple black and white "if this email is in HTML then I'll bin it as spam" approach.

We do not run Spamassassin at the MTA level on mail.fysh.org, but any user can make use of procmail to filter their email via it themselves. A section similar to the following in ~/.procmailrc will enable spamassassin filtering of email into a separate folder:

# Pipe the mail through spamassassin (replace 'spamassassin' with
# 'spamc' if you use the spamc/spamd combination)
#
# The condition line ensures that only messages smaller than 250 kB
# (250 * 1024 = 256000 bytes) are processed by SpamAssassin. Most spam
# isn't bigger than a few k and working with big messages can bring
# SpamAssassin to its knees.
#
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| spamassassin

# All mail tagged as spam (eg. with a score higher than the set
# threshold) is moved to "spam".
:0
* ^X-Spam-Status: Yes
.spam/

Please be sure to read the Spamassassin documentation (man spamassassin and the files under river:/usr/share/doc/spamassassin) before putting a section like this in your ~/.procmailrc file.

Bogofilter

Bogofilter is another means of automatically determining if an email is spam. It uses something called Bayesian filtering to attempt to determine if the text of an email is spam or not. Spamassassin actually uses its own implementation of this method of spam determination, but some users find it better to run both Spamassassin and Bogofilter over all their email, as each will catch some spam emails that the other doesn't.

Again you'll use a section of your ~/.procmailrc file to enable filtering with bogofilter. Do NOT enable this until you have first trained bogofilter on a good corpus of ham (emails that are not spam) and spam, else it will give effectively random results.


## Run through bogofilter
# -p, --passthrough         - passthrough.
# -e, --ham-true            - in -p mode, exit with code 0 when the mail
#                             is not spam.
# -u, --update-as-scored    - score message as spam or non-spam and register
#                             accordingly.
:0fw: bogofilter.lock
| bogofilter -e -p -u

# if bogofilter failed, return the mail to the queue, the MTA will
# retry to deliver it later
## NB: This causes more headaches than it is worth, when combined with
## using 'formail -D' to de-dupe emails.  If we return it to the queue
## for later delivery and it hits the de-dupe it'll get dropped as a
## dupe.  The filter rule above DOES still pass the original through
## unchanged if bogofilter failed for some reason (at least if it
## doesn't recognise a command line option), so we're safe to continue.
## At worse we'll not filter some spam.  That's as opposed to plain
## losing email due to the bad interaction with de-duping! 
#:0e
#{
#       EXITCODE=75
#}

## If bogofilter thinks it's spam, save
:0:
* ^X-Bogosity: Yes, tests=bogofilter
.spam/

Note that if you do also use Spamassassin in your ~/.procmailrc then the sum of the configuration should be something like:

## Any rules to have email skip the spamassassin and bogofilter tests here:
## i.e. uncomment these and edit to taste
### ## Absolutely whitelisted email addresses
### :0 H
### * ^TO(abuse|postmaster)@(fysh\.org|miggy\.org|dsl\.miggy\.org|novusinitium\.org)
### {
###         :0
###         * ^TO(abuse|postmaster)@fysh\.org
###         .fysh/
### 
###         :0 B
###         * !http://www\.bodybouncer\.com/
###         $MAILDIR/
### }

## Run through bogofilter
# -p, --passthrough         - passthrough.
# -e, --ham-true            - in -p mode, exit with code 0 when the mail
#                             is not spam.
# -u, --update-as-scored    - score message as spam or non-spam and register
#                             accordingly.
:0fw: bogofilter.lock
| bogofilter -e -p -u

# if bogofilter failed, return the mail to the queue, the MTA will
# retry to deliver it later
## NB: This causes more headaches than it is worth, when combined with
## using 'formail -D' to de-dupe emails.  If we return it to the queue
## for later delivery and it hits the de-dupe it'll get dropped as a
## dupe.  The filter rule above DOES still pass the original through
## unchanged if bogofilter failed for some reason (at least if it
## doesn't recognise a commandline option), so we're safe to continue.
## At worse we'll not filter some spam.  That's as opposed to plain
## losing email due to the bad interaction with de-duping! 
#:0e
#{
#       EXITCODE=75
#}

# Pipe the mail through spamassassin (replace 'spamassassin' with
# 'spamc' if you use the spamc/spamd combination)
# 
# The condition line ensures that only messages smaller than 250 kB
# (250 * 1024 = 256000 bytes) are processed by SpamAssassin. Most spam
# isn't bigger than a few k and working with big messages can bring
# SpamAssassin to its knees.
# 
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| spamassassin

## If bogofilter thinks it's spam, save
:0:
* ^X-Bogosity: Yes, tests=bogofilter
{
        ## Make sure SpamAssassin's filtering learns it as spam
        :0c
        |formail -I "X-Bogosity" | sa-learn --spam

        ## Something we don't filter/recognise, we'll look at it
        :0
        .spam/
}

## All mail tagged as spam (eg. with a score higher than the set
# threshold) is moved to "spam".
:0
* ^X-Spam-Status: Yes
{
        ## Make sure Bogofilter learns it as spam
        :0c
        |spamassassin -d | bogofilter --register-spam

        :0
        .spam/
}

This ensures that any email which bogofilter thinks is spam also gets fed to spamassassin's bayesian filtering to learn as spam.

To train bogofilter initially you should, at the very least, teach it what your non-spam email looks like (the -M option assumes the email folder is in mbox format):

bogofilter -M -n /var/mail/${USER}

or adjust the name of the mailbox you feed it to suit where you've saved a significant amount of non-spam email. Likewise if you have some saved spam email you can train it on that:

bogofilter -M -s ~/Mail/spam

Correcting Spamassassin and/or Bogofilter Registration of Email

If your ~/.procmailrc rules cause spamassassin and/or bogofilter to mistakenly flag an email as spam you should be sure you re-train them on it to decrease the likelihood of them making the same mistake again. An example of doing this for the MUA Mutt would be the following in ~/.muttrc:

## spam
# Register as Spam, unregister as Ham (non-Spam)
#
macro index S "<enter-command>unset wait_key\n\
<tag-entry>\
<tag-prefix>\
<clear-flag>N\
<tag-prefix>\
<pipe-entry>/usr/bin/spamassassin -r\n\
<pipe-entry>spamassassin -d | bogofilter --register-spam --unregister-nonspam -v\n\
<tag-prefix>\
<save-message>=savedspam\n\
<untag-pattern>.*\n\
<enter-command>set wait_key\n"
macro pager S "<enter-command>unset wait_key\n\
<tag-entry>\
<tag-prefix>\
<clear-flag>N\
<tag-prefix>\
<pipe-entry>/usr/bin/spamassassin -r\n\
<pipe-entry>spamassassin -d | bogofilter --register-spam --unregister-nonspam -v\n\ 
<tag-prefix>\
<save-message>=savedspam\n\
<enter-command>set wait_key\n"
# Register as Ham (non-spam), unregister as Spam
macro index H "<enter-command>unset wait_key\n\
<pipe-entry>/usr/bin/sa-learn --ham  --no-sync\n\
<pipe-entry>spamassassin -d | bogofilter --register-ham --unregister-spam -v\n\
<enter-command>set wait_key\n"
macro pager H "<enter-command>unset wait_key\n\
<pipe-entry>/usr/bin/sa-learn --ham  --no-sync\n\
<pipe-entry>spamassassin -d | bogofilter --register-ham --unregister-spam -v\n\
<enter-command>set wait_key\n"

This allows you to press H (capital H, not lowercase h) to have mutt tell both spamassassin and bogofilter that the current email, in the mail index or pager, is Ham, not Spam. Likewise it also enables you, by pressing S (capital S), to re-train an actual Spam email that got past your filtering as Spam instead of Ham.

Per-site email aliases

Note by 'per-site' here we mean this is a convenient way to give a unique email address to any web sites you might want to sign up to (so you know who leaked your address to spammers if they do).

For any email set to deliver on mail.fysh.org a user can utilise a feature that allows them to define almost limitless email addresses. Basically if your user account is 'foo' then you can use an email address of the form 'foo-bar@fysh.org' and it will be delivered as if to 'foo@fysh.org'. The 'bar' may be any legal text for the left-hand-side of an email address. NB: This only works for email directly to an @fysh.org address, not other domains delivered on mail.fysh.org. This is because it explicitly breaks any aliases that have a hyphen in them. We can control that for fysh.org, but users may be unaware of this for their own domains and it wouldn't be easy to figure out why things aren't working. They can, of course, just create whatever aliases they want for their own domain anyway.

Sending Spam from mail.fysh.org

It should go without saying, but we'll say it here anyway, that sending any form of email spam from mail.fysh.org is strictly prohibited. Upon discovery, and we will discover such activity, your account will be closed forthwith pending investigation.

In the past we have even rejected requests to use our service to send out mass-marketing emails to opt-in lists, not having enough information to be 100% sure the list was opt-in and 100% up to date.

Note that this does mean that care should be taken with any scripts you have for sending email out to multiple people, as well as any scripts you place in your web space that could possibly be insecure and allow for sending of email to arbitrary addresses.

Hey spammers

I'd love some spam to poohshoney@fysh.org !

Known Problems & Workarounds

'procmail -d' introducing >From header

There is a known bug1 with the version of procmail in Debian/Etch as of 2007-08-29, specifically version 3.22-16. We no longer use 'procmail -d <user>' to deliver email to users locally on pond.fysh.org, thus this bug will only affect users who are specifically delivering mail in this way for some reason.

Use of the -d flag adds an extra header of the form '>From <user> <Date and time>'. Unfortunately because this header has the '>' character at the start it can confuse other programs. Ironically this includes procmail itself!

If you aren't using a ~/.procmailrc file at all then you shouldn't be affected, email will simply get delivered into your /var/mail/<user> file. If you are using a ~/.procmailrc then there is a simple workaround. Simply add this recipe as the very first one in your ~/.procmailrc:

## 'procmail -d' is buggy, it adds a '>From <user> ...' header which
## can confuse other programs (due to it starting with >).
## So, let's filter that
:0fHw
| sed -r -e 's/^>From (.*)/Old-From_: \1/;'

1 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=128160