Mail: Difference between revisions

From FyshyWyky
Jump to navigationJump to search
(→‎Having us handle email for your domain: Add SPF, DKIM and DMARC information)
 
(106 intermediate revisions by the same user not shown)
Line 5: Line 5:


== Introduction ==
== Introduction ==
[[bowl.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 [mailto:postmaster@fysh.org The Fyshy Postmaster] with details for us to configure things correctly.
[[river.fysh.org]] hosts the primary Mail eXchanger (MX) for fysh.org itself and any other domain configured to deliver locally on it. If you have a domain that you would like us to host then please email [mailto:postmaster@fysh.org The Fyshy Postmaster] with details for us to configure things correctly.


We currently use [http://www.exim.org/ exim4] as the [[wikipedia:Mail transfer agent|MTA]] that handles all email.  This is configured to allow relaying only for [[Services:Mail:SMTP#Auth|authorised users]] and also employs a number of [[Services/Mail/Spam#Counter_Measures|Anti-Spam Countermeasures]] to help protect our users from the deluge that is the norm on the Internet today.
We currently use [http://www.exim.org/ exim4] as the [[wikipedia:Mail transfer agent|MTA]] that handles all email.  This is configured to allow relaying only for [[Mail#SMTP|authorised users]] and also employs a number of [[Mail#MTA_Counter-Measures|Anti-Spam Countermeasures]] to help protect our users from the deluge that is the norm on the Internet today.
 
It should be noted that '''outbound email purporting to come from a fysh.org email address must be sent through mail.fysh.org or directly on river.fysh.org'''.  Attempt to send such from any other email server risks it being rejected if the receiving server checks SPF and/or DKIM.


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 [[wikipedia:Mail user agent|MUA]] locally through a [[Services/Shell Accounts|shell login]] if they prefer.
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 [[wikipedia:Mail user agent|MUA]] locally through a [[Services/Shell Accounts|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 [mailto:postmaster@fysh.org 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:
=== SPF (Sender Policy Framework) records ===
[https://datatracker.ietf.org/doc/html/rfc7208 Sender Policy Framework] helps prevent spammers from sending email pretending to be from you.
So long as you're confident that all holders of email accounts within your domain have access to send through mail.fysh.org you can specify an SPF record that copies the one for fysh.org.  Check the current one with, e.g.:
host -t txt fysh.org | grep v=spf1
We recommend initially ending your record with " ~all", not " -all" until you confirm it is working as intended.
If we host the DNS for your domain we can take care of this at your request.
=== DKIM (DomainKeys Identified Mail) ===
[https://www.rfc-editor.org/rfc/rfc6376.html DomainKeys Identified Mail] allows email to be signed at the originating email server to attest that the email is from a genuine user of the domain.  This entails setting up a signing key and a DNS record with the public half of the key pair for that so recipients can verify the signatures.
If we control the DNS for your domain (as that makes it much easier for us to perform the necessary setup, we can enable outbound DKIM signing of email for your domain.  As with SPF, you really want mail.fysh.org to be the only place that email from the domain originates, i.e. all users send email through there.  If not you risk genuine email going out unsigned and thus looking like possible spam.
=== Domain-based Message Authentication, Reporting, and Conformance (DMARC) ===
[https://www.rfc-editor.org/rfc/rfc7489 Domain-based Message Authentication, Reporting, and Conformance] mostly allows you to define email address(es) to receive reports about email received elsewhere purporting to be from your domain, with the information pertaining to the passing or failure of both SPF and DKIM checks.  It also allows for allowing or disallowing that your SPF and DKIM setups also apply to any subdomain of your domain.
It does ''not'' allow you to alter the soft/hard fail nature of your SPF or DKIM setup.
If we control your DNS then we can set up the necessary DNS record for this.  You'll need to either tell us the email addresses you'd like the reports to go to, or tell us that you're happy for us to receive them (which can help us diagnose issues with SPF and/or DKIM on your domain).
=== 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 ==
== 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.
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.  To do so you will first have to [https://www.fysh.org/utils/smtppassword.cgi set up a password] specifically for this.
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 [https://www.fysh.org/utils/smtppassword.cgi set up a password] specifically for this.


Configure your Email Client with the following details:
Configure your Email Client with the following details:
Line 26: Line 70:
|-
|-
| Port
| Port
| 25 (''NB: You may also use the SMTP Submission Port, 587, for this.'')
| 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
| Secure Connection
| Enable 'TLS' for preference, or 'SSL' if your client only supports that.
| Enable 'STARTTLS' or 'TLS', preferably at least version 1.2 if given the option.
|-
|-
| Authentication
| Authentication
| Your bowl.fysh.org username and the password you [https://www.fysh.org/utils/smtppassword.cgi setup] specifically for this, ''not'' your [[Shell Account|shell login]] password.
| Your [[river.fysh.org]] username and the password you [https://www.fysh.org/utils/smtppassword.cgi set up] specifically for this, ''not'' your [[Services/Shell Accounts|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.
# 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).
# 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]]
<pre>MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/
</pre>
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:


<pre>######################################
# The Fysh List
######################################
:0
* ^TOfysh@fysh\.org
.fyshlist/
:0
* ^FROMfysh-.*@fysh\.org
.fyshlist/
######################################</pre>
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==
== 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).
=== Forwarding email elsewhere to read it ===
We '''STRONGLY ADVISE AGAINST BLINDLY FORWARDING ALL EMAIL TO ANOTHER PROVIDER IN ORDER TO READ IT THERE'''.  Why?  Because you will inevitably be forwarding some amount of spam and ''that WILL cause the other provider to consider us as a source of spam''.  That will then not only mean that your forward either doesn't work at all, or encounters delays, '''but also that any other email from mail.fysh.org users to that provider will be adversely affected'''.
'''NO''', it is not sufficient to use, e.g. [[Mail#Spamassassin|Spamassassin]], to filter email on mail.fysh.org and only forward what it doesn't think is spam.  Google often treats email as suspicious that Spamassassin doesn't.
An unfortunate example of this is setting a fysh.org account up to forward all email to a Google Mail (gmail.com/googlemail.com) account.  Eventually enough email sent to Google in this manner will cause them to, at best, rate limit how fast mail.fysh.org can send email to the entire Google Mail service.  It has been observed that this can cause email from mail.fysh.org to all Google Mail accounts to be '''delayed by over 40 hours'''.
We have no reason to believe that other major email providers, e.g. Microsoft's Outlook webmail, won't exhibit a similar issue.
==== Actually just use the other email provider ====
In the first instance, if you prefer this other email provider (and remember we do have both [[Mail#Webmail|Webmail]] and [[Mail#POP3|POP3]]/[[Mail#IMAP|IMAP]] service available), then just use them.  Update your email address with anyone who utilises it and stop using mail.fysh.org in this manner.
==== Set up the other provider to ''pull'' from mail.fysh.org instead ====
Even if you decide to just use this other email provider you might want to ensure you still know about email arriving on mail.fysh.org for you.  In some cases you will be able to set up the other email provider to check your mail.fysh.org account in a 'pull' manner.
What follows is best-efforts advice on how to set this up, but is not guaranteed to be accurate or work when you're reading this.  Many other email providers might have the functionality, but not in a free tier that we could access and test.  In general you're looking for an option to utilise 'POP', 'POP3', or 'IMAP' to retrieve email from another account.
===== Pull to Google Mail =====
# Access the settings for your account.  As of 2022-02-28 this can be found via: Cog > See all settings
# Select 'Accounts and Import'
# Scroll down to 'Check email from other accounts'
# Select 'Add an email account', which will open a popup
# Email address: <fysh user>@fysh.org (yes, even if technically the email is for another domain)
# Import emails from my other account (POP3)
# Username: <should be autofilled if you got #2 correct)
# Password: <The fysh.org account password>.  Yes, you'll have to tell Google this. For *this* purpose we approve of this.
# POP Server: <should have autofilled as 'mail.fysh.org' from #2>
# Port: 995
# Do '''NOT''' tick "Leave a copy of retrieved message on the server."
# '''YOU MUST TICK''' "Always use a secure connection (SSL) when retrieving mail"
# Your choice of "Label incoming messages".  Perhaps the mail.fysh.org account is actually receiving email under a different domain, so you will want to change this to reflect that.
# You probably ''do not'' want to tick "Archive incoming messages (Skip the Inbox), because you want to be aware of the new email, yes ?
=== POP3 ===
=== POP3 ===
mail.fysh.org 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.
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.


{| border="1" cellspacing="0" cellpadding="5" align="center"
{| border="1" cellspacing="0" cellpadding="5" align="center"
Line 50: Line 166:
|-
|-
| Port
| Port
| 110
| 110 <sup>1</sup>
|-
|-
| User Name
| User Name
| Your bowl.fysh.org username  
| Your [[river.fysh.org]] username  
|-
|-
| Password
| Password
| Your [[Shell Account|shell login]] password, not the SMTP AUTH one.
| Your [[Shell Accounts|shell login]] password, not the SMTP AUTH one.
|-
|-
| Secure Connection
| Secure Connection
Line 62: Line 178:
|-
|-
| Use Secure Authentication
| Use Secure Authentication
| OFF (the server doesn't support this)
| OFF <sup>2</sup>
|-
|-
|}
|}


<sup>1</sup> - If port 110 is blocked from your site, then try port 995 instead, with TLS or SSL for 'Secure Connection'.
<sup>2</sup> - APOP authentication is no longer supported.


=== IMAP ===
=== IMAP ===
mail.fysh.org 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.
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.


{| border="1" cellspacing="0" cellpadding="5" align="center"
{| border="1" cellspacing="0" cellpadding="5" align="center"
Line 81: Line 200:
|-
|-
| User Name
| User Name
| Your bowl.fysh.org username  
| Your [[river.fysh.org]] username  
|-
|-
| Password
| Password
| Your [[Shell Account|shell login]] password, not the SMTP AUTH one.
| Your [[Shell Accounts|shell login]] password, not the SMTP AUTH one.
|-
|-
| Secure Connection
| Secure Connection
| Use SSL
| Use TLS if available, else SSL.
|-
|-
| Use Secure Authentication
| Use Secure Authentication
| OFF (the server doesn't support this)
| OFF (the server doesn't support this)
|-
| Prefix
| Leave blank to use the configuration we have set up for you.  See the notes below.
|-
|-
|}
|}


# 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.
# 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>.
# 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 ===
=== Webmail ===
We offer access to email held on mail.fysh.org via HTTP using [http://www.squirrelmail.org/ Squirrelmail].  The address for this service is [https://squirrelmail.fysh.org/ https://squirrelmail.fysh.org/], or if for some reason you're unable to use encrypted HTTP (HTTPS) use [http://squirrelmail.fysh.org/ http://squirrelmail.fysh.org/] 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.
We offer access to email held on mail.fysh.org via HTTP using [https://roundcube.net/ Roundcube].  The address for this service is [https://roundcube.fysh.org/ 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.


{| border="1" cellspacing="0" cellpadding="5" align="center"
{| border="1" cellspacing="0" cellpadding="5" align="center"
| URL
| URL
| https://squirrelmail.fysh.org/ (preferred) or http://squirrelmail.fysh.org/ if that is unuseable from your location
| https://roundcube.fysh.org/
|-
|-
| Username/Password
| Username/Password
| Your bowl.fysh.org [[Shell Account|shell login]] details.
| Your [[river.fysh.org]] [[Shell Accounts|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.


=== Reading Mail Locally ===
==== Mutt ====
Many Fysh.Org users prefer to read their email by logging in to bowl.fysh.org 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.
The main supported program for this is Mutt.  This supports default mbox style mailboxes along with [[Mail#Using Maildir instead of mbox|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 [[Mail#Using Maildir instead of mbox|Maildir]] format, but you can simply use IMAP instead if needs be. Set 'Inbox Path' to something like (change 'athan' to your username):


<pre>mail.fysh.org/user=athan</pre>


And the Folder to:


== Maillists ==
<pre>Maildir/INBOX</pre>
fysh.org is available for hosting multi-user maillists using [http://www.gnu.org/software/mailman/index.html MailMan] as the software.  There is a [http://www.fysh.org/mailman/listinfo list] of those hosted maillists that allow public viewing of details.  Please contact [mailto:postmaster@fysh.org 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.


==== 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 [https://list.org/ MailMan] as the software.  There is a [https://www.fysh.org/mailman3/postorius/lists/ list] of those hosted maillists that allow public viewing of details.  Please contact [mailto:postmaster@fysh.org 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 ==
== Email Spam ==
Line 125: Line 270:


=== MTA Counter-Measures ===
=== MTA Counter-Measures ===
mail.fysh.org employs some measures at the [[wikipedia:MTA|MTA]] level to reduce the amount of spam that ends up in our users' inboxes.
mail.fysh.org employs some measures at the [[wikipedia:MTA|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:'''
'''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 [[Mail#SMTP|authenticated]].
*The email is being submitted to us on port 587, the Mail Submission port which ''requires'' all senders to be [[Mail#SMTP|authenticated]].
*The connection is otherwise [[Mail#SMTP|authorised]] and thus trusted.
*The connection is otherwise [[Mail#SMTP|authenticated]] and thus trusted.
*Email being sent by mail.fysh.org itself, i.e. locally generated email.
*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.
*Any email addressed to 'postmaster', 'abuse', or 'dmarcreports' at any domain we are relaying email forThey get to make their own decision on the primary MX.  This does mean that email to those local parts for domains delivered locally on mail.fysh.org might be rejected due to one of our MTA-level antispam measures.




Line 144: Line 289:
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.
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 Accounts|shell account]] login can still send email to/via mail.fysh.org from a dialup or ADSL connection, provided that they have [[Mail#SMTP|authorised]] themselves first, which is necessary anyway to relay through mail.fysh.org.''
''NB: Users with a fysh.org [[Shell Accounts|shell account]] login can still send email to/via mail.fysh.org from a dialup or ADSL connection, provided that they have [[Mail#SMTP|authenticated]] themselves first, which is necessary anyway to relay through mail.fysh.org.''
 


==== Realtime Black Lists ====
==== Realtime Black Lists ====
The single measure we find reduces locally-delivered spam the most is to make use of the [http://www.spamhaus.org/ Spamhaus] SBL-XBL ''[[wikipedia:DNSBL|RBL]]''.  This is basically a list of hosts known to send email spam. We also still use the relays.ordb.org RBL, but it very seldom catches anything that SBL-XBL doesn't<!-- I find the exim docs unclear as to if multiple domains on a dnslists are tested in paralell or in the order you specify.  If it's the latter then, given we're checking relays.ordb.org first, it's being next to useless for us given how much more sbl-xbl catches after it -Athan --> 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 single measure we find reduces locally-delivered spam the most is to make use of the [http://www.spamhaus.org/ Spamhaus] [https://www.spamhaus.org/zen/ Zen] ''[[wikipedia:DNSBL|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 [mailto:postmaster@fysh.org The Fyshy Postmaster] with full details, preferably the full headers and relevant body of the original email and/or the bounce that was generated.
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 [mailto:postmaster@fysh.org 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.
==== SPF checks on inbound email ====
As of 2023-11-30 mail.fysh.org will reject any email if the SPF check returns a hardfail.  This means the alleged sending domain (envelope from):


==== Greylisting ====
1. Has declared an SPF record.
The other primary anti-spam counter-measure that we employ is called Greylisting.
2. That record does not list the sending IP as allowed.
3. That record ends with "-all" to denote that any other IP should cause rejection of the email.


Any time an email is sent to a domain delivered on mail.fysh.org it is checked against our [[wikipedia:Greylisting|Greylisting]] lists.  The data that is checked is the tuple "<originating IP> <mail from address> <mail to address>" (NB: These are the ''Envelope'' To and From, which aren't necessarily the same as those in the headers of the email itself).  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.
==== DKIM Signature Verification ====
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 list''.
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 to 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 list'' 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.
As of 2022-08-07 we have implemented MTA level checking of DKIM signatures '''but do not reject any email based on this'''.


You can check what the outcome of this by checking the ''top-most'' (in case someone nefarious tried to pre-add any of them) "X-DKIM" and "Authentication-Results" headers in any email delivered by mail.fysh.org.


'''Problems With Greylisting'''
Examples:


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:
1. Valid DKIM signature(s)
    X-DKIM: Exim 4.94.2 on river.fysh.org
    Authentication-Results: river.fysh.org; dkim=pass header.d=twitch.tv header.i= header.s=wcdtjomfpuxxefyhk6a7dbwy5fy6ofyc
    Authentication-Results: river.fysh.org; dkim=pass header.d=amazonses.com header.i= header.s=ndjes4mrtuzus6qxu3frw3ubo3gpjndv


:bugtraq-return-28583-bugtraq=miggy.org @ securityfocus.com
2. INvalid DKIM signature(s)
:bugtraq-return-28581-bugtraq=miggy.org @ securityfocus.com
    X-DKIM: Exim 4.94.2 on river.fysh.org
    Authentication-Results: river.fysh.org; dkim=fail header.d=twitch.tv header.i= header.s=wcdtjomfpuxxefyhk6a7dbwy5fy6ofyc reason="signature_incorrect"
    Authentication-Results: river.fysh.org; dkim=fail header.d=amazonses.com header.i= header.s=ndjes4mrtuzus6qxu3frw3ubo3gpjndv reason="signature_incorrect"


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 list''. 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 [mailto:postmaster@fysh.org forward us] the full headers from at least 3 example emails that came from the list so that we can determine which sending host(s) 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.
3. No signature on a domain we've seen valid ones on in the past (manually curated list).
    X-DKIM: Exim 4.94.2 on river.fysh.org (no dkim signature for required domain: twitch.tv)


There are also some misconfigured or badly coded MTAs in use which don't retry email at all. In this case you'll again need to [mailto:postmaster@fysh.org inform us] of the IP(s) of the sending host(s) so we can add them to our ''whitelisted hosts list'' for greylisting.
4. No signature on a domain we do ''not'' have in that list.
    X-DKIM: Exim 4.94.2 on river.fysh.org (no dkim signature for example.com)


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. Please email [mailto:postmaster@fysh.org The Fyshy Postmaster] with any requests to have either your entire domain or just a set of full addresses skip greylisting.
SpamAssassin can also do its own verification of DKIM signatures, and on river.fysh.org will do so by default.  Further more the current webmail, roundcube, can display the result of this if you enable the "Auth. Result" column in the mailbox view.
 
==== Greylisting ====
As of 2019-10-17 ~12:53 BST we have turned off [https://en.wikipedia.org/wiki/Greylisting greylisting] entirely.  As no issues were reported or observed in the following 2 weeks this was then made permanent.


=== User Counter-Measures ===
=== User Counter-Measures ===
Line 182: Line 345:
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.
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 bowl.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.
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 bowl.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 [http://www.fysh.org/mailman/listinfo/Fysh-Announce Fysh-Announce].
''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 [http://www.fysh.org/mailman/listinfo/Fysh-Announce 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.


<!-- Link to an example .procmailrc for specific fysh.org anti-spam measures-->
<!-- Link to an example .procmailrc for specific fysh.org anti-spam measures-->
<!-- This example needs cleaning up and putting within this Wiki, or at least within the web area and linked here-->
<!-- This example needs cleaning up and putting within this Wiki, or at least within the web area and linked here-->
There is an example usage of procmail available on bowl.fysh.org in ~athan/etc/procmailrc-example .  Please note you WILL have to edit this to suit your own email needs, do NOT put it in place (~/.procmailrc) as-is !
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:
 
# filtering spam into a sub-folder using spamassassin
# a fixup for a quirk to do with the 'From ' (no-colon) email header.
# 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).
# Ensuring proper headers are in place for PGP/GPG encrypted/signed messages.
 
Furthermore it has examples for:
 
# Temporarily disabling email delivery
# Excepting email from even being run through spamassassin.
# Discarding email without causing a bounce.
# Filtering extra 'me' email addresses into your INBOX.


==== Exim Filters ====
==== Exim Filters ====
Line 196: Line 373:
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.
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 [[Mail#Procmail 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:
We do not run Spamassassin at the MTA level on mail.fysh.org, but any user can make use of [[Mail#Procmail|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:


<pre>
<pre>
Line 218: Line 395:
:0
:0
* ^X-Spam-Status: Yes
* ^X-Spam-Status: Yes
spam
.spam/
</pre>
</pre>


Please be sure to read the Spamassassin documentation ('''man spamassass''' and the files under bowl:/usr/share/doc/spamassassin) before putting a section like this in your ~/.procmailrc file.
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 ====
Bogofilter is another means of automatically determining if an email is spam.  It uses something called [[wikipedia:Bayesian spam filtering|Bayesian filtering]] to attempt to determine if the text of an email is spam or not.  [[Mail#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.
Bogofilter is another means of automatically determining if an email is spam.  It uses something called [[wikipedia:Bayesian spam filtering|Bayesian filtering]] to attempt to determine if the text of an email is spam or not.  [[Mail#Spamassassin|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.
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.
Line 257: Line 434:
:0:
:0:
* ^X-Bogosity: Yes, tests=bogofilter
* ^X-Bogosity: Yes, tests=bogofilter
spam
.spam/
</pre>
</pre>


Line 271: Line 448:
###        :0
###        :0
###        * ^TO(abuse|postmaster)@fysh\.org
###        * ^TO(abuse|postmaster)@fysh\.org
###        fysh
###        .fysh/
###  
###  
###        :0 B
###        :0 B
###        * !http://www\.bodybouncer\.com/
###        * !http://www\.bodybouncer\.com/
###        inbox
###        $MAILDIR/
### }
### }


Line 323: Line 500:
         ## Make sure SpamAssassin's filtering learns it as spam
         ## Make sure SpamAssassin's filtering learns it as spam
         :0c
         :0c
         |sa-learn --spam
         |formail -I "X-Bogosity" | sa-learn --spam


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


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


Line 387: Line 571:


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.
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 ===
=== Sending Spam from mail.fysh.org ===
Line 394: Line 584:


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|web space]] that could possibly be insecure and allow for sending of email to arbitrary addresses.
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|web space]] that could possibly be insecure and allow for sending of email to arbitrary addresses.
=== Hey spammers ===
I'd love some spam to [mailto:poohshoney@fysh.org poohshoney@fysh.org] !
== Known Problems & Workarounds ==
=== 'procmail -d' introducing >From header ===
There is a known bug<sup>1</sup> 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:
<pre>
## '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/;'
</pre>
<sup>1</sup> - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=128160


[[Category:Services]]
[[Category:Services]]

Latest revision as of 19:47, 7 December 2023

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. 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.

It should be noted that outbound email purporting to come from a fysh.org email address must be sent through mail.fysh.org or directly on river.fysh.org. Attempt to send such from any other email server risks it being rejected if the receiving server checks SPF and/or DKIM.

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:

SPF (Sender Policy Framework) records

Sender Policy Framework helps prevent spammers from sending email pretending to be from you.

So long as you're confident that all holders of email accounts within your domain have access to send through mail.fysh.org you can specify an SPF record that copies the one for fysh.org. Check the current one with, e.g.:

host -t txt fysh.org | grep v=spf1

We recommend initially ending your record with " ~all", not " -all" until you confirm it is working as intended.

If we host the DNS for your domain we can take care of this at your request.

DKIM (DomainKeys Identified Mail)

DomainKeys Identified Mail allows email to be signed at the originating email server to attest that the email is from a genuine user of the domain. This entails setting up a signing key and a DNS record with the public half of the key pair for that so recipients can verify the signatures.

If we control the DNS for your domain (as that makes it much easier for us to perform the necessary setup, we can enable outbound DKIM signing of email for your domain. As with SPF, you really want mail.fysh.org to be the only place that email from the domain originates, i.e. all users send email through there. If not you risk genuine email going out unsigned and thus looking like possible spam.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Domain-based Message Authentication, Reporting, and Conformance mostly allows you to define email address(es) to receive reports about email received elsewhere purporting to be from your domain, with the information pertaining to the passing or failure of both SPF and DKIM checks. It also allows for allowing or disallowing that your SPF and DKIM setups also apply to any subdomain of your domain.

It does not allow you to alter the soft/hard fail nature of your SPF or DKIM setup.

If we control your DNS then we can set up the necessary DNS record for this. You'll need to either tell us the email addresses you'd like the reports to go to, or tell us that you're happy for us to receive them (which can help us diagnose issues with SPF and/or DKIM on your domain).

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).

Forwarding email elsewhere to read it

We STRONGLY ADVISE AGAINST BLINDLY FORWARDING ALL EMAIL TO ANOTHER PROVIDER IN ORDER TO READ IT THERE. Why? Because you will inevitably be forwarding some amount of spam and that WILL cause the other provider to consider us as a source of spam. That will then not only mean that your forward either doesn't work at all, or encounters delays, but also that any other email from mail.fysh.org users to that provider will be adversely affected.

NO, it is not sufficient to use, e.g. Spamassassin, to filter email on mail.fysh.org and only forward what it doesn't think is spam. Google often treats email as suspicious that Spamassassin doesn't.

An unfortunate example of this is setting a fysh.org account up to forward all email to a Google Mail (gmail.com/googlemail.com) account. Eventually enough email sent to Google in this manner will cause them to, at best, rate limit how fast mail.fysh.org can send email to the entire Google Mail service. It has been observed that this can cause email from mail.fysh.org to all Google Mail accounts to be delayed by over 40 hours.

We have no reason to believe that other major email providers, e.g. Microsoft's Outlook webmail, won't exhibit a similar issue.

Actually just use the other email provider

In the first instance, if you prefer this other email provider (and remember we do have both Webmail and POP3/IMAP service available), then just use them. Update your email address with anyone who utilises it and stop using mail.fysh.org in this manner.

Set up the other provider to pull from mail.fysh.org instead

Even if you decide to just use this other email provider you might want to ensure you still know about email arriving on mail.fysh.org for you. In some cases you will be able to set up the other email provider to check your mail.fysh.org account in a 'pull' manner.

What follows is best-efforts advice on how to set this up, but is not guaranteed to be accurate or work when you're reading this. Many other email providers might have the functionality, but not in a free tier that we could access and test. In general you're looking for an option to utilise 'POP', 'POP3', or 'IMAP' to retrieve email from another account.

Pull to Google Mail
  1. Access the settings for your account. As of 2022-02-28 this can be found via: Cog > See all settings
  2. Select 'Accounts and Import'
  3. Scroll down to 'Check email from other accounts'
  4. Select 'Add an email account', which will open a popup
  5. Email address: <fysh user>@fysh.org (yes, even if technically the email is for another domain)
  6. Import emails from my other account (POP3)
  7. Username: <should be autofilled if you got #2 correct)
  8. Password: <The fysh.org account password>. Yes, you'll have to tell Google this. For *this* purpose we approve of this.
  9. POP Server: <should have autofilled as 'mail.fysh.org' from #2>
  10. Port: 995
  11. Do NOT tick "Leave a copy of retrieved message on the server."
  12. YOU MUST TICK "Always use a secure connection (SSL) when retrieving mail"
  13. Your choice of "Label incoming messages". Perhaps the mail.fysh.org account is actually receiving email under a different domain, so you will want to change this to reflect that.
  14. You probably do not want to tick "Archive incoming messages (Skip the Inbox), because you want to be aware of the new email, yes ?

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 'postmaster', 'abuse', or 'dmarcreports' at any domain we are relaying email for. They get to make their own decision on the primary MX. This does mean that email to those local parts for domains delivered locally on mail.fysh.org might be rejected due to one of our MTA-level antispam 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.

SPF checks on inbound email

As of 2023-11-30 mail.fysh.org will reject any email if the SPF check returns a hardfail. This means the alleged sending domain (envelope from):

1. Has declared an SPF record. 2. That record does not list the sending IP as allowed. 3. That record ends with "-all" to denote that any other IP should cause rejection of the email.

DKIM Signature Verification

As of 2022-08-07 we have implemented MTA level checking of DKIM signatures but do not reject any email based on this.

You can check what the outcome of this by checking the top-most (in case someone nefarious tried to pre-add any of them) "X-DKIM" and "Authentication-Results" headers in any email delivered by mail.fysh.org.

Examples:

1. Valid DKIM signature(s)

   X-DKIM: Exim 4.94.2 on river.fysh.org
   Authentication-Results: river.fysh.org; dkim=pass header.d=twitch.tv header.i= header.s=wcdtjomfpuxxefyhk6a7dbwy5fy6ofyc
   Authentication-Results: river.fysh.org; dkim=pass header.d=amazonses.com header.i= header.s=ndjes4mrtuzus6qxu3frw3ubo3gpjndv

2. INvalid DKIM signature(s)

   X-DKIM: Exim 4.94.2 on river.fysh.org
   Authentication-Results: river.fysh.org; dkim=fail header.d=twitch.tv header.i= header.s=wcdtjomfpuxxefyhk6a7dbwy5fy6ofyc reason="signature_incorrect"
   Authentication-Results: river.fysh.org; dkim=fail header.d=amazonses.com header.i= header.s=ndjes4mrtuzus6qxu3frw3ubo3gpjndv reason="signature_incorrect"

3. No signature on a domain we've seen valid ones on in the past (manually curated list).

   X-DKIM: Exim 4.94.2 on river.fysh.org (no dkim signature for required domain: twitch.tv)

4. No signature on a domain we do not have in that list.

   X-DKIM: Exim 4.94.2 on river.fysh.org (no dkim signature for example.com)

SpamAssassin can also do its own verification of DKIM signatures, and on river.fysh.org will do so by default. Further more the current webmail, roundcube, can display the result of this if you enable the "Auth. Result" column in the mailbox view.

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