We recommend you read email using 'mutt'. Requests to have other email clients installed may be granted. Pine will not be installed due to a long history of security problems.
You should not have to do anything to send or receive mail on mongers.org. Once your account has been activated, our mailer software will accept all email for your username. The files created in your home directory should ensure that when you send mail using mutt, it will use the correct from name and address.
procmail is a mail pre-processor. It is capable of doing
complex analysis of mail messages and performing various filtering operations
that aid in managing mailing lists and fighting any spam that may slip through
the system counter measures.
Mail is stored in the 'Maildir' format.
If you wish, you may use fetchmail to retrieve mail from other
sites, and read it on our systems. You may place an email address in
~/.qmail-default if you wish your mail to be forwarded
elsewhere.
Dovecot, the imap service, has been installed and is currently available for use in pre-auth mode via an SSH tunnel.
If none of this made sense to you do not worry. You do not need to understand it to read and send email.
Greylisting and greyfiltering is in effect as an anti-spam measure, and bmf and dspam have been installed from ports.
Please see My first mutt for a new user introduction to mutt.
Dovecot imap is available in SSH pre-auth tunnel mode. A configuration example for mutt is displayed below: (Tools like isync or offlineimap have handy features for offline imap folders).
set imap_idle=yes # Keep imap connection open when idle set folder=imap://miracle.mongers.org/ # Set this before using + to point # to mail folders. set spoolfile=+incoming/ set mail_check=60 # Check all folders for new mail every N seconds. Don't # reduce this value. set timeout=10 # Scan current folder for new mail every N seconds. set tunnel="ssh -q miracle.mongers.org MAIL='maildir:~/Maildir/' /usr/local/libexec/dovecot/imap"
Use SSH multi-plexing to speed up mailbox access by logging into miracle (with ControlMaster auto) before starting mutt.
The Dovecot documentation is horribly lacking. Dovecot appears to only display mail folders starting with a dot, so you may need to link incoming to .incoming, sent to .sent, etc. Also, dots in filenames (e.g. "list.openbsd-sc" is treated as a folder, so mutt will display a directory called list with the openbsd-sc mail folder inside.
imaps with certificate authentication is still planned, but not high up on the priority list.
As stated in our UCE policy, a small number of RBLs are used to prevent spammers and spammer friendly sites from delivering mail here. Any connection which has a source IP that is listed in one of the RBLs is dropped, and the email address in the ReturnPath header will get notified of the delivery failure by the MTA which attempted mail delivery.
Consequently, valid mail from any of your friends who may be using a spammer friendly site will actually get told if their attempts to send mail to you was rejected. Valid mail will not simply vanish without a trace.
If you feel you are missing email due to RBLs, check the RBL logs at http://mongers.org/s/rejected-email/
or /var/www/users/stats/rejected-email to see if the site you are
expecting mail from was rejected. Also, check your ~/Maildir/.procmail.log
to see if the mail was delivered to a different folder than then one you
expected.
RBL checking is done on a per machine basis, and cannot be done on a per user basis. The possibility of tagging based on RBL lookups have been considered and may be implemented when I have spare cash to actually pay for the extra IP traffic involved in receiving full spam messages instead of just rejecting mail based on source IP.
Our authentication requirements will protect the contents of the mail as it travels from mongers.org to your workstation. However, this is slightly pointless as the message has just crossed the Internet in plain text.
To protect the contents of your messages, you need to rely on a higher layer than mail protocols. mongers.org has GNU Privacy Guard installed and highly recommend that you start using it. However, there are certain things you need to realise before you do so.
By using GnuPG as installed on mongers.org, you are making the following assumptions:
You need to decide for yourself if these assumptions are safe for you to make. If they are, you should be able to go ahead and make use of GnuPG. If not, you may want to create a GnuPG key pair that you use exclusively for mail sent and recieved through mongers.org. That way, if your assumed web of trust fails, your mongers.org GnuPG key may have been commpromised, but your original GnuPG key is still good.
You may want to leave out the greeting when gpg starts and the version in
clear-text signatures. We use encrypted swap memory so you can safely ignore
the "secure memory" warning. You may supress all of these by editing your
~/.gnupg/options and adding:
no-greeting no-version no-secmem-warning
An alternative to placing encryption keys on miracle would be to use imap and read/decrypt mail locally on your client.
Suppose you have registered example.com and arranged to use miracle as MX for this domain. You will recieve all mail for this domain to your miracle account, unless you state otherwise.
To maquerade outgoing mail, add the following to your .profile
MAILHOST=example.com MAILUSER=userid MAILNAME='Your Full Name' QMAILINJECT=f export MAILHOST MAILUSER MAILNAME QMAILINJECT
These variables can also be set in ~/.ssh/environment if you
want your real userid and name on CVS commit messages.
The system-wide mutt configuration is in /etc/mutt/Muttrc. User
specific options go in ~/.muttrc which can also be used to
override system-wide options. Users are encouraged to study the system-wide
file and consult muttrc(5) for the exact meaning of options.
The system-wide configuration is placed in /etc/procmailrc. If
you want to create your own ~/.procmailrc you should copy this
file and add your own options. ~/.procmailrc cannot be a symlink.
The order of rules is important, and generally, only the first match is used. The following entry filters dublets before you ever see them, and stores the msgid of the previous 8192 messages in msgid.cache. This should probably be one of your first rules.
:0 Wh: msgid.lock | formail -D 8192 msgid.cache
This entry kills HTML email:
:0: * Content-type: text/html /dev/null
Use Sender, List-Id or something similar from the header to match mailing list mail. Avoid trying to match on To, Cc or Bcc. If you postfix the folder with a slash, procmail will write the mail to a Maildir.
:0: * List-Id: <secprog\.list-id\.securityfocus\.com> list.secprog/ :0: * Sender: owner-source-changes@openbsd\.org list.openbsd-sc/
Some brief notes, stolen from http://cr.yp.to/ezmlm.html:
A user of mongers.org types:
$ ezmlm-make ~/SOS ~/.qmail-sos userid-jokes mongers.org
and instantly has a functioning mailing list (seemingly for distribution of
jokes), userid-jokes@mongers.org, with all relevant information
stored in a new ~/SOS directory. This location can be anywhere the
user has write access.
The listname you specify must contain your userid. If you want to create a list which does not contain your userid, contact staff. If mongers.org hosts an MX for you, you may create lists on this domain at will by replacing mongers.org with your domain name in the ezmlm-make command.
ezmlm sets up joe-sos-subscribe and
joe-sos-unsubscribe for automatic processing of subscription and
unsubscription requests. Any message to joe-sos-subscribe will
work; The list admin doesn't have to explain any tricky command formats. ezmlm will send
back instructions if a subscriber sends a message to
joe-sos-request or joe-sos-help.
ezmlm automatically archives new messages. Messages are labelled with
sequence numbers; a subscriber can fetch message 123 by sending mail to
joe-sos-get.123. The archive format supports fast message
retrieval even when there are thousands of messages.
ezmlm takes advantage of qmail's VERPs to reliably determine the recipient address and message number for every incoming bounce message. It waits ten days and then sends the subscriber a list of message numbers that bounced. If that warning bounces, ezmlm sends a probe; if the probe bounces, ezmlm automatically removes the subscriber from the mailing list.
ezmlm is easy for users to control. The user can edit ~/SOS/text/*
to change any of the administrative messages sent to subscribers. He can remove
~/SOS/public (removing this file is strongly recommended) and
~/SOS/archived to disable automatic subscription and archiving. He
can put his own (any) email address into ~/SOS/editor to set up a
moderated mailing list. He can edit
~/SOS/{headeradd,headerremove} to control outgoing headers.
To view who is subscribed to your list, type:
$ ezmlm-list ~/SOS
You may use the vacation(1) program to mail out vacation
notices when you go away for longer periods of time. The program will not
spam posters to mailinglists, and it will only mail out one notification
per vacation.
The vacation program expects ~/.vacation.msg containing your
with SMTP headers. You can use this template:
From: Full Name <userid@mongers.org> Subject: Away until Date/Month Precedence: bulk This is an autogenerated message. Feel free to send more mail; you will only receive this message once. I am away on vacation, returning x/y. For queries related to FOO, contact FOO Master at foo-master@example.com. Sincerely, Full Name
When you have created the message, insert the following near the top of your
~/.procmailrc, replacing userid with your system login.
:0: | /usr/bin/vacation userid
When you return from vacation, prefix those two lines with # and delete
~/.vacation.db so that vacation will send out notices next time
you go on vacation. Go through your mail, and delete most of it because there
is just too much of it to read anyway.
This is what you do if you think you're not getting mail to your miracle account.
Sign into two sesions, one running mutt, the other running
tail -f ~/Maildir/.procmail.log. From mutt, send a
message to your local email address. An entry should appear immediately
in your .procmail.log showing the message as received and telling you
where it was stored. You should be able to find the message in your inbox in
mutt. If so, local mail works.
While keeping the .procmail.log open, send mail to your miracle account from somewhere else. Remember: If you never sent mail to miracle from that place before, the outbound mailserver will be subject to greyfiltering so an actual delivery make not take place for 30 minutes or more. You might want to ask a friend who sends you mail all the time to send you a test mail, as to avoid the greylisting delay on unknown systems. Again, you should see an entry in .procmail.log within a few minutes, and if so, remote mail works also.
Maybe your actual email address doesn't end in 'mongers.org', which means you have mail hosted here or somewhere else. Check that the domain MX records are correct with:
$ host -t MX example.com example.com mail is handled by 50 smtp.example.com.
If your mail isn't handled by miracle, you need to make sure your external MX host works.
If you need any help finding the cause of your mail issues, talk to Daddy Chief.