Server Surat

Tujuan utama SMTP adalah untuk mentransfer email antar server email. Namun, ini juga penting untuk klien email. Untuk mengirim email, klien mengirim pesan ke server email keluar, yang pada gilirannya menghubungi server email tujuan untuk pengiriman. Untuk alasan ini, perlu untuk menentukan server SMTP saat mengonfigurasi klien email.

Di bawah Fedora, pengguna dapat mengonfigurasi server SMTP pada komputer lokal untuk menangani pengiriman email. Namun, dimungkinkan juga untuk mengonfigurasi server SMTP jarak jauh untuk surat keluar.

Satu poin penting yang harus dibuat tentang protokol SMTP adalah bahwa ia tidak memerlukan otentikasi. Ini memungkinkan siapa pun di Internet untuk mengirim email ke orang lain atau bahkan ke sekelompok besar orang. Karakteristik SMTP inilah yang memungkinkan email sampah atau spam. Memberlakukan pembatasan relay membatasi pengguna acak di Internet untuk mengirim email melalui server SMTP Anda, ke server lain di internet. Server yang tidak memberlakukan batasan seperti itu disebut server open relay.

Fedora menyediakan program SMTP Postfix dan Sendmail.

Server POP default di bawah Fedora adalah Dovecot dan disediakan oleh paket dovecot.

Saat menggunakan server POP, pesan email diunduh oleh aplikasi klien email. Secara default, sebagian besar klien email POP secara otomatis dikonfigurasi untuk menghapus pesan di server email setelah berhasil ditransfer, namun pengaturan ini biasanya dapat diubah.

POP sepenuhnya kompatibel dengan standar perpesanan Internet penting, seperti Multipurpose Internet Mail Extensions (MIME), yang memungkinkan lampiran email.

POP bekerja paling baik untuk pengguna yang memiliki satu sistem untuk membaca email. Ini juga berfungsi dengan baik untuk pengguna yang tidak memiliki koneksi persisten ke Internet atau jaringan yang berisi server email. Sayangnya bagi mereka yang memiliki koneksi jaringan lambat, POP memerlukan program klien setelah otentikasi untuk mengunduh seluruh konten dari setiap pesan. Ini bisa memakan waktu lama jika ada pesan yang memiliki lampiran besar.

Versi terbaru dari protokol POP standar adalah POP3.

Namun, ada berbagai varian protokol POP yang jarang digunakan:

Untuk keamanan tambahan, dimungkinkan untuk menggunakan enkripsi Secure Socket Layer (SSL) untuk autentikasi klien dan sesi transfer data. Ini dapat diaktifkan dengan menggunakan layanan pop3s, atau dengan menggunakan aplikasi stunnel. Untuk informasi selengkapnya tentang mengamankan komunikasi email, lihat Mengamankan Komunikasi.

Server IMAP baku di bawah Fedora adalah Dovecot dan disediakan oleh paket dovecot. Lihat POP untuk informasi tentang cara memasang Dovecot.

Saat menggunakan server email IMAP, pesan email tetap berada di server tempat pengguna dapat membaca atau menghapusnya. IMAP juga memungkinkan aplikasi klien untuk membuat, mengganti nama, atau menghapus direktori email di server untuk mengatur dan menyimpan email.

IMAP sangat berguna bagi pengguna yang mengakses email mereka menggunakan beberapa mesin. Protokol ini juga nyaman bagi pengguna yang terhubung ke server email melalui koneksi yang lambat, karena hanya informasi header email yang diunduh untuk pesan hingga dibuka, menghemat bandwidth. Pengguna juga memiliki kemampuan untuk menghapus pesan tanpa melihat atau mengunduhnya.

Untuk kenyamanan, aplikasi klien IMAP mampu menyimpan salinan pesan secara lokal, sehingga pengguna dapat menelusuri pesan yang sudah dibaca sebelumnya saat tidak terhubung langsung ke server IMAP.

IMAP, seperti POP, sepenuhnya kompatibel dengan standar perpesanan Internet penting, seperti MIME, yang memungkinkan lampiran email.

