• RoundCube : accessing email from the web

• PostGrey : further spam defence

• ClamAV : setting up the automated antivirus system

AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED

This setup will work on most -if not all- linux distributions without major change and the instructions should work out-of-the-box on all recent RedHat derived systems: RedHat Linux, CentOS and Fedora.

• 03DEC2008 Created archive for Fedora Core 5 and started updating for'recent distros.

AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for CentOS 5.2

AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for Fedora Core 10

%bgcolor=#FF0000;color=#FFFFFF% AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for Fedora Core 10

AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for Fedora Core 10

AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for Fedora Core 10

AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for Fedora Core 10

AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for Fedora Core 10

   AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for Fedora Core 10 

AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for Fedora Core 10

white%AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for Fedora Core 10

AS OF 03DEC2008, the articles below ARE IN THE PROCESS OF BEING UPDATED for Fedora Core 10

Older versions

• The update for Fedora Core 5 is available as a single long page.
• The original article written for Fedora Core 4 is available as a single long page.

• 03DEC2008 Created archive for Fedora Core 5 and started updating for Fedora Core 10.
• 23MAY2006 Added sections Firewall, SecureAccess and AlternateAccess.
• 21DEC2005 Fixed layout issues with the single long page version of this article.
• 20DEC2005 Added section on Baysian filtering in SpamAssassin
• 02DEC2005 Added SpamAssassinImproved
• 22DEC2005 Added AWStats
• 14JUL2005 Original version

The update for Fedora Core 5 is available as a single long page.

All articles below have being updated for Fedora Core 10

• 2006-05-23 Added sections Firewall, SecureAccess and AlternateAccess.

All articles below have being updated for Fedora Core 5

• SpamAssassin : filtering out spam

All articles below are being updated for Fedora Core 5, starting 19JUN2006. This will take a few days

The original article written for Fedora Core 4 is available as a single long page.

• All articles below are being updated for Fedora Core 5, starting 19JUN2006. This will take a few days

(:description This is a rather extensive article describing the configuration of a high performance Mail server for Small and Medium businesses, with a focus on security, mail retention and accessibility though IMAP and webmail :)

• Gmail on Home Linux Box using Postfix and Fetchmail (Using SASL and TLS)

• 2206-05-23 Added sections Firewall, SecureAccess and AlternateAccess.

• SecureAccess : using SSL to encrypt email communications
• AlternateAccess : circumventing ports blocking by ISPs

• 2206-05-23 Added sections Firewall, SecureAccess and AlternateAccess.

• 2005-12-21 Fixed layout issues with the single long page version of this article.
• 2005-12-20 Added section on Baysian filtering in SpamAssassin

• SpamAssassinImproved : Improving spam filering

• 2005-12-02 Added SpamAssassinImproved
• 2005-07-22 Added AWStats

• Gmail on Home Linux Box using Postfix and Fetchmail (Using SASL and TLS)

• AWStats : mail log analysis and statistics

• 2005-07-22 Added AWStats

• AWStat? : mail log analysis and statistics

Todo

• ConfigClients : how to configure mail clients such as Outlook or Thunderbird

• Postfix SMTP AUTH (and TLS) HOWTO

History

• 2005-07-14 Original version
• 2005-07-22 Added AWStat?

• List of email related IETF technologies and their implementations, such as SASL
• Postfix SMTP AUTH (and TLS) HOWTO

• List of email related IETF technologies and their implementations, such as SASL

Resources

You will find relevant resources in each article above. The following resources are more wide-ranging and are excellent articles to use as references.

• http://www.freespamfilter.org/
• How to install Postfix, Amavisd-new, SpamAssassin, Pyzor, Razor, DCC, and ClamAV on Fedora Core 4 - v2.1.1
• ISP-style Email Service with Debian-Sarge and Postfix 2.1

• ConfigClients : how to configure mail clients such as Outlook or Thunderbird

This is a rather extensive article describing the configuration of a high performance Mail server for Small and Medium businesses, with a focus on security, mail retention and accessibility though IMAP and webmail.

This is a rather extensive article describing the configuration of a high performance Mail server for Small and Medium businesses, with a focus on secutiry, mail retention and accessibility though IMAP and webmail.

