Server Surat
Fedora menawarkan banyak aplikasi canggih untuk melayani dan mengakses email. Bab ini menjelaskan protokol email modern yang digunakan saat ini, dan beberapa program yang dirancang untuk mengirim dan menerima email.
Protokol Surel
Hari ini, email dikirim menggunakan arsitektur klien/server. Pesan email dibuat menggunakan program klien email. Program ini kemudian mengirim pesan ke server. Server kemudian meneruskan pesan ke server email penerima, di mana pesan kemudian diberikan ke klien email penerima.
Untuk mengaktifkan proses ini, berbagai protokol jaringan standar memungkinkan mesin yang berbeda, sering menjalankan sistem operasi yang berbeda dan menggunakan program email yang berbeda, untuk mengirim dan menerima email.
Protokol berikut yang dibahas adalah yang paling umum digunakan dalam transfer email.
Protokol Transportasi Surat
Pengiriman email dari aplikasi klien ke server, dan dari server asal ke server tujuan, ditangani oleh Simple Mail Transfer Protocol (SMTP).
SMTP
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.
Protokol Akses Surat
Ada dua protokol utama yang digunakan oleh aplikasi klien email untuk mengambil email dari server email: Post Office Protocol (POP) dan Internet Message Access Protocol (IMAP).
POP
Server POP default di bawah Fedora adalah Dovecot dan disediakan oleh paket dovecot.
Memasang paket dovecot
Untuk menggunakan Dovecot, pertama-tama pastikan paket dovecot dipasang pada sistem Anda dengan menjalankan, sebagai ~]# dnf install dovecot Untuk informasi selengkapnya tentang memasang paket dengan DNF, lihat Memasang Paket. |
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:
-
APOP —
POP3
dengan autentikasiMD5
. Hash yang dikodekan dari kata sandi pengguna dikirim dari klien email ke server daripada mengirim kata sandi yang tidak terenkripsi. -
KPOP —
POP3
dengan autentikasi Kerberos. -
RPOP —
POP3
dengan autentikasiRPOP
. Ini menggunakan ID per pengguna, mirip dengan kata sandi, untuk mengautentikasi permintaan POP. Namun, ID ini tidak dienkripsi, jadiRPOP
tidak lebih aman daripadaPOP
standar.
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.
IMAP
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.
Dovecot
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:
-
Edit berkas konfigurasi
/etc/dovecot/dovecot.conf
untuk memastikan variabelprotocols
tidak dikomentari (hapus tanda hash (#
) di awal baris) dan berisi argumenpop3
. Misalnya:protocols = imap pop3 lmtp
Ketika variabel
protocols
dibiarkan dikomentari, dovecot akan menggunakan nilai baku seperti dijelaskan di atas. -
Buat perubahan operasional untuk sesi saat ini dengan menjalankan perintah berikut sebagai
root
:~]# systemctl restart dovecot
-
Buat perubahan operasional setelah reboot berikutnya dengan menjalankan perintah:
~]# systemctl enable dovecot ln -s '/usr/lib/systemd/system/dovecot' '/etc/systemd/system/multi-user.target.wants/dovecot'
Layanan dovecot memulai server POP3Harap dicatat bahwa dovecot hanya melaporkan bahwa ia memulai server
IMAP
, tetapi juga memulai serverPOP3
.
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:
-
Edit berkas konfigurasi
/etc/pki/dovecot/dovecot-openssl.cnf
sesuai keinginan Anda. Namun, dalam instalasi tipikal, berkas ini tidak memerlukan modifikasi. -
Ganti nama, pindahkan, atau hapus berkas
/etc/pki/dovecot/certs/dovecot.pem
dan/etc/pki/dovecot/private/dovecot.pem
. -
Execute the
/usr/libexec/dovecot/mkcert.sh
script which creates the dovecot self signed certificates. These certificates are copied in the/etc/pki/dovecot/certs
and/etc/pki/dovecot/private
directories. To implement the changes, restart dovecot by issuing the following command asroot
:~]# systemctl restart dovecot
Detail lebih lanjut tentang dovecot dapat ditemukan secara daring di https://www.dovecot.org.
Klasifikasi Program Surel
Secara umum, semua aplikasi surel termasuk dalam setidaknya satu dari tiga klasifikasi. Setiap klasifikasi memainkan peran tertentu dalam proses memindahkan dan mengelola pesan surel. Meskipun sebagian besar pengguna hanya mengetahui program surel tertentu yang mereka gunakan untuk menerima dan mengirim pesan, masing-masing penting untuk memastikan bahwa surel tiba di tujuan yang benar.
Mail Transport Agent
Suatu Mail Transport Agent (MTA) membawa pesan surel antar host menggunakan SMTP
. Sebuah pesan mungkin melibatkan beberapa MTA saat bergerak ke tujuan yang diarah.
Sementara pengiriman pesan antar mesin mungkin tampak agak mudah, seluruh proses pembuatan keputusan apakah MTA tertentu dapat atau harus menerima pesan untuk pengiriman itu cukup rumit. Selain itu, karena masalah dari spam, penggunaan MTA tertentu biasanya dibatasi oleh konfigurasi MTA atau konfigurasi akses untuk jaringan tempat MTA berada.
Banyak program klien surel modern dapat bertindak sebagai MTA saat mengirim surel. Namun, tindakan ini tidak boleh disamakan dengan peran MTA sejati. Satu-satunya alasan program klien surel mampu mengirim surel seperti MTA adalah karena host yang menjalankan aplikasi tidak memiliki MTA sendiri. Hal ini terutama berlaku untuk program klien surel pada sistem operasi berbasis non-UNIX. Namun, program klien ini hanya mengirim pesan keluar ke MTA yang berwenang untuk mereka gunakan dan tidak langsung mengirimkan pesan ke server surel penerima yang dituju.
Karena Fedora menawarkan dua MTA, Postfix dan Sendmail, program klien surel sering kali tidak diperlukan untuk bertindak sebagai MTA. Fedora juga menyertakan MTA tujuan khusus yang disebut Fetchmail.
Untuk informasi lebih lanjut tentang Postfix, Sendmail, dan Fetchmail, lihat Mail Transport Agents.
Mail Delivery Agent
Suatu Mail Delivery Agent (MDA) dipanggil oleh MTA untuk menempatkan surel masuk di kotak surat pengguna yang tepat. Dalam banyak kasus, MDA sebenarnya adalah Local Delivery Agent (LDA), seperti mail atau Procmail.
Program apa pun yang benar-benar menangani pesan untuk dikirim ke titik di mana ia dapat dibaca oleh aplikasi klien surel dapat dianggap sebagai MDA. Untuk alasan ini, beberapa MTA (seperti Sendmail dan Postfix) dapat mengisi peran MDA ketika mereka menambahkan pesan surel baru ke berkas spool surel pengguna lokal. Secara umum, MDA tidak mengangkut pesan antar sistem dan juga tidak menyediakan antarmuka pengguna; MDA mendistribusikan dan mengurutkan pesan pada komputer lokal untuk diakses oleh aplikasi klien surel.
Mail User Agent
Suatu Mail User Agent (MUA) identik dengan aplikasi klien surel. MUA adalah program yang, setidaknya, memungkinkan pengguna untuk membaca dan menulis pesan surel. Banyak MUA yang mampu mengambil pesan melalui protokol POP
atau IMAP
, menyiapkan kotak surat untuk menyimpan pesan, dan mengirim pesan keluar ke MTA.
MUA mungkin grafis, seperti Evolution, atau memiliki antarmuka berbasis teks sederhana, seperti Mutt.
Mail Transport Agent
Fedora menawarkan dua MTA utama: Postfix dan Sendmail. Postfix dikonfigurasi sebagai MTA baku dan Sendmail dianggap usang. Jika diperlukan untuk mengalihkan MTA baku ke Sendmail, Anda dapat menghapus Postfix atau menggunakan perintah berikut sebagai root
untuk beralih ke Sendmail:
~]# alternatives --config mta
Anda juga dapat menggunakan perintah berikut untuk mengaktifkan layanan yang diinginkan:
~]# systemctl enable service
Demikian pula, untuk menonaktifkan layanan, ketik berikut ini pada prompt shell:
~]# systemctl disable service
Untuk informasi selengkapnya tentang cara mengelola layanan sistem di Fedora 30, lihat Layanan dan Daemon.
Postfix
Awalnya dikembangkan di IBM oleh pakar keamanan dan programmer Wietse Venema, Postfix adalah MTA yang kompatibel dengan Sendmail yang dirancang agar aman, cepat, dan mudah dikonfigurasi.
Untuk meningkatkan keamanan, Postfix menggunakan desain modular, di mana proses kecil dengan hak istimewa terbatas diluncurkan oleh daemon master. Proses yang lebih kecil dan kurang istimewa melakukan tugas yang sangat spesifik terkait dengan berbagai tahap pengiriman surat dan berjalan di lingkungan root yang berubah untuk membatasi efek serangan.
Mengonfigurasi Postfix untuk menerima koneksi jaringan dari host selain komputer lokal hanya membutuhkan beberapa perubahan kecil dalam berkas konfigurasinya. Namun bagi mereka yang memiliki kebutuhan yang lebih kompleks, Postfix menyediakan berbagai opsi konfigurasi, serta add-on pihak ketiga yang menjadikannya MTA yang sangat serbaguna dan berfitur lengkap.
Berkas konfigurasi untuk Postfix dapat dibaca manusia dan mendukung lebih dari 250 direktif. Tidak seperti Sendmail, tidak ada pemrosesan makro yang diperlukan agar perubahan diterapkan dan sebagian besar opsi yang paling umum digunakan dijelaskan dalam berkas yang banyak dikomentari.
Instalasi Postfix Baku
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:
-
access
— Digunakan untuk kontrol akses, berkas ini menentukan host mana yang diizinkan untuk terhubung ke Postfix. -
main.cf
— Berkas konfigurasi Postfix global. Sebagian besar opsi konfigurasi ditentukan dalam berkas ini. -
master.cf
— Menentukan bagaimana Postfix berinteraksi dengan berbagai proses untuk menyelesaikan pengiriman surel. -
transport
— Memetakan alamat surel ke host relay.
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.
Mengonfigurasi Postfix sebagai server untuk klien lain
Berkas baku |
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
:
~]# systemctl restart postfix
Konfigurasi Postfix Dasar
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:
-
Edit berkas
/etc/postfix/main.cf
dengan editor teks, seperti vi. -
Hapus komentar pada baris
mydomain
dengan menghapus tanda pagar (#
), dan ganti domain.tld dengan domain yang dilayani server surel, sepertiexample.com
. -
Hapus komentar pada baris
myorigin = $mydomain
. -
Hapus komentar pada baris
myhostname
, dan ganti host.domain.tld dengan nama host untuk komputer. -
Hapus komentar pada baris
mydestination = $myhostname, localhost.$mydomain
. -
Uncomment the
mynetworks
line, and replace 168.100.189.0/28 with a valid network setting for hosts that can connect to the server. -
Uncomment the
inet_interfaces = all
line. -
Comment the
inet_interfaces = localhost
line. -
Restart the
postfix
service.
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/.
Menggunakan Postfix dengan LDAP
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:
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
Create a /etc/postfix/ldap-aliases.cf
file if you do not have one already and make sure it contains the following:
server_host = ldap.example.com search_base = dc=example, dc=com
where ldap.example.com
, example
, and com
are parameters that need to be replaced with specification of an existing available LDAP
server.
Berkas /etc/postfix/ldap-aliases.cf
The |
For more information on LDAP
, see OpenLDAP.
Sendmail
Tujuan inti Sendmail, seperti MTA lainnya, adalah untuk mentransfer surel dengan aman di antara host, biasanya menggunakan protokol SMTP
. Perhatikan bahwa Sendmail dianggap tidak digunakan lagi dan pengguna didorong untuk menggunakan Postfix jika memungkinkan. Lihat Postfix untuk informasi lebih lanjut.
Purpose and Limitations
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).
Instalasi Sendmail Baku
In order to use Sendmail, first ensure the sendmail package is installed on your system by running, as root
:
~]# dnf install sendmail
In order to configure Sendmail, ensure the sendmail-cf package is installed on your system by running, as root
:
~]# dnf install sendmail-cf
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:
-
Gunakan makefile yang disertakan dalam
/etc/mail/
untuk membuat berkas konfigurasi/etc/mail/sendmail.cf
baru:~]# make all -C /etc/mail/
All other generated files in
/etc/mail
(db files) will be regenerated if needed. The old makemap commands are still usable. The make command is automatically used whenever you start or restart thesendmail
service.
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:
-
access
— Menentukan sistem mana yang dapat menggunakan Sendmail untuk surel keluar. -
domaintable
— Specifies domain name mapping. -
local-host-names
— Specifies aliases for the host. -
mailertable
— Specifies instructions that override routing for particular domains. -
virtusertable
— Specifies a domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine.
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
:
~]# cd /etc/mail/ ~]# make all
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:
make name.db all
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:
make name.db
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:
~]# systemctl restart sendmail
Misalnya, agar semua surel yang ditujukan ke domain example.com
dikirimkan ke bob@other-example.com
, tambahkan baris berikut ke berkas virtusertable
:
@example.com bob@other-example.com
To finalize the change, the virtusertable.db
file must be updated:
~]# make virtusertable.db all
Using the all
option will result in the virtusertable.db
and access.db
being updated at the same time.
Common Sendmail Configuration Changes
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.
Backup the sendmail.cf file before changing its content
Before replacing or making any changes to the |
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:
~]# systemctl restart sendmail
Configuring Sendmail as a server for other clients
The default ~]# systemctl restart sendmail |
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.
Masquerading
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
:
FEATURE(always_add_domain)dnl FEATURE(`masquerade_entire_domain')dnl FEATURE(`masquerade_envelope')dnl FEATURE(`allmasquerade')dnl MASQUERADE_AS(`example.com.')dnl MASQUERADE_DOMAIN(`example.com.')dnl MASQUERADE_AS(example.com)dnl
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
.
Menghentikan Spam
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
~]# systemctl 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:
badspammer.com ERROR:550 "Go away and do not spam us anymore" tux.badspammer.com OK 10.0 RELAY
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
:
~]# makemap hash /etc/mail/access < /etc/mail/access
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.
Menggunakan Sendmail dengan LDAP
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:
LDAPROUTE_DOMAIN('yourdomain.com')dnl FEATURE('ldap_routing')dnl
Konfigurasi tingkat lanjut
This is only for a very basic configuration of Sendmail with Consult |
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.
Fetchmail
Fetchmail is an MTA which retrieves email from remote servers and delivers it to the local MTA. Many users appreciate the ability to separate the process of downloading their messages located on a remote server from the process of reading and organizing their email in an MUA. Designed with the needs of dial-up users in mind, Fetchmail connects and quickly downloads all of the email messages to the mail spool file using any number of protocols, including POP3
and IMAP
. It can even forward email messages to an SMTP
server, if necessary.
Installing the fetchmail package
In order to use Fetchmail, first ensure the fetchmail package is installed on your system by running, as ~]# dnf install fetchmail Untuk informasi selengkapnya tentang memasang paket dengan DNF, lihat Memasang Paket. |
Fetchmail is configured for each user through the use of a .fetchmailrc
file in the user’s home directory. If it does not already exist, create the .fetchmailrc
file in your home directory
Using preferences in the .fetchmailrc
file, Fetchmail checks for email on a remote server and downloads it. It then delivers it to port 25 on the local machine, using the local MTA to place the email in the correct user’s spool file. If Procmail is available, it is launched to filter the email and place it in a mailbox so that it can be read by an MUA.
Opsi Konfigurasi Fetchmail
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 — Gives Fetchmail instructions that control the operation of the program or provide settings for every connection that checks for email.
-
server options — Specifies necessary information about the server being polled, such as the host name, as well as preferences for specific email servers, such as the port to check or number of seconds to wait before timing out. These options affect every user using that server.
-
user options — Contains information, such as user name and password, necessary to authenticate and check for email using a specified email server.
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:
set postmaster "user1" set bouncemail poll pop.domain.com proto pop3 user 'user1' there with password 'secret' is user1 here poll mail.domain2.com user 'user5' there with password 'secret2' is user1 here user 'user7' there with password 'secret3' is user1 here
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.
Omitting the password from the configuration
Pengguna tidak diharuskan untuk menempatkan kata sandi mereka di berkas |
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.
Opsi Global
Each global option should be placed on a single line after a set action.
-
daemon seconds — Specifies daemon-mode, where Fetchmail stays in the background. Replace seconds with the number of seconds Fetchmail is to wait before polling the server.
-
postmaster — Specifies a local user to send mail to in case of delivery problems.
-
syslog — Specifies the log file for errors and status messages. By default, this is
/var/log/maillog
.
Opsi Server
Server options must be placed on their own line in .fetchmailrc
after a poll or skip action.
-
auth auth-type — Replace auth-type with the type of authentication to be used. By default, password authentication is used, but some protocols support other types of authentication, including kerberos_v5, kerberos_v4, and ssh. If the any authentication type is used, Fetchmail first tries methods that do not require a password, then methods that mask the password, and finally attempts to send the password unencrypted to authenticate to the server.
-
interval number — Polls the specified server every number of times that it checks for email on all configured servers. This option is generally used for email servers where the user rarely receives messages.
-
port port-number — Replace port-number with the port number. This value overrides the default port number for the specified protocol.
-
proto protocol — Replace protocol with the protocol, such as pop3 or imap, to use when checking for messages on the server.
-
timeout seconds — Replace seconds with the number of seconds of server inactivity after which Fetchmail gives up on a connection attempt. If this value is not set, a default of 300 seconds is used.
Opsi Pengguna
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).
-
fetchall — Orders Fetchmail to download all messages in the queue, including messages that have already been viewed. By default, Fetchmail only pulls down new messages.
-
fetchlimit number — Replace number with the number of messages to be retrieved before stopping.
-
flush — Deletes all previously viewed messages in the queue before retrieving new messages.
-
limit max-number-bytes — Replace max-number-bytes with the maximum size in bytes that messages are allowed to be when retrieved by Fetchmail. This option is useful with slow network links, when a large message takes too long to download.
-
password 'password' — Ganti password dengan kata sandi pengguna.
-
preconnect "command" — Replace command with a command to be executed before retrieving messages for the user.
-
postconnect "command" — Replace command with a command to be executed after retrieving messages for the user.
-
ssl — Mengaktifkan enkripsi SSL.
-
user "username" — Replace username with the username used by Fetchmail to retrieve messages. This option must precede all other user options.
Opsi Perintah Fetchmail
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.
Informational or Debugging Options
Certain options used after the fetchmail command can supply important information.
-
--configdump — Displays every possible option based on information from
.fetchmailrc
and Fetchmail defaults. No email is retrieved for any users when using this option. -
-s — Executes Fetchmail in silent mode, preventing any messages, other than errors, from appearing after the fetchmail command.
-
-v — Executes Fetchmail in verbose mode, displaying every communication between Fetchmail and remote email servers.
-
-V — Displays detailed version information, lists its global options, and shows settings to be used with each user, including the email protocol and authentication method. No email is retrieved for any users when using this option.
Opsi Khusus
These options are occasionally useful for overriding defaults often found in the .fetchmailrc
file.
-
-a — Fetchmail downloads all messages from the remote email server, whether new or previously viewed. By default, Fetchmail only downloads new messages.
-
-k — Fetchmail leaves the messages on the remote email server after downloading them. This option overrides the default behavior of deleting messages after downloading them.
-
-l max-number-bytes — Fetchmail does not download any messages over a particular size and leaves them on the remote email server.
-
--quit — Quits the Fetchmail daemon process.
More commands and .fetchmailrc
options can be found in the fetchmail man page.
Mail Transport Agent (MTA) Configuration
A Mail Transport Agent (MTA) is essential for sending email. A Mail User Agent (MUA) such as Evolution, Thunderbird, and Mutt, is used to read and compose email. When a user sends an email from an MUA, the message is handed off to the MTA, which sends the message through a series of MTAs until it reaches its destination.
Even if a user does not plan to send email from the system, some automated tasks or system programs might use the mail command to send email containing log messages to the root
user of the local system. Fedora 30 provides two MTAs: Postfix and Sendmail. If both are installed, Postfix is the default MTA. Note that Sendmail is considered deprecated in MAJOROS;.
Mail Delivery Agent
Fedora includes two primary MDAs, Procmail and mail. Both of the applications are considered LDAs and both move email from the MTA’s spool file into the user’s mailbox. However, Procmail provides a robust filtering system.
This section details only Procmail. For information on the mail command, consult its man page (man mail). Procmail delivers and filters email as it is placed in the mail spool file of the localhost. It is powerful, gentle on system resources, and widely used. Procmail can play a critical role in delivering email to be read by email client applications.
Procmail can be invoked in several different ways. Whenever an MTA places an email into the mail spool file, Procmail is launched. Procmail then filters and files the email for the MUA and quits. Alternatively, the MUA can be configured to execute Procmail any time a message is received so that messages are moved into their correct mailboxes. By default, the presence of /etc/procmailrc
or of a ~/.procmailrc
file (also called an rc file) in the user’s home directory invokes Procmail whenever an MTA receives a new message.
By default, no system-wide rc
files exist in the /etc/
directory and no .procmailrc
files exist in any user’s home directory. Therefore, to use Procmail, each user must construct a .procmailrc
file with specific environment variables and rules.
Whether Procmail acts upon an email message depends upon whether the message matches a specified set of conditions or recipes in the rc
file. If a message matches a recipe, then the email is placed in a specified file, is deleted, or is otherwise processed.
When Procmail starts, it reads the email message and separates the body from the header information. Next, Procmail looks for a /etc/procmailrc
file and rc
files in the /etc/procmailrcs
directory for default, system-wide, Procmail environmental variables and recipes. Procmail then searches for a .procmailrc
file in the user’s home directory. Many users also create additional rc
files for Procmail that are referred to within the .procmailrc
file in their home directory.
Konfigurasi Procmail
The Procmail configuration file contains important environmental variables. These variables specify things such as which messages to sort and what to do with the messages that do not match any recipes.
These environmental variables usually appear at the beginning of the ~/.procmailrc
file in the following format:
env-variable="value"
In this example, env-variable is the name of the variable and value defines the variable.
There are many environment variables not used by most Procmail users and many of the more important environment variables are already defined by a default value. Most of the time, the following variables are used:
-
DEFAULT — Sets the default mailbox where messages that do not match any recipes are placed.
The default DEFAULT value is the same as $ORGMAIL.
-
INCLUDERC — Specifies additional
rc
files containing more recipes for messages to be checked against. This breaks up the Procmail recipe lists into individual files that fulfill different roles, such as blocking spam and managing email lists, that can then be turned off or on by using comment characters in the user’s~/.procmailrc
file.Misalnya, baris dalam baris
~/.procmailrc
pengguna mungkin terlihat seperti ini:MAILDIR=$HOME/Msgs INCLUDERC=$MAILDIR/lists.rc INCLUDERC=$MAILDIR/spam.rc
To turn off Procmail filtering of email lists but leaving spam control in place, comment out the first INCLUDERC line with a hash sign (
#
). Note that it uses paths relative to the current directory. -
LOCKSLEEP — Sets the amount of time, in seconds, between attempts by Procmail to use a particular lockfile. The default is 8 seconds.
-
LOCKTIMEOUT — Sets the amount of time, in seconds, that must pass after a lockfile was last modified before Procmail assumes that the lockfile is old and can be deleted. The default is 1024 seconds.
-
LOGFILE — The file to which any Procmail information or error messages are written.
-
MAILDIR — Sets the current working directory for Procmail. If set, all other Procmail paths are relative to this directory.
-
ORGMAIL — Specifies the original mailbox, or another place to put the messages if they cannot be placed in the default or recipe-required location.
By default, a value of /var/spool/mail/$LOGNAME is used.
-
SUSPEND — Sets the amount of time, in seconds, that Procmail pauses if a necessary resource, such as swap space, is not available.
-
SWITCHRC — Allows a user to specify an external file containing additional Procmail recipes, much like the INCLUDERC option, except that recipe checking is actually stopped on the referring configuration file and only the recipes on the SWITCHRC-specified file are used.
-
VERBOSE — Causes Procmail to log more information. This option is useful for debugging.
Other important environmental variables are pulled from the shell, such as LOGNAME, the login name; HOME, the location of the home directory; and SHELL, the default shell.
A comprehensive explanation of all environments variables, and their default values, is available in the procmailrc
man page.
Resep Procmail
New users often find the construction of recipes the most difficult part of learning to use Procmail. This difficulty is often attributed to recipes matching messages by using regular expressions which are used to specify qualifications for string matching. However, regular expressions are not very difficult to construct and even less difficult to understand when read. Additionally, the consistency of the way Procmail recipes are written, regardless of regular expressions, makes it easy to learn by example. To see example Procmail recipes, see Recipe Examples.
Procmail recipes take the following form:
:0 flags : lockfile-name * condition_1_special-condition-character condition_1_regular_expression * condition_2_special-condition-character condition-2_regular_expression * condition_N_special-condition-character condition-N_regular_expression special-action-character action-to-perform
The first two characters in a Procmail recipe are a colon and a zero. Various flags can be placed after the zero to control how Procmail processes the recipe. A colon after the flags section specifies that a lockfile is created for this message. If a lockfile is created, the name can be specified by replacing lockfile-name.
A recipe can contain several conditions to match against the message. If it has no conditions, every message matches the recipe. Regular expressions are placed in some conditions to facilitate message matching. If multiple conditions are used, they must all match for the action to be performed. Conditions are checked based on the flags set in the recipe’s first line. Optional special characters placed after the asterisk character (*) can further control the condition.
Argumen action-to-perform menentukan tindakan yang diambil ketika pesan cocok dengan salah satu kondisi. Hanya ada satu tindakan per resep. Dalam banyak kasus, nama kotak surat digunakan di sini untuk mengarahkan pesan yang cocok ke dalam berkas itu, menyortir surel secara efektif. Karakter tindakan khusus juga dapat digunakan sebelum tindakan ditentukan. Lihat Kondisi dan Tindakan Khusus untuk informasi lebih lanjut.
Delivering vs. Non-Delivering Recipes
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
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:
-
A — Specifies that this recipe is only used if the previous recipe without an A or a flag also matched this message.
-
a — Specifies that this recipe is only used if the previous recipe with an A or a flag also matched this message and was successfully completed.
-
B — Mengurai isi pesan dan mencari kondisi yang cocok.
-
b — Menggunakan isi dalam tindakan apa pun yang dihasilkan, seperti menulis pesan ke berkas atau meneruskannya. Ini adalah perilaku baku.
-
c — Generates a carbon copy of the email. This is useful with delivering recipes, since the required action can be performed on the message and a copy of the message can continue being processed in the
rc
files. -
D — Makes the egrep comparison case-sensitive. By default, the comparison process is not case-sensitive.
-
E — While similar to the A flag, the conditions in the recipe are only compared to the message if the immediately preceding recipe without an E flag did not match. This is comparable to an
else
action. -
e — Resep dibandingkan dengan pesan hanya jika tindakan yang ditentukan dalam resep sebelumnya gagal.
-
f — Menggunakan pipa sebagai filter.
-
H — Mengurai header pesan dan mencari kondisi yang cocok. Ini adalah perilaku baku.
-
h — Menggunakan header dalam tindakan yang dihasilkan. Ini adalah perilaku baku.
-
w — Tells Procmail to wait for the specified filter or program to finish, and reports whether or not it was successful before considering the message filtered.
-
W — Is identical to w except that "Program failure" messages are suppressed.
For a detailed list of additional flags, see the procmailrc
man page.
Specifying a Local Lockfile
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 Conditions and Actions
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:
-
! — Di baris kondisi, karakter ini membalikkan kondisi, menyebabkan kecocokan terjadi hanya jika kondisinya tidak cocok dengan pesan.
-
< — Memeriksa apakah pesan berada di bawah jumlah byte tertentu.
-
> — Memeriksa apakah pesan melebihi jumlah byte tertentu.
The following characters are used to perform special actions:
-
! — In the action line, this character tells Procmail to forward the message to the specified email addresses.
-
$ — Refers to a variable set earlier in the
rc
file. This is often used to set a common mailbox that is referred to by various recipes. -
| — Starts a specified program to process the message.
-
{ and } — Constructs a nesting block, used to contain additional recipes to apply to matching messages.
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.
Contoh Resep
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:
:0: new-mail.spool
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.
:0 * ^From: spammer@domain.com /dev/null
With this example, any messages sent by spammer@domain.com
are sent to the /dev/null
device, deleting them.
Mengirim pesan ke /dev/null
Be certain that rules are working as intended before sending messages to A better solution is to point the recipe’s action to a special mailbox, which can be checked from time to time to look for false positives. Once satisfied that no messages are accidentally being matched, delete the mailbox and direct the action to send the messages to |
The following recipe grabs email sent from a particular mailing list and places it in a specified folder.
:0: * ^(From|Cc|To).*tux-lug tuxlug
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.
Filter Spam
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.
Installing the spamassassin package
In order to use SpamAssassin, first ensure the spamassassin package is installed on your system by running, as ~]# dnf install spamassassin Untuk informasi selengkapnya tentang memasang paket dengan DNF, lihat Memasang Paket. |
The easiest way for a local user to use SpamAssassin is to place the following line near the top of the ~/.procmailrc
file:
INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc
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:
*****SPAM*****
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:
:0 Hw * ^X-Spam-Status: Yes spam
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:
~]# systemctl start spamassassin.service
To start the SpamAssassin daemon when the system is booted, run:
systemctl enable spamassassin.service
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
:
INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc
Mail User Agent
Fedora offers a variety of email programs, both, graphical email client programs, such as Evolution, and text-based email programs such as mutt.
The remainder of this section focuses on securing communication between a client and a server.
Mengamankan Komunikasi
Popular MUAs included with Fedora, such as Evolution and Mutt offer SSL-encrypted email sessions. Like any other service that flows over a network unencrypted, important email information, such as user names, passwords, and entire messages, may be intercepted and viewed by users on the network. Additionally, since the standard POP
and IMAP
protocols pass authentication information unencrypted, it is possible for an attacker to gain access to user accounts by collecting user names and passwords as they are passed over the network.
Secure Email Clients
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.
Securing Email Client Communications
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.
Avoid using self-signed certificates
Self-signed certificates should be used for testing purposes only. Any server used in a production environment should use an SSL certificate signed by a CA. |
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
:
dovecot]# rm -f certs/dovecot.pem private/dovecot.pem dovecot]# /usr/libexec/dovecot/mkcert.sh
Once finished, make sure you have the following configurations in your /etc/dovecot/conf.d/10-ssl.conf
file:
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem ssl_key = </etc/pki/dovecot/private/dovecot.pem
Issue the following command to restart the dovecot daemon:
~]# systemctl restart dovecot
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.
Memasang paket stunnel
In order to use stunnel, first ensure the stunnel package is installed on your system by running, as ~]# dnf install stunnel Untuk informasi selengkapnya tentang memasang paket dengan DNF, lihat Memasang Paket. |
To create a self-signed SSL certificate, change to the /etc/pki/tls/certs/
directory, and type the following command:
certs]# make stunnel.pem
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:
cert = /etc/pki/tls/certs/stunnel.pem [pop3s] accept = 995 connect = 110 [imaps] accept = 993 connect = 143
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.
Sumber Daya Tambahan
The following is a list of additional documentation about email applications.
Dokumentasi Terpasang
-
Information on configuring Sendmail is included with the sendmail and sendmail-cf packages.
-
/usr/share/sendmail-cf/README
— Contains information on the m4 macro processor, file locations for Sendmail, supported mailers, how to access enhanced features, and more.In addition, the
sendmail
andaliases
man pages contain helpful information covering various Sendmail options and the proper configuration of the Sendmail/etc/mail/aliases
file.
-
-
/usr/share/doc/postfix/
— Contains a large amount of information on how to configure Postfix. -
/usr/share/doc/fetchmail/
— Contains a full list of Fetchmail features in theFEATURES
file and an introductoryFAQ
document. -
/usr/share/doc/procmail/
— Contains aREADME
file that provides an overview of Procmail, aFEATURES
file that explores every program feature, and anFAQ
file with answers to many common configuration questions.When learning how Procmail works and creating new recipes, the following Procmail man pages are invaluable:
-
procmail
— Provides an overview of how Procmail works and the steps involved with filtering email. -
procmailrc
— Explains therc
file format used to construct recipes. -
procmailex
— Gives a number of useful, real-world examples of Procmail recipes. -
procmailsc
— Explains the weighted scoring technique used by Procmail to match a particular recipe to a message. -
/usr/share/doc/spamassassin/
— Contains a large amount of information pertaining to SpamAssassin.
-
Situs Web yang Berguna
-
Proofpoint Open Source Sendmail — Provides link to sourcecode for sendmail open source, current GPG keys, and contact email addresses.
-
http://www.fetchmail.info/fetchmail-FAQ.html — A thorough FAQ about Fetchmail.
-
http://www.procmail.org/ — The home page for Procmail with links to assorted mailing lists dedicated to Procmail as well as various FAQ documents.
-
https://spamassassin.apache.org/ — The official site of the SpamAssassin project.
Buku Terkait
-
Sendmail Milters: A Guide for Fighting Spam by Bryan Costales and Marcia Flynt; Addison-Wesley — A good Sendmail guide that can help you customize your mail filters.
-
Sendmail oleh Bryan Costales dengan Eric Allman dkk.; O’Reilly & Associates — Referensi Sendmail yang bagus yang ditulis dengan bantuan pencipta asli Delivermail dan Sendmail.
-
Removing the Spam: Email Processing and Filtering by Geoff Mulligan; Addison-Wesley Publishing Company — A volume that looks at various methods used by email administrators using established tools, such as Sendmail and Procmail, to manage spam problems.
-
Internet Email Protocols: A Developer’s Guide oleh Kevin Johnson; Addison-Wesley Publishing Company — Memberikan tinjauan yang sangat menyeluruh tentang protokol email utama dan keamanan yang mereka berikan.
-
Managing IMAP oleh Dianna Mullet dan Kevin Mullet; O’Reilly & Associates — Merinci langkah-langkah yang diperlukan untuk mengonfigurasi server IMAP.
Want to help? Learn how to contribute to Fedora Docs ›