Untuk keamanan tambahan, dimungkinkan untuk menggunakan enkripsi SSL untuk otentikasi klien dan sesi transfer data. Ini dapat diaktifkan dengan menggunakan layanan imaps, atau dengan menggunakan program stunnel. Untuk informasi selengkapnya tentang mengamankan komunikasi email, lihat Mengamankan Komunikasi.

Klien dan server IMAP gratis dan komersial lainnya tersedia, banyak di antaranya memperluas protokol IMAP dan menyediakan fungsionalitas tambahan.

Proses imap-login dan pop3-login yang mengimplementasi protokol IMAP dan POP3 dihasilkan oleh daemon master dovecot yang termasuk dalam paket dovecot. Penggunaan IMAP dan POP dikonfigurasi melalui berkas konfigurasi /etc/dovecot/dovecot.conf; secara baku dovecot menjalankan IMAP dan POP3 bersama dengan versi amannya menggunakan SSL. Untuk mengonfigurasi dovecot agar menggunakan POP, selesaikan langkah-langkah berikut:

Tidak seperti SMTP, IMAP dan POP3 memerlukan koneksi klien untuk mengautentikasi menggunakan nama pengguna dan kata sandi. Secara baku, kata sandi untuk kedua protokol diteruskan melalui jaringan yang tidak terenkripsi.

Untuk mengonfigurasi SSL pada dovecot:

Detail lebih lanjut tentang dovecot dapat ditemukan secara daring di https://www.dovecot.org.

Postfix yang dapat dieksekusi adalah postfix. Daemon ini meluncurkan semua proses terkait yang diperlukan untuk menangani pengiriman surel.

Postfix menyimpan berkas konfigurasinya di direktori /etc/postfix/. Berikut ini adalah daftar berkas yang lebih umum digunakan:

Berkas alias dapat ditemukan di direktori /etc/. Berkas ini dipakai bersama antara Postfix dan Sendmail. Ini adalah daftar yang dapat dikonfigurasi yang diperlukan oleh protokol surel yang menjelaskan alias ID pengguna.

Mulai ulang layanan postfix setelah mengubah opsi apa pun dalam berkas konfigurasi di bawah direktori /etc/postfix agar perubahan tersebut diterapkan. Untuk melakukannya, jalankan perintah berikut sebagai root:

Secara baku, Postfix tidak menerima koneksi jaringan dari host mana pun selain host lokal. Lakukan langkah-langkah berikut sebagai root untuk mengaktifkan pengiriman surel untuk host lain di jaringan:

Once these steps are complete, the host accepts outside emails for delivery.

Postfix has a large assortment of configuration options. One of the best ways to learn how to configure Postfix is to read the comments within the /etc/postfix/main.cf configuration file. Additional resources including information about Postfix configuration, SpamAssassin integration, or detailed descriptions of the /etc/postfix/main.cf parameters are available online at http://www.postfix.org/.

Postfix can use an LDAP directory as a source for various lookup tables (e.g.: aliases, virtual, canonical, etc.). This allows LDAP to store hierarchical user information and Postfix to only be given the result of LDAP queries when needed. By not storing this information locally, administrators can easily maintain it.

The following is a basic example for using LDAP to look up the /etc/aliases file. Make sure your /etc/postfix/main.cf file contains the following:

Create a /etc/postfix/ldap-aliases.cf file if you do not have one already and make sure it contains the following:

where ldap.example.com, example, and com are parameters that need to be replaced with specification of an existing available LDAP server.

For more information on LDAP, see OpenLDAP.

It is important to be aware of what Sendmail is and what it can do, as opposed to what it is not. In these days of monolithic applications that fulfill multiple roles, Sendmail may seem like the only application needed to run an email server within an organization. Technically, this is true, as Sendmail can spool mail to each users' directory and deliver outbound mail for users. However, most users actually require much more than simple email delivery. Users usually want to interact with their email using an MUA, that uses POP or IMAP, to download their messages to their local machine. Or, they may prefer a Web interface to gain access to their mailbox. These other applications can work in conjunction with Sendmail, but they actually exist for different reasons and can operate separately from one another.

It is beyond the scope of this section to go into all that Sendmail should or could be configured to do. With literally hundreds of different options and rule sets, entire volumes have been dedicated to helping explain everything that can be done and how to fix things that go wrong. See the Additional Resources for a list of Sendmail resources.

This section reviews the files installed with Sendmail by default and reviews basic configuration changes, including how to stop unwanted email (spam) and how to extend Sendmail with the Lightweight Directory Access Protocol (LDAP).

In order to use Sendmail, first ensure the sendmail package is installed on your system by running, as root:

In order to configure Sendmail, ensure the sendmail-cf package is installed on your system by running, as root:

Untuk informasi selengkapnya tentang memasang paket dengan DNF, lihat Memasang Paket.

Before using Sendmail, the default MTA has to be switched from Postfix. For more information how to switch the default MTA refer to Mail Transport Agents.

The Sendmail executable is sendmail.

Sendmail’s lengthy and detailed configuration file is /etc/mail/sendmail.cf. Avoid editing the sendmail.cf file directly. To make configuration changes to Sendmail, edit the /etc/mail/sendmail.mc file, back up the original /etc/mail/sendmail.cf file, and use the following alternatives to generate a new configuration file:

More information on configuring Sendmail can be found in Common Sendmail Configuration Changes.

Various Sendmail configuration files are installed in the /etc/mail/ directory including:

Several of the configuration files in the /etc/mail/ directory, such as access, domaintable, mailertable and virtusertable, must actually store their information in database files before Sendmail can use any configuration changes. To include any changes made to these configurations in their database files, run the following commands, as root:

This will update virtusertable.db, access.db, domaintable.db, mailertable.db, sendmail.cf, and submit.cf.

To update all the database files listed above and to update a custom database file, use a command in the following format:

where name represents the name of the custom database file to be updated.

To update a single database, use a command in the following format:

where name.db represents the name of the database file to be updated.

You may also restart the sendmail service for the changes to take effect by running:

Misalnya, agar semua surel yang ditujukan ke domain example.com dikirimkan ke bob@other-example.com, tambahkan baris berikut ke berkas virtusertable:

To finalize the change, the virtusertable.db file must be updated:

Using the all option will result in the virtusertable.db and access.db being updated at the same time.

When altering the Sendmail configuration file, it is best not to edit an existing file, but to generate an entirely new /etc/mail/sendmail.cf file.

To add the desired functionality to Sendmail, edit the /etc/mail/sendmail.mc file as root. Once you are finished, restart the sendmail service and, if the m4 package is installed, the m4 macro processor will automatically generate a new sendmail.cf configuration file:

The default configuration in Fedora works for most SMTP-only sites. However, it does not work for UUCP (UNIX-to-UNIX Copy Protocol) sites. If using UUCP mail transfers, the /etc/mail/sendmail.mc file must be reconfigured and a new /etc/mail/sendmail.cf file must be generated.

Consult the /usr/share/sendmail-cf/README file before editing any files in the directories under the /usr/share/sendmail-cf/ directory, as they can affect the future configuration of the /etc/mail/sendmail.cf file.

One common Sendmail configuration is to have a single machine act as a mail gateway for all machines on the network. For example, a company may want to have a machine called mail.example.com that handles all of their email and assigns a consistent return address to all outgoing mail.

In this situation, the Sendmail server must masquerade the machine names on the company network so that their return address is user@example.com instead of user@host.example.com.

To do this, add the following lines to /etc/mail/sendmail.mc:

After generating a new sendmail.cf file using the m4 macro processor, this configuration makes all mail from inside the network appear as if it were sent from example.com.

Email spam can be defined as unnecessary and unwanted email received by a user who never requested the communication. It is a disruptive, costly, and widespread abuse of Internet communication standards.

Sendmail makes it relatively easy to block new spamming techniques being employed to send junk email. It even blocks many of the more usual spamming methods by default. Main anti-spam features available in sendmail are header checks, relaying denial (default from version 8.9), access database and sender information checks.

For example, forwarding of SMTP messages, also called relaying, has been disabled by default since Sendmail version 8.9. Before this change occurred, Sendmail directed the mail host (x.edu) to accept messages from one party (y.com) and sent them to a different party (z.net). Now, however, Sendmail must be configured to permit any domain to relay mail through the server. To configure relay domains, edit the /etc/mail/relay-domains file and restart Sendmail

However users can also be sent spam from from servers on the Internet. In these instances, Sendmail’s access control features available through the /etc/mail/access file can be used to prevent connections from unwanted hosts. The following example illustrates how this file can be used to both block and specifically allow access to the Sendmail server:

This example shows that any email sent from badspammer.com is blocked with a 550 RFC-821 compliant error code, with a message sent back. Email sent from the tux.badspammer.com sub-domain, is accepted. The last line shows that any email sent from the 10.0.. network can be relayed through the mail server.

Because the /etc/mail/access.db file is a database, use the makemap command to update any changes. Do this using the following command as root:

Message header analysis allows you to reject mail based on header contents. SMTP servers store information about an email’s journey in the message header. As the message travels from one MTA to another, each puts in a Received header above all the other Received headers. It is important to note that this information may be altered by spammers.

The above examples only represent a small part of what Sendmail can do in terms of allowing or blocking access. See the /usr/share/sendmail-cf/README file for more information and examples.

Karena Sendmail memanggil Procmail MDA saat mengirimkan surel, dimungkinkan juga untuk menggunakan program pemfilteran spam, seperti SpamAssassin, untuk mengidentifikasi dan mengajukan spam bagi pengguna. Lihat Filter Spam untuk informasi lebih lanjut tentang menggunakan SpamAssassin.

Using LDAP is a very quick and powerful way to find specific information about a particular user from a much larger group. For example, an LDAP server can be used to look up a particular email address from a common corporate directory by the user’s last name. In this kind of implementation, LDAP is largely separate from Sendmail, with LDAP storing the hierarchical user information and Sendmail only being given the result of LDAP queries in pre-addressed email messages.

Namun, Sendmail mendukung integrasi yang jauh lebih besar dengan LDAP, di mana ia menggunakan LDAP untuk mengganti berkas yang dikelola secara terpisah, seperti /etc/aliases dan /etc/mail/virtusertables, pada server surel berbeda yang bekerja sama untuk mendukung organisasi tingkat menengah hingga perusahaan. Singkatnya, LDAP mengabstraksi tingkat routing surel dari Sendmail dan berkas konfigurasi terpisahnya ke kluster LDAP yang kuat yang dapat dimanfaatkan oleh banyak aplikasi berbeda.

The current version of Sendmail contains support for LDAP. To extend the Sendmail server using LDAP, first get an LDAP server, such as OpenLDAP, running and properly configured. Then edit the /etc/mail/sendmail.mc to include the following:

Next, recreate the /etc/mail/sendmail.cf file by running the m4 macro processor and again restarting Sendmail. See Common Sendmail Configuration Changes for instructions.

For more information on LDAP, see OpenLDAP.

Although it is possible to pass all necessary options on the command line to check for email on a remote server when executing Fetchmail, using a .fetchmailrc file is much easier. Place any desired configuration options in the .fetchmailrc file for those options to be used each time the fetchmail command is issued. It is possible to override these at the time Fetchmail is run by specifying that option on the command line.

Berkas .fetchmailrc pengguna berisi tiga kelas opsi konfigurasi:

Global options appear at the top of the .fetchmailrc file, followed by one or more server options, each of which designate a different email server that Fetchmail should check. User options follow server options for each user account checking that email server. Like server options, multiple user options may be specified for use with a particular server as well as to check multiple email accounts on the same server.

Server options are called into service in the .fetchmailrc file by the use of a special option verb, poll or skip, that precedes any of the server information. The poll action tells Fetchmail to use this server option when it is run, which checks for email using the specified user options. Any server options after a skip action, however, are not checked unless this server’s host name is specified when Fetchmail is invoked. The skip option is useful when testing configurations in the .fetchmailrc file because it only checks skipped servers when specifically invoked, and does not affect any currently working configurations.