• ConfigClients : how to configure mail clients sur as Outlook or Thunderbird

• ConfigClients : how to configure mail clients sur as Outlook, or Trhunderbird to use our server

This is a rather extensive article describing the configuration of a high performance Mail server for Small and Medium businesses, with a focus on mail retention and accessibility though IMAP.

You can view the article as a single long page or as a series of smaller articles describing each steps to perform :

• Preparation : description of objectives, assumptions and installation
• Users : how users are configured
• Postfix : using Postfix as the Mail Transport Agent (MTA)
• Dovecot : using Dovecot for high performance POP/IMAP access
• AmavisdNew : setting up filtering
• SpamAssassin : filering out spam
• ClamAV : setting up the automated antivirus system
• SquirrelMail : accessing email from the web
• Firewall : proper setup for your firewall
• MboxMaildirMigration : migrating your old mailboxes to the new system
• TroubleShooting : a few tests and tips to help troubleshooting.

I hope you will find these helpfull. Let me know if they helped or if you have any comments: (:email etc@nkadesign.com:) or just leave your comments in the comment boxes at the bottom of each article.

ARTICLE WILL BE COMPLETED BY 12JULY2005

Setting Up a high performance IMAP server

The aim of this article is to describe how to configure a reliable and high performance email server for a 5-100 employees company.

The constraint here is not to send/receive millions of messages a day but to allow users to keep their emails on the server and use IMAP to retrieve them from wherever they are, and for however long they want to keep them.

This type of server is particularly suited for companies whose employees deal with a lot of emails, such as an Engineering, Project Management or a Law firm.

Objectives

The main objectives are:

• enabling users to send any sized email through the server,
• enabling roaming users to send email through the server securely from the Internet,
• enabling users to check their email through a secured web interface, wherever they are,
• allowing up to a few hundred of thousand of email messages to be stored in an IMAP folder without noticeable slow down when operating on messages (deleting, reading, getting headers)

Assumptions

In this document, the FQDN? (Fully Qualified Domain Name) of the server is also its hostname mail.example.com and its domain name is thus example.com.

I assume that you have setup a MX DNS record for mail.example.com and that mail sent to joe@example.com will be attempted to be delivered to the server we're setting up.

Note: if you need to setup your domain name and take control of your email, I suggest that you take an account with ZoneEdit: the first 5 zones are free, and extra services are quite cheap. You have total control over you domains, subdomains, and can of course create Mail eXchange records. They also have a service to buffer your email should your server be offline. when things return to normal, any email they kept will be delivered as usual.

Installation

The initial installation process is not critical here. Simply avoid installing too much stuff that you don't need (like X, Gnome or KDE and anything graphical) and limit the number of services that run on the server. It's easy enough to add missing packages afterwards.

Buy your hard-drives in double or triple and mount your partitions as RAID1 or RAID5 arrays: this is quite critical as it means that you won't lose everything if one of the drives fails. I won't discuss backup solutions for this system, but you should have one. In the future, I plan to describe a mail to database solution that could be used as a specific mail backup/archiving/retrieval system.

When deciding your disk partitions, allow a rather large one that you will mount as /mail and format as ext3.
Make it as large as you can. You could also build an LVM on top of that partition if you believe that you could run out of disk space. With LVM, you can easily increase or decrease your available space by simply adding new partitions to the Volume.

During the installation process, make sure that you choose Postfix in the available packages. Fedora defaults to using sendmail, so we'll have to fix that later.

After you've rebooted, use yum to update your system.

Check partition indexes

By default, Fedora Core 4 uses indexes when creating ext3 partitions, this is good and is required for the partition where the emails will be saved.

Why are indexes so important you ask?
Well, since we're going to use maildirs, each email will be saved as a file. Without indexes, it will take an increasing amount of time for the kernel to locate a file in a busy mailbox. The kernel limit that issue by building fast indexes so it can easily find the file it needs.

It doesn't hurt to double check that our partition supports indexes. Let's suppose that your /mail partition is /dev/hda3:

(:source lang=Bash:) tune2fs -l /dev/hda3 | grep features (:sourcend:) You should see a reference to dir_index.
If not, then you can modify your partition without losing data: (:source lang=Bash:) umount /dev/hda3 tune2fs -O dir_index /dev/hda3 e2fsk -fD /dev/hda3 mount /dev/hda3 (:sourcend:) This bit was taken from the Dovecot site.

Users

There are plenty of different ways to authenticate users for mail access.
By default though, Postfix, Dovecot and saslauthd -the services we use here- use the standard unix user accounts to validate users and find out its home directory.

Using LDAP, virtual users, MySQL databases, NIS, SMB or any other scheme is of course possible but in our case I wanted to keep things simple and allow this server to later become say a file server as well without too much hassle. Changing the authentication scheme can be necessary if you're managing virtual email accounts with lots of different domains (if you're and ISP for instance).
In our case, there was nothing much to gain.

Having said that, there are a few of drawbacks to using standard user accounts:

• by default, these accounts are login accounts, meaning that users can log onto the machine at will. While they are not supposed to have enough credentials to wreak havoc in the system, it's still a potential security risk.
• Whenever you create a new user account, its home directory is filled with local configuration files that we don't need (such as bash profiles, or emacs config files)
• The default user account is created in /home but we want them in /mail instead.

I will assume that all our users will not need to login onto the machine by default. If you need such users, you can still override these settings.

Edit the /etc/default/useradd file: (:source lang=Bash:)

1. useradd defaults file

GROUP=100 HOME=/mail INACTIVE=-1 EXPIRE= SHELL=/bin/nologin SKEL=/etc/skelmail (:sourcend:) Note: the normal way of doing this is to use adduser -D syntax from the command line, but there is no documented option to change the default skeleton directory.

Now create the skeleton directory: (:source lang=:)

1. mkdir -p /etc/skelmail/email/{cur,new,tmp}
2. chmod 700 -R /etc/skelmail/email

(:sourcend:)

Now, whenever we use the useradd command, the user will be added to the system without the ability to login and his mail directory will be automatically created.

Note: It's very important that the email folder is not world-accessible: Postfix will otherwise refuse to write any email in it as it would be a security hazard. That's why we set it to chmod 700.

Should you need to add normal login users accounts, you can override the default settings of adduser on the command line as such: (:source lang=:)

1. adduser -m /etc/skel -s /bin/bash -d /home/susan susan

(:sourcend:)

Will add the normal login user susan to the system.

Switch to Postfix

Now that your system is nice and clean, let's switch from the default sendmail to postfix.
This stuff is pretty specific to RedHat's way of thinking: they wanted to make email management totally transparent so that it didn't really matter which MTA (Mail Transport Agent) you were using.

To switch, do the following: (:source lang=Bash:) yum install postfix yum install system-switch-mail /usr/sbin/system-switch-mail (:sourcend:) The first 2 yum installs may not be necessary if they are already on your system, but it won't hurt if you do it anyway.

You will be presented with a choice on screen, go for Postfix and press OK. After a few seconds, you should get a succinct report that the switch was completed.

Configuring Postfix

Postfix uses a few configuration files. The most important files are master.cf and main.cf and are located in /etc/postfix.

Let's first make a backup copy of these config files, just in case: (:source lang=Bash:) cp master.cf master.cf.ORIGINAL cp main.cf main.cf.ORIGINAL (:sourcend:)

main.cf parameters

Now, edit the main.cf file and update the following definitions. Alternatively, you can use postconf -e "definition" on the command line for each line below if you don't want to edit the file by hand.

(:source lang=Bash:) myorigin = $mydomain (:sourcend:) This says that mail sent from your server will take the form xxx@example.com.

Note that by default, $myhostname and $mydomain are automatically derived from your machine's name. This name should be a Fully Qualified Domain Name (FQDM) like mail.example.com.
If that's not the case, you can change it editing the /etc/sysconfig/network file or you can declare the myhostname = mail.example.com and mydomain = example.com in the main.cf file itself.

(:source lang=Bash:) mydestination = $myhostname localhost.$mydomain localhost $mydomain (:sourcend:) Defines which domains you want to receive mail for. We should always allow the variations of localhost so the server can accept mail sent to itself, and $myhostname and $mydomain ensure that you will get mail sent to both mail.example.com and example.com.