The following is an example of a .fetchmailrc file:

In this example, the global options specify that the user is sent email as a last resort (postmaster option) and all email errors are sent to the postmaster instead of the sender (bouncemail option). The set action tells Fetchmail that this line contains a global option. Then, two email servers are specified, one set to check using POP3, the other for trying various protocols to find one that works. Two users are checked using the second server option, but all email found for any user is sent to user1's mail spool. This allows multiple mailboxes to be checked on multiple servers, while appearing in a single MUA inbox. Each user’s specific information begins with the user action.

Fetchmail has numerous global, server, and local options. Many of these options are rarely used or only apply to very specific situations. The fetchmail man page explains each option in detail, but the most common ones are listed in the following three sections.

Each global option should be placed on a single line after a set action.

Server options must be placed on their own line in .fetchmailrc after a poll or skip action.

User options may be placed on their own lines beneath a server option or on the same line as the server option. In either case, the defined options must follow the user option (defined below).

Most Fetchmail options used on the command line when executing the fetchmail command mirror the .fetchmailrc configuration options. In this way, Fetchmail may be used with or without a configuration file. These options are not used on the command line by most users because it is easier to leave them in the .fetchmailrc file.

There may be times when it is desirable to run the fetchmail command with other options for a particular purpose. It is possible to issue command options to temporarily override a .fetchmailrc setting that is causing an error, as any options specified at the command line override configuration file options.

Certain options used after the fetchmail command can supply important information.

These options are occasionally useful for overriding defaults often found in the .fetchmailrc file.

More commands and .fetchmailrc options can be found in the fetchmail man page.

The action used if the recipe matches a particular message determines whether it is considered a delivering or non-delivering recipe. A delivering recipe contains an action that writes the message to a file, sends the message to another program, or forwards the message to another email address. A non-delivering recipe covers any other actions, such as a nesting block. A nesting block is a set of actions, contained in braces { }, that are performed on messages which match the recipe’s conditions. Nesting blocks can be nested inside one another, providing greater control for identifying and performing actions on messages.

When messages match a delivering recipe, Procmail performs the specified action and stops comparing the message against any other recipes. Messages that match non-delivering recipes continue to be compared against other recipes.

Flags are essential to determine how or if a recipe’s conditions are compared to a message. The egrep utility is used internally for matching of the conditions. The following flags are commonly used:

For a detailed list of additional flags, see the procmailrc man page.

Lockfiles are very useful with Procmail to ensure that more than one process does not try to alter a message simultaneously. Specify a local lockfile by placing a colon (:) after any flags on a recipe’s first line. This creates a local lockfile based on the destination file name plus whatever has been set in the LOCKEXT global environment variable.

Alternatively, specify the name of the local lockfile to be used with this recipe after the colon.

Special characters used before Procmail recipe conditions and actions change the way they are interpreted.

The following characters may be used after the asterisk character (*) at the beginning of a recipe’s condition line:

The following characters are used to perform special actions:

If no special character is used at the beginning of the action line, Procmail assumes that the action line is specifying the mailbox in which to write the message.

Procmail is an extremely flexible program, but as a result of this flexibility, composing Procmail recipes from scratch can be difficult for new users.

The best way to develop the skills to build Procmail recipe conditions stems from a strong understanding of regular expressions combined with looking at many examples built by others. A thorough explanation of regular expressions is beyond the scope of this section. The structure of Procmail recipes and useful sample Procmail recipes can be found at various places on the Internet. The proper use and adaptation of regular expressions can be derived by viewing these recipe examples. In addition, introductory information about basic regular expression rules can be found in the grep(1) man page.

The following simple examples demonstrate the basic structure of Procmail recipes and can provide the foundation for more intricate constructions.

A basic recipe may not even contain conditions, as is illustrated in the following example:

The first line specifies that a local lockfile is to be created but does not specify a name, so Procmail uses the destination file name and appends the value specified in the LOCKEXT environment variable. No condition is specified, so every message matches this recipe and is placed in the single spool file called new-mail.spool, located within the directory specified by the MAILDIR environment variable. An MUA can then view messages in this file.