(:source lang=Bash:) mynetworks_style = subnet (:sourcend:) Allows people on the local network to be able to use the server to relay their emails. People from outside the subnet (outside of the IP addresses defined by your network's netmask, such as 255.255.255.0) will not be able to use the server to send email. This is safe, you never want unknown people from the Internet to be able to relay their mail through your server: it would only take a few minutes for your machine to become a spam hub.

(:source lang=Bash:) relay_domains = $mydestination (:sourcend:) Authorises people from the outside to send email that is supposed to be for us.

(:source lang=Bash:) notify_classes = resource, software (:sourcend:) Defines what sort of information should be sent to the postmaster when there is a problem. There are more options to that, but using too many could flood your mailbox.

(:source lang=Bash:) relayhost = (:sourcend:) Confirms we're not using any external relays as we want the server to deliver our emails directly to other servers. If your ISP doesn't let you send emails by yourself (some block port 25), then you can put their own email server there [mail.isp.com] (including the brackets). Any mail you sent through your server will be given to your ISP's email server for delivery. Note that this is not very reliable as ISP have usually no guarantee that your email will be delivered to its destination: you're in effect sending your mail through a black hole.

(:source lang=Bash:) proxy_interfaces = 1.2.3.4 (:sourcend:) Is only needed if your server is not directly connected to the Internet but is for instance behind a firewall that uses Port Forwarding to redirect traffic to it on a local subnet (for instance, your server address is 192.168.0.1 or another reserved LAN IP Class). In that case, you have to tell Postfix what is the outside address of the mail server (replace 1.2.3.4 by whatever is your real IP). Note though that if you don't have a fixed IP, this can be a bit annoying and you may be better off with connecting the server directly to the Internet and using iptables as a good internal firewall.

(:source lang=Bash:) inet_interfaces = all (:sourcend:) Makes Postfix listen to all interfaces for email.

(:source lang=Bash:) message_size_limit = 20971520 (:sourcend:) Limits the size of emails. Here we set it to 20MB which should be more than enough for most systems. It's a good idea to set a limit. I've have users trying to send 150MB emails to people who only had a dial-up connection (since delivery to the server from the local network is fast, people tend not to notice much the size of the emails they send).

(:source lang=Bash:) masquerade_domains = $mydomain (:sourcend:) Ensures that mail from other hosts being sent through the server gets rewritten with our domain name correctly appended. this means that if elise@accounts.example.com sends an email through the server, it will be rewritten as elise@example.com.

(:source lang=Bash:) mail_name = MyOwnPostOffice (:sourcend:) Optional and replaces the default name returned by Postfix. It's not a bad idea to replace the default string as it is par of the messages exchanged every time an email is being delivered. Potentially, it could allow someone to use that information to exploit a known security hole (the default string contains the full version number of Postfix).

(:source lang=Bash:) home_mailbox = email/ (:sourcend:) If that directive is present, it will tell Postfix to deliver messages to the email/ folder inside the user's home, as in /mail/joe/email, instead of the default /var/mail/joe mbox file.
Note that the trailing / means that we want to use maildir instead of mbox. This is how we get to save our received emails in directories and files rather than in one single flat file that becomes cumbersome and fragile if there are too many stored emails in it.

Note: you do not need to create the directories: Postfix will do that for you if they don't exist.

SASL Authentication

As we've discussed before, ensuring that your server is locked down is vital if you don't want to become the next spam relay.
However, we must still ensure that we've got a flexible system that allows all our legitimate users to send email from wherever they are.

SASL is a way of authenticating users when they are trying to send mail. It uses a variety of methods and it's fairly flexible, at the expense of being simple.

To ensure proper SASL authentication, add the following to your main.conf file:

(:source lang=Bash:) smtpd_sasl_auth_enable = yes broken_sasl_auth_clients = yes smtpd_recipient_restrictions =

  permit_mynetworks
  permit_sasl_authenticated
  reject_unauth_destination
  reject_invalid_hostname
  reject_unknown_sender_domain

(:sourcend:) The first line enables authentication for email being sent through the server from the outside (allowing roaming users to send email from the Internet).
the next directive ensures that Postfix will work around older mail clients with broken implementations of SMTP authentication.
Finally, smtpd_recipient_restrictions lists the steps that an email must pass before being accepted. There are a lot of different possibilities. I have used what I think is reasonable for our system.

For security reasons, Postfix runs as an unprivileged user, meaning that it doesn't have access to your password files.
To be able to authenticate users, it must rely on an external service, saslauthd.

Fortunately, this is already installed on Fedora and probably on most distributions as well. Just to be sure, do the following from the prompt: (:source:)

1. yum install cyrus-sasl
2. chkconfig saslauthd --levels 235 on
3. service saslauthd restart

(:sourcend:)

There is nothing else to do: the default configuration takes care of everything.
The only configuration that tells saslautd that is is needed for mail authentication is in the file /usr/lib/sasl2/smtpd.conf which is installed as part of the Postfix package.
This file contains simply one parameter: (:source lang=Bash:) pwcheck_method: saslauthd (:sourcend:)

Note: on other Linux systems, this file may be missing or may be located under /usr/local/lib/sasl2/smtpd.conf instead.

Aliases

The minimum alias that must be set-up is for the postmaster who will receive errors and warnings issued by Postfix:

Edit /etc/aliases and modify the following: (:source lang=Bash:) postmaster: administrator root: administrator (:sourcend:)

The administrator user must have been created and you should probably the one using that account regularly to check for issues.

Note: after every modification of the alias file, you must run postalias /etc/aliases to rebuild the database that Postfix will use. Your changes won't be taken into account if you don't do that!

To add more aliases, just add them to /etc/aliases: (:noteblock:) Email aliases (:notecontent:) I usually use a fair number of variation on employee's names as aliases so most misspelling in an email address still end-up going to the right person. You should of course only give one email address to your user, for instance, your company policy could be that emails should be in the form suzan.smith@example.com. (:noteblockend:) (:source lang=Bash:) suzan.smith: susan s.smith: susan suzansmith: susan ssmith: suzan smith.suzan suzan

accounts: boss marketing: boss sales: boss joe.doe boss joedoe boss (:sourcend:)

Don't forget to run postalias /etc/aliases to rebuild the aliases database for Postfix.

Dovecot for POP3 and IMAP

Dovecot is a good and flexible POP3 and IMAP mail server. It is very performing and can manage large amounts of emails.
Docevot is part of Fedora Core 4 and we don't have to do too much to make it work, although setting encrypted communications takes a bit of work.

If you haven't got it on your system, you can build it from source or just use the ubiquitous yum: (:source lang=:)

1. yum install dovecot
2. chkconfig dovecot --levels 235 on

(:sourcend:)

First, we need to tell Dovecot where to fin our emails: as you remember, we told Postfix to use maildirs in the user directories instead of the default mbox.

Edit the /etc/dovecot.conf file and modify the following lines: (:source:) default_mail_env = maildir:/mail/%u/email client_workarounds = oe6-fetch-no-newmail outlook-idle outlook-pop3-no-nuls mailbox_check_interval = 20 mail_full_filesystem_access = no maildir_copy_with_hardlinks = yes (:sourcend:)

Restart Dovecot (service dovecot restart) and test it right away, trying to get email from your test administrator account through POP3 and IMAP. Note that you must have sent email to that account first so Postfix could create the proper directory structure, otherwise you'll get and error when trying to access the IMAP folder that doesn't exist yet.

SSL for IMAP and POP

TSL for securely sending mail

Amavisd-New

Do the following from the command line (check the latest version number of Amavisd-New and replace it, this is just an example): (:source lang=:) cd /usr/local/src/ wget http://www.ijs.si/software/amavisd/amavisd-new-2.3.2.tar.gz tar xzvf amavisd-new-2.3.2.tar.gz cd amavisd-new-2.3.2 cp amavisd /usr/local/sbin/ cp amavisd.conf /etc/ (:sourcend:)

SpamAssassin

ClamAV Antivirus

SquirrelMail web interface

SquirrelMail is the webmail interface that comes preloaded with Fedora.
If it's not installed, just use yum install squirelmail to get it. You will also of course need Apache and make sure that your firewall has port 80 (http) and 443 (https) open.

Make sure Apache is running service httpd start. SquirrelMail is available out of the box from http://mail.example.com/webmail/.

By default, SquirrelMail is not accessible from https, and since our server will only be for mail, there is not need for appending the /mail at the end of the URL, so we need to fix those shortcomings.

First get the original SquirrelMail Apache config file out of the way: (:source lang=:)

1. cd /etc/httpd/conf.d/
2. mv squirrelmail.conf squirrelmail.OLD

(:sourcend:)

Then edit the /etc/httpd/conf.d/ssl.conf and add the following between the existing <Virtualhost> tags, then append the URL rewrite rules: (:source lang=:) <VirtualHost _default_:443>

  ...
  DocumentRoot "/usr/share/squirrelmail"
  ServerName mail.example.com
  <Directory /usr/share/squirrelmail>
    AllowOverride None
    Options ExecCGI
    Order allow,deny
    Allow from all
  </Directory>
  ...

</Virtualhost>

1. Log the rewrites, just in case we need to debug

RewriteEngine on RewriteLog "/var/log/httpd/rewrite_log" RewriteLogLevel 0

1. Force SSL if the user tried to access from http://mail.example.com

RewriteCond %{HTTPS} off RewriteCond %{HTTP_HOST} ^(.*)$ [NC] RewriteRule (^.*$) https://%1 [L,R] (:sourcend:)

Now restart Apache service httpd restart and you should be able to access your email from anywhere securely through http://mail.example.com/.

Note: https connections require a digital certificate registered with a known authority. The certificate is only valid for one website and one IP address and you need to pay for it. If you don;t have a certificate, your users will receive a warning when trying to access the site. You will have to tell them not to worry about that if you don't want or can't have a certificate (if you're using dynamic IP for instance). The certificate is only necessary to confirms that the site using is really who it pretends to be, it doesn't affect the fact that communications are encrypted.

Configuring the firewall

Appendix 1 - Specific issues encountered

• GrubOfDeath? : a boot loader issue involving the use of many hard-drives and a mismatch in the BIOS and GRUB universes.
• MboxMaildirMigration : migrating users mailboxes from an older system to our new server.

Appendix 2 - Troubleshooting

Checking SASL authentication

(:noteblock:) Testing your Authentication Config (:notecontent:) The script in this section was lifted from the very complete book Postfix: the Definitive Guide from O'Reilly. (:noteblockend:) To ensure that your authentication process works fine, we'll check what the server reports when we try to feed it a correct login.

Since logins are base64 encoded, copy and paste the following in a file that you call encode_sasl_plain.pl (don't forget to chmod 755 to make it executable): (:source lang=Perl:)

1. !/usr/bin/perl

use strict; use MIME::Base64; if ( $#ARGV != 1 ) {

   die "Usage: encode_sasl_plain.pl <username> <password>\n";

} print encode_base64("$ARGV[0]\0$ARGV[0]\0$ARGV[1]"); exit 0; (:sourcend:)

Then use it to encode a username/password pair as it would be expected by the mail server for authentication. Here I use the existing administrator user (the account must exist on the system):

(:source:)

1. encode_sasl_plain.pl administrator 123456

YWRtaW5pc3RyYXRvcgBhZG1pbmlzdHJhdG9yADEyMzQ1Ng== (:sourcend:)

Then, talk to your mail server manually: (:source linenum:)

1. telnet localhost 25

Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. 220 mail.example.com ESMTP MyOwnPostOffice EHLO test.faraway.com 250-mail.example.com 250-PIPELINING 250-SIZE 20971520 250-VRFY 250-ETRN 250-AUTH LOGIN DIGEST-MD5 PLAIN CRAM-MD5 250-AUTH=LOGIN DIGEST-MD5 PLAIN CRAM-MD5 250 8BITMIME AUTH PLAIN YWRtaW5pc3RyYXRvcgBhZG1pbmlzdHJhdG9yADEyMzQ1Ng== 235 Authentication successful quit 221 Bye Connection closed by foreign host. (:sourcend:) The only lines you will need to type are 6, 15, 17. The others are the server's responses.

References

• How to install Postfix, Amavisd-new, SpamAssassin, Pyzor, Razor, DCC, and ClamAV on Fedora Core 4 - v2.1
• Switching To Postfix in Fedora
• Apache config for Squirrelmail

(:comments:)