A basic recipe, such as this, can be placed at the end of all rc files to direct messages to a default location.

The following example matched messages from a specific email address and throws them away.

With this example, any messages sent by spammer@domain.com are sent to the /dev/null device, deleting them.

The following recipe grabs email sent from a particular mailing list and places it in a specified folder.

Any messages sent from the tux-lug@domain.com mailing list are placed in the tuxlug mailbox automatically for the MUA. Note that the condition in this example matches the message if it has the mailing list’s email address on the From, Cc, or To lines.

Consult the many Procmail online resources available in Additional Resources for more detailed and powerful recipes.

Because it is called by Sendmail, Postfix, and Fetchmail upon receiving new emails, Procmail can be used as a powerful tool for combating spam.

This is particularly true when Procmail is used in conjunction with SpamAssassin. When used together, these two applications can quickly identify spam emails, and sort or destroy them.

SpamAssassin uses header analysis, text analysis, blacklists, a spam-tracking database, and self-learning Bayesian spam analysis to quickly and accurately identify and tag spam.

The easiest way for a local user to use SpamAssassin is to place the following line near the top of the ~/.procmailrc file:

The /etc/mail/spamassassin/spamassassin-default.rc contains a simple Procmail rule that activates SpamAssassin for all incoming email. If an email is determined to be spam, it is tagged in the header as such and the title is prepended with the following pattern:

The message body of the email is also prepended with a running tally of what elements caused it to be diagnosed as spam.

To file email tagged as spam, a rule similar to the following can be used:

This rule files all email tagged in the header as spam into a mailbox called spam.

Since SpamAssassin is a Perl script, it may be necessary on busy servers to use the binary SpamAssassin daemon (spamd) and the client application (spamc). Configuring SpamAssassin this way, however, requires root access to the host.

To start the spamd daemon, type the following command:

To start the SpamAssassin daemon when the system is booted, run:

Lihat Layanan dan Daemon untuk informasi selengkapnya tentang cara mengonfigurasi layanan di Fedora.

To configure Procmail to use the SpamAssassin client application instead of the Perl script, place the following line near the top of the ~/.procmailrc file. For a system-wide configuration, place it in /etc/procmailrc:

Most Linux MUAs designed to check email on remote servers support SSL encryption. To use SSL when retrieving email, it must be enabled on both the email client and the server.

SSL is easy to enable on the client-side, often done with the click of a button in the MUA’s configuration window or via an option in the MUA’s configuration file. Secure IMAP and POP have known port numbers (993 and 995, respectively) that the MUA uses to authenticate and download messages.

Offering SSL encryption to IMAP and POP users on the email server is a simple matter.

First, create an SSL certificate. This can be done in two ways: by applying to a Certificate Authority (CA) for an SSL certificate or by creating a self-signed certificate.

To create a self-signed SSL certificate for IMAP or POP, change to the /etc/pki/dovecot/ directory, edit the certificate parameters in the /etc/pki/dovecot/dovecot-openssl.cnf configuration file as you prefer, and type the following commands, as root:

Once finished, make sure you have the following configurations in your /etc/dovecot/conf.d/10-ssl.conf file:

Issue the following command to restart the dovecot daemon:

Alternatively, the stunnel command can be used as an encryption wrapper around the standard, non-secure connections to IMAP or POP services.

The stunnel utility uses external OpenSSL libraries included with Fedora to provide strong cryptography and to protect the network connections. It is recommended to apply to a CA to obtain an SSL certificate, but it is also possible to create a self-signed certificate.

To create a self-signed SSL certificate, change to the /etc/pki/tls/certs/ directory, and type the following command:

Answer all of the questions to complete the process.

Once the certificate is generated, create an stunnel configuration file, for example /etc/stunnel/mail.conf, with the following content:

Once you start stunnel with the created configuration file using the stunnel /etc/stunnel/mail.conf command, it will be possible to use an IMAP or a POP email client and connect to the email server using SSL encryption.

For more information on stunnel, see the stunnel(8) man page or the documents in the /usr/share/doc/stunnel/ directory.