فصل 11. سرویس‌های شبکه: Postfix، Apache، NFS، Samba، Squid، LDAP، SIP، XMPP، Turn

Network services are the programs that users interact with directly in their daily work. They are the tip of the information system iceberg, and this chapter focuses on them; the hidden parts they rely on are the infrastructure we already described. They usually require the encryption technology described in قسمت 10.2, “X.509 certificates” .

11.1. سرور ایمیل

مدیرسیستم‌های شرکت فالکوت Postfix را، با توجه به قابلیت اطمینان بالا و سادگی در پیکربندی برای سرور ایمیل خود انتخاب کرده‌اند. در حقیقت، طراحی آن بگونه‌ای است که هر وظیفه با حداقل تعداد مجوزهای مورد نیاز پیاده‌سازی شود، که این روش یک عامل کاهنده در رابطه با مشکلات امنیتی است.

جایگزین سرور Exim4

دبیان از Exim4 به عنوان سرور پیشفرض ایمیل استفاده می‌کند (به همین دلیل است که زمان نصب اولیه سیستم انتخاب شده است). پیکربندی آن در بسته جداگانه‌ای بنام exim4-config قرار دارد و به صورت خودکار توسط پرسش‌های مطرح شده از Debconf سفارشی‌سازی می‌شود، که بسیار شبیه به پرسش‌های مطرح شده توسط بسته postfix است.

پیکربندی می‌تواند در یک فایل جداگانه قرار داشته باشد (/etc/exim4/exim4.conf.template) یا در مسیر /etc/exim4/conf.d/ بین چندین فایل مختلف تقسیم گردد. در هر دو مورد، فایل‌ها توسط update-exim4.conf به عنوان قالبی برای تولید /var/lib/exim4/config.autogenerated مورد استفاده قرار می‌گیرند. فایل آخر همان فایلی است که توسط Exim4 مورد استفاده قرار می‌گیرد. به لطف این مکانیزم، مقادیر بدست آمده از پیکربندی debconf در Exim - که در فایل /etc/exim4/update-exim4.conf.conf ذخیره شده‌اند - می‌توانند درون فایل پیکربندی Exim قرار گیرند، حتی زمانی که مدیرسیستم یا بسته دیگری پیکربندی پیشفرض آن را تغییر داده باشند.

The Exim4 configuration file syntax has its peculiarities and its learning curve; however, once these peculiarities are understood, Exim4 is a very complete and powerful email server, as evidenced by the tens of pages of documentation.

→ https://www.exim.org/docs.html

11.1.1. نصب Postfix

The postfix package includes the main SMTP daemon. Other packages (such as postfix-ldap and postfix-pgsql) add extra functionality to Postfix, including access to mapping databases. You should only install them if you know that you need them.

هنگام نصب بسته، چندین پرسش از طرف Debconf مطرح می‌شود. پاسخ‌های داده شده برای تولید اولین فایل پیکربندی /etc/postfix/main.cf بکار می‌روند.

پرسش اول درباره نوع راه‌اندازی است. تنها دو تا از پاسخ‌های پیشنهادی در مورد یک سرور متصل به اینترنت مناسب هستند، “Internet site” و “Internet with smarthost”. اولی برای سروری مناسب است که ایمیل ورودی را دریافت کرده و پاسخ را مستقیم به گیرنده می‌فرستد، که به همین دلیل برای شرکت فالکوت مناسب است. دومی برای سروری مناسب است که ایمیل ورودی را دریافت کرده، اما پاسخ را از طریق یک سرور SMTP میانی - یا همان “smarthost” - به گیرنده می‌فرستد. این گزینه اغلب برای افرادی مناسب است که از نشانی IP پویا استفاده می‌کنند، چرا که بسیاری سرورهای ایمیل از دریافت پیام‌های ارسالی از طرف چنین نشانی‌هایی خودداری می‌کنند. در این مورد، smarthost معمولا سرور SMTP شرکت ارائه دهنده خدمات اینترنتی است، که معمولا طوری پیکربندی می‌شود تا ایمیل‌های دریافتی از مشتریان خود را به درستی مسیریابی کند. این راه‌اندازی (با یک smarthost) برای سرورهایی که دائم به اینترنت متصل نیستند نیز مناسب است، چرا که از مدیریت صف پیام‌های غیرقابل ارسال که نیاز به حذف شدن در زمان دیگری را دارند، جلوگیری می‌کند.

پرسش دوم درباره نام کامل رایانه‌ای است که نشانی‌های ایمیل را از یک کاربر محلی تولید می‌کند؛ نام کامل پس از قسمت جلوی “@” می‌آید. در مورد فالکوت، پاسخ برابر است با mail.falcot.com. این تنها پرسشی است که به صورت پیشفرض مطرح می‌شود، اما پیکربندی که در پی دارد نیازهای شرکت فالکوت را تامین نمی‌کند، به همین دلیل مدیرسیستم‌های آن اقدام به اجرای dpkg-reconfigure postfix می‌کنند تا بتوانند گزینه‌های بیشتری را پیکربندی نمایند.

یکی از پرسش‌های اضافی که پرسیده می‌شود درباره تمام دامنه‌های مرتبط با این رایانه است. فهرست پیشفرض شامل نام کامل آن به همراه برخی نام‌های مترادف برای localhost است، اما دامنه اصلی falcot.com باید به صورت دستی اضافه شود. به صورت کلی، این پرسش باید با تمام نام‌های دامنه که برای آن‌ها این رایانه به عنوان یک سروی MX عمل می‌کند پاسخ داده شود؛ به عبارت دیگر، تمام دامنه‌هایی که DNS می‌گوید برای این رایانه ایمیل دریافت می‌کنند. این اطلاعات در متغیر mydestination واقع در فایل پیکربندی اصلی Postfix - /etc/postfix/main.cf - قرار می‌گیرند.

شكل 11.1. نقش رکورد MX در DNS هنگام ارسال ایمیل

در برخی موارد، فرآیند نصب می‌تواند شبکه‌ای را که مجاز به ارسال ایمیل است درخواست کند. در پیکربندی پیشفرض، Postfix فقط ایمیل‌های ارسالی از خود رایانه را قبول می‌کند؛ شبکه محلی نیز معمولا اضافه می‌شود. مدیرسیستم‌های فالکوت 192.168.0.0/16 را به پاسخ پیشفرض اضافه کرده‌اند. اگر این پرسش مطرح نشود، متغیر مربوطه در فایل پیکربندی عبارت است از mynetworks، که در نمونه زیر نیز مشاهده می‌شود.

Local email can also be delivered through procmail. This tool allows users to sort their incoming email according to rules stored in their ~/.procmailrc file. Both Postfix and Exim4 suggest procmail by default, but there are alternatives like maildrop or Sieve filters.

پس از این گام اولیه، فایل پیکربندی مقابل در اختیار مدیرسیستم‌ها قرار گرفته است؛ از این فایل به عنوان نقطه شروعی برای افزودن قابلیت‌های بیشتر در قسمت‌های بعدی استفاده می‌شود.

مثال 11.1. فایل اولیه /etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2



# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname

امنیت گواهینامه‌های SSL زهر ماری

The snake oil certificates, like the snake oil “medicine” sold by unscrupulous quacks in old times, have absolutely no value: you cannot rely on them to authenticate the server since they are automatically generated self-signed certificates. However, they are useful to improve the privacy of the exchanges.

In general they should only be used for testing purposes, and normal service must use real certificates. The Let's encrypt initiative offers free and trusted SSL/TLS certificates, which can be generated using the certbot package as described in قسمت 11.2.2, “Adding support for SSL” and then used in postfix like this:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = /etc/ssl/certs

A different way to generate your own certificates using your own certificate authority is described in قسمت 10.2.2, “زیرساخت کلید عمومی: easy-rsa” .

11.1.2. پیکربندی دامنه‌های مجازی

The mail server can receive mails addressed to other domains besides the main domain; these are then known as “virtual“ domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains.

11.1.2.1. دامنه‌های مستعار مجازی

یک دامنه مستعار مجازی تنها شامل نام‌های مستعار است، نشانی‌هایی که ایمیل‌ها را به سایر نشانی‌ها فوروارد می‌کنند.

چنین دامنه‌ای با افزودن نامش به متغیر virtual_alias_domains و ارجاع دادن به یک فایل نگاشت نشانی در متغیر virtual_alias_maps، فعال می‌شود.

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual

فایل /etc/postfix/virtual یک نگاشت با شیوه‌ای ساده را توضیح می‌دهد: هر خط شامل دو فیلد است که با فاصله از یکدیگر جدا شده‌اند؛ فیلد اول نام مستعار و فیلد دوم فهرستی از نشانی‌های ایمیل است که به آن ارسال می‌شود. شیوه نگارشی بخصوص @domain.com تمام نام‌های مستعار در یک دامنه را پوشش می‌دهد.

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com

After changing /etc/postfix/virtual the postfix table /etc/postfix/virtual.db needs to be updated using sudo postmap /etc/postfix/virtual.

11.1.2.2. دامنه‌های صندوق‌پستی مجازی

احتیاط دامنه مجازی ترکیبی؟

Postfix اجازه نمی‌دهد که از یک دامنه در هر دو متغیر virtual_alias_domains و virtual_mailbox_domains استفاده شود. با این حال هر دامنه موجود در virtual_mailbox_domains به طور ضمنی در virtual_alias_domains نیز قرار داده می‌شود که امکان ترکیب نام‌های مستعار و صندوق‌های پستی در یک دامنه مجازی را فراهم می‌آورد.

پیام‌هایی که به یک دامنه صندوق‌پستی مجازی ارسال می‌شوند در صندوق‌پستی‌هایی ذخیره می‌گردد که در اختیار کاربر محلی سیستم نیست.

فعال‌سازی یک دامنه صندوق‌پستی مجازی نیازمند نام بردن از این دامنه در متغیر virtual_mailbox_domains و ارجاع به یک فایل نگاشت صندوق‌پستی در virtual_mailbox_maps است. پارامتر virtual_mailbox_base شامل دایرکتوری است که در آن صندوق‌های پستی ذخیره می‌شوند.

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts

پارامتر virtual_uid_maps (به همین ترتیب پارامتر virtual_gid_maps) به فایلی ارجاع می‌دهد که شامل نگاشت بین نشانی ایمیل و کاربر سیستم است که "مالک" صندوق‌پستی مربوطه می‌باشد (به همین ترتیب برای گروه). برای دریافت تمام صندوق‌پستی‌هایی که توسط مالک/گروه یکسانی اداره می‌شوند، عبارت static:5000 یک شناسه‌کاربر/شناسه‌گروه ثابت را به آن اختصاص می‌دهد (در اینجا مقدار ۵۰۰۰).

مجدد، شیوه نگارش فایل /etc/postfix/vmailbox کاملا واضح است: دو فیلد که با فاصله از یکدیگر جدا شده‌اند. فیلد اول نشانی ایمیل یکی از دامنه‌های مجازی است و فیلد دوم مکان صندوق‌پستی مورد نظر است (نسبت به دایرکتوری مشخص شده در virtual_mailbox_base). اگر نام صندوق‌پستی با یک اسلش (/) تمام شود، ایمیل‌ها در قالب maildir ذخیره‌سازی می‌شوند؛ در غیر اینصورت از قالب سنتی mbox استفاده می‌گردد. قالب maildir از یک دایکتوری کامل برای ذخیره‌سازی یک صندوق‌پستی استفاده می‌کند، که هر پیام آن در یک فایل جداگانه قرار می‌گیرد. از طرف دیگر، در قالب mbox تمام صندوق‌پستی در یک فایل بزرگ ذخیره می‌شود و هر خطی که با From (به همراه یک فاصله) آغاز گردد، نشانگر ابتدای یک پیام است.

# Jean's email is stored as maildir, with
# one file per email in a dedicated directory
jean@falcot.org falcot.org/jean/
# Sophie's email is stored in a traditional "mbox" file,
# with all mails concatenated into one single file
sophie@falcot.org falcot.org/sophie

11.1.3. محدودیت برای ارسال و دریافت

تعداد رو به افزایش ایمیل‌های انبوه ناخواسته (spam) تصمیم‌گیری درباره اینکه سرور چه ایمیل‌هایی را دریافت کند، دشوار می‌سازد. این قسمت به بررسی برخی راهبردهای موجود در Postfix می‌پردازد.

If the reject-rules are too strict, it may happen that even legitimate email traffic gets locked out. It is therefor a good habit to test restrictions and prevent the permanent rejection of requests during this time using the soft_bounce = yes directive. By prepending a reject-type directive with warn_if_reject only a log message will be recorded instead of rejecting the request.

فرهنگ مشکل اسپم

“Spam” is a generic term used to designate all the unsolicited commercial emails (also known as UCEs) that flood our electronic mailboxes; the unscrupulous individuals sending them are known as spammers. They care little about the nuisance they cause, since sending an email costs very little, and only a very small percentage of recipients need to be attracted by the offers for the spamming operation to make more money than it costs. The process is mostly automated, and any email address made public (for instance, on a web forum, or on the archives of a mailing list, or on a blog, and so on) will be likely discovered by the spammers' robots, and subjected to a never-ending stream of unsolicited messages. Also every contact found at a compromised system is targeted.

تمام مدیرسیستم‌ها تلاش می‌کنند که با استفاده از فیلترهای اسپم با این مزاحمت مقابله کنند، اما اسپمرها نیز در این میان بیکار نمی‌شینند. برخی از آن‌ها برای کار خود حتی شبکه‌ای از رایانه‌ها را از اتحادیه‌های خلافکاری به اجاره می‌گیرند. محاسبات آماری اخیر نشان می‌دهد که بالغ بر ۹۵٪ از ترافیک ایمیل روی اینترنت مربوط به اسپم است!

11.1.3.1. محدودیت‌های دسترسی مبتنی بر IP

عبارت smtpd_client_restrictions کنترل می‌کند که چه رایانه‌هایی مجاز به برقراری ارتباط با سرور ایمیل هستند.

When a variable contains a list of rules, as in the example below, these rules are evaluated in order, from the first to the last. Each rule can accept the message, reject it, or leave the decision to a following rule. As a consequence, order matters, and simply switching two rules can lead to a widely different behavior.

مثال 11.2. محدودیت‌های مبتنی بر نشانی میزبان

smtpd_client_restrictions =
    permit_mynetworks,
    warn_if_reject reject_unknown_client_hostname,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    reject_rhsbl_reverse_client rhsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client dnsbl.sorbs.net

The permit_mynetworks directive, used as the first rule, accepts all emails coming from a machine in the local network (as defined by the mynetworks configuration variable).

The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the warn_if_reject modifier to the reject_unknown_client directive: this modifier turns the rejection into a simple warning recorded in the logs. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement.

نکته جدول‌های دسترسی

The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created using a copy of the /usr/share/doc/postfix/examples/access file shipped with the postfix-doc package and explained in access(5). This model is self-documented in its comments, which means each table describes its own syntax.

The /etc/postfix/access_clientip table lists IP addresses and networks; /etc/postfix/access_helo lists domain names; /etc/postfix/access_sender contains sender email addresses. All these files need to be turned into hash-tables (a format optimized for fast access) after each change, with the sudo postmap /etc/postfix/file command.

The check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.

The last four rules reject any message coming from a server listed in one of the indicated blacklists. RBL is an acronym for Remote Black List, and RHSBL stands for Right-Hand Side Black List. The difference is that the former lists IP addresses, whereas the latter lists domain names. There are several such services. They list domains and IP addresses with poor reputation, badly configured servers that spammers use to relay their emails, as well as unexpected mail relays such as machines infected with worms or viruses.

نکته فهرست سفید و RBLها

فهرست‌های سیاه گاهی شامل سرورهای قانونی هستند که دچار حادثه شده‌اند. در این شرایط، تمام ایمیل‌های ارسالی از این سرورها رد می‌شوند مگر اینکه نام آن‌ها در یک فهرست سفید تعریف شده در /etc/postfix/access_clientip وجود داشته باشد.

Prudence therefore recommends including in the whitelist(s) all the trusted servers from which many emails are usually received.

11.1.3.2. بررسی اعتبار دستورات `EHLO` یا `HELO`

Each SMTP exchange starts with a HELO (or EHLO) command, followed by the name of the sending email server. Checking the validity of this name can be interesting. To fully enforce the restrictions listed in smtpd_helo_restrictions the smtpd_helo_required option needs to be enabled. Otherwise clients could skip the restrictions by not sending any HELO/EHLO command.

مثال 11.3. محدودیت‌های نام اعلام شده در EHLO

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    warn_if_reject reject_unknown_helo_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_rhsbl_helo multi.surbl.org

عبارت ابتدایی permit_mynetworks به تمام رایانه‌های شبکه محلی اجازه می‌دهد که خود را آزادانه معرفی کنند. این مهم است چرا که برخی برنامه‌های ایمیل برای این بخش از پروتکل SMTP به اندازه کافی احترام قائل نیستند و آن‌ها می‌توانند خود را با نام‌های مهمل معرفی کنند.

The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.

The reject_rhsbl_helo allows to specify a black list to check the hostname against an RHSBL.

Using permit_mynetworks as the first rule has an interesting side effect: the following rules only apply to hosts outside the local network. This allows blacklisting all hosts that announce themselves as part of the falcot.com network, for instance by adding a falcot.com REJECT You are not in our network! line to the /etc/postfix/access_helo file.

11.1.3.3. Accepting or Refusing Mails Based on the Announced Sender

هر پیام شامل فرستنده است، که توسط دستور MAIL FROM از پروتکل SMTP اعلام می‌شود؛ مجدد، این اطلاعات می‌توانند به چندین روش ارزیابی گردند.

مثال 11.4. بررسی‌های فرستنده

smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain,
    reject_unlisted_sender,
    reject_non_fqdn_sender,
    reject_rhsbl_sender rhsbl.sorbs.net

جدول /etc/postfix/access_sender با برخی فرستندگان به شیوه‌ای خاص برخورد می‌کند. این معمولا به معنی قراردادن برخی فرستندگان در فهرست سیاه و سفید است.

The reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from joe.bloggs@falcot.com are only accepted if such an address really exists.

در نهایت، قانون reject_non_fqdn_sender پیام‌هایی که از یک نشانی بدون نام دامنه تمام-عیار ارسال شوند را رد می‌کند. در عمل، یعنی پیام‌هایی که به صورت user@machine باشند: نشانی باید به صورت user@machine.example.com یا user@example.com اعلام گردد.

The reject_rhsbl_sender rule reject senders based on a (domain-based) RHSBL service.

11.1.3.4. Accepting or Refusing Mails Based on the Recipient

هر ایمیل حداقل یک گیرنده دارد، که توسط دستور RCPT TO از پروتکل SMTP معرفی می‌شود. این نشانی‌ها همچنین عملیات اعتبارسنجی را تضمین می‌کنند، حتی اگر از بررسی‌های انجام شده روی نشانی فرستنده مشخص نباشد.

مثال 11.5. بررسی‌های گیرنده

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit

reject_unauth_destination قانون پایه‌ای است که پیام‌های خارجی را ملزم می‌سازد نشانی ما را داشته باشند؛ پیام‌هایی که به نشانی خارج از محدوده پوشش این سرور فرستاده شوند رد می‌شوند. بدون این قانون، یک سرور به سیستم بازی تبدیل می‌شود که به اسپمرها اجازه می‌دهد پیام‌های ناخواسته خود را ارسال کنند؛ بنابراین این قانون الزامی است و بهتر است که در قسمت ابتدایی فهرست قرار گیرد، تا قبل از مشخص نشدن گیرنده یک پیام، هیچ قانون دیگری نتواند آن را بررسی کند.

قانون reject_unlisted_recipient پیام‌های ارسالی به کاربران غیرواقعی را رد می‌کند، که با عقل جور در می‌آید. در نهایت، قانون reject_non_fqdn_recipient نشانی‌هایی که تمام-عیار نباشند را رد می‌کند؛ این قانون منجر می‌شود که پیام به jean یا jean@machine ارسال نشود و نیازمند نشانی کامل می‌باشد از جمله jean@machine.falcot.com یا jean@falcot.com.

The permit directive at the end is not necessary. But it can be useful at the end of a restriction list to make the default policy explicit.

11.1.3.5. محدودیت‌های مرتبط با دستور `DATA`

دستور DATA از پروتکل SMTP قبل از محتوای پیام قرار می‌گیرد. با اینکه هیچ اطلاعات خاصی را فراهم نمی‌کند، بجز معرفی قسمت بعدی، می‌تواند مورد بررسی قرار گیرد.

مثال 11.6. بررسی‌های DATA

smtpd_data_restrictions = reject_unauth_pipelining

عبارت reject_unauth_pipelining زمانی منجر به رد پیام می‌شود که فرستنده آن دستوری را قبل از پاسخ به دستور قبلی فرستاده باشد. این عملکرد در مقابل شیوه کار ربات‌های اسپمر قرار می‌گیرد، چرا که آن‌ها اغلب اهمیتی به پاسخ‌ها نمی‌دهند و تمرکز خود را روی ارسال بیشترین پیام در کمترین زمان معطوف می‌سازند.

11.1.3.6. اعمال محدودیت‌ها

Although the above commands validate information at various stages of the SMTP exchange, Postfix sends the actual rejection as a reply to the RCPT TO command by default.

یعنی حتی اگر پیام مبتنی بر یک دستور نامعتبر ... رد شده باشد، Postfix از فرستنده و گیرنده پیام هنگام اعلام رد آن آگاه است. در این مرحله است که می‌تواند پیام مرتبط‌تری را در فایل‌های گزارش قرار دهد تا اینکه همان ابتدای کار این فرآیند متوقف می‌شد. علاوه بر این، تعدادی از برنامه‌های SMTP انتظار شکست عملیات در همان دستورات ابتدایی SMTP را ندارند و این برنامه‌ها کمتر با این عملیات رد دیرموقع، مختل می‌‌شوند.

مزیت نهایی این انتخاب این است که قوانین می‌توانند طی مراحل مختلف تبادل SMTP اطلاعات زیادی کسب کنند؛ این باعث می‌شود مجوزهای بهتری را بتوان تعریف کرد، از جمله رد یک ارتباط غیر-محلی که خود را به عنوان یک فرستنده محلی معرفی کرده باشد.

The default behavior is controlled by the smtpd_delay_reject rule.

11.1.3.7. فیلترکردن مبتنی بر محتوای پیام

سیستم ارزیابی و ایجاد محدودیت بدون ایجاد روشی برای بررسی متن پیام کامل نیست. Postfix بین بررسی‌های انجام گرفته روی سرآیند ایمیل و بدنه آن تفاوت قائل می‌شود.

مثال 11.7. فعال‌سازی فیلترهای محتوا-محور

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

هر دو فایل شامل فهرستی از عبارت‌های منظم (که به نام regexps یا regexes نیز شاخته می‌شوند) و اقدامات مربوط به هر کدام در صورت تطبیق سرآیند یا بدنه ایمیل با آن‌ها می‌باشند.

مثال 11.8. نمونه فایل /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification

بازگشت به مقدمات عبارت منظم

The regular expression term (shortened to regexp or regex) references a generic notation for expressing a description of the contents and/or structure of a string of characters. Certain special characters allow defining alternatives (for instance, foo|bar matches either “foo” or “bar”), sets of allowed characters (for instance, [0-9] means "any digit", and . — a dot — means "any character"), quantification (s? matches either s or the empty string, in other words 0 or 1 occurrence of s; s+ matches one or more consecutive s characters; and so on). Parentheses allow grouping search results.

The precise syntax of these expressions varies across the tools using them, but the basic features are similar.

→ https://en.wikipedia.org/wiki/Regular_expression

اولی به بررسی سرآیند می‌پردازد که آیا شامل نرم‌افزار ایمیل هست یا خیر؛ اگر GOTO Sarbacane (یک نرم‌افزار ایمیل انبوه) پیدا شد، پیام رد می‌شود. عبارت دوم نیز به بررسی محتوای پیام می‌پردازد؛ اگر شامل یک اطلاعیه ویروس باشد، می‌توان تصمیم گرفت بجای رد ایمیل، آن را نادیده بگیریم.

استفاده از این فیلترها مانند راه رفتن روی لبه تیغ است، چرا که در صورت عمومی در نظر گرفتن این قوانین ممکن است بسیاری از ایمیل‌های معتبر و قانونی را از دست بدهیم. در این موارد، نه تنها پیام‌ها از دست می‌روند، بلکه برای فرستندگان آنان نیز پیام‌های خطای آزاردهنده ارسال می‌گردد.

11.1.4. برپایی فهرست خاکستری

“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted after a further delivery attempt with some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time.

Postfix به خودی خود شامل فهرست خاکستری نیست، اما گزینه‌ای وجود دارد که تصمیم‌گیری برای پذیرش یا رد یک پیام را می‌توان به یک برنامه خارجی سپرد. بسته postgrey شامل همین عملکرد است، که به منظور سیاست دسترسی به عنوان سرویس نماینده طراحی شده است.

زمانی که postgrey نصب شود، به عنوان یک فرآیند پس‌زمینه به درگاه ۱۰۰۲۳ گوش می‌کند. سپس می‌توان با تنظیم پارامتر check_policy_service در Postfix، آن را به این منظور پیکربندی کرد:

smtpd_recipient_restrictions =
    permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023

Each time Postfix reaches this rule in the rule set, it will connect to the postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.

اشکال اصلی فهرست خاکستری این است که پیام‌های قانونی با تاخیر مواجه می‌شوند، که برای همیشه قابل قبول نیست. همچنین بار سرورهایی که بسیاری ایمیل‌های قانونی را ارسال می‌کنند، افزایش می‌‌دهد.

در عمل نقطه ضعف فهرست خاکستری

به لحاظ نظری، فهرست خاکستری تنها باید اولین پیام ارسالی از یک فرستنده به گیرنده را با تاخیر همراه سازد، که این تاخیر در حد چند دقیقه است. اما حقیقت چیزی دیگری است. برخی شرکت‌های بزرگ ارائه‌دهنده خدمات اینترنت، خوشه‌ای از سرورهای SMTP را استفاده می‌کنند و زمانی که یک پیام در ابتدا رد می‌شود، سروری که به این کد خطا پاسخ می‌دهد الزاما با سروری که پیام اولیه را فرستاده است، یکسان نیست. زمانی که این اتفاق می‌افتد، سرور دوم نیز این پیام خطای موقت را دریافت می‌کند و به همین ترتیب؛ ممکن است چندین ساعت طول بکشد تا همان سرور اولیه به مسیر تبادل پیام بازگردد، چرا که سرورهای SMTP با هر بار مواجه پیام خطا، زمان ارسال مجدد آن را افزایش می‌دهند.

به عنوان یک پیامد، نشانی IP دریافتی حتی برای یک فرستنده نیز می‌تواند در طول زمان تغییر کند. اما مشکل دیگری نیز وجود دارد: حتی نشانی فرستنده نیز می‌تواند تغییر کند. برای نمونه، بسیاری سروهای میلینگ-لیست به منظور تعامل با پیام‌های خطا اقدام به رمزگذاری اطلاعات اضافی در قسمت نشانی فرستنده می‌کنند (که به عنوان bounces شناخته می‌شود). هر پیام جدید که به میلینگ-لیست ارسال می‌شود نیاز به عبور از فهرست خاکستری را دارد، که به معنی ذخیره‌سازی (موقت) آن در سرور فرستنده است. برای میلینگ‌-لیست‌های بسیار بزرگ (با ده‌ها هزار مشترک) این امر به زودی مشکل بزرگی می‌شود.

برای مقابله با این مشکلات، Postgrey فهرست سفیدی از چنین سایت‌هایی را مدیریت می‌کند و پیام‌هایی که از آن‌ها ارسال شود را بدون عبور از فهرست خاکستری مورد پذیرش قرار می‌دهد. این فهرست به سادگی می‌تواند برای نیازهای شبکه محلی سازگار شود، چرا که در فایل /etc/postgrey/whitelist_clients قرار گرفته است.

مطالعه بیشتر فهرست خاکستری انتخابی با استفاده از milter-greylist

اشکالات موجود در فهرست خاکستری می‌تواند با اعمال آن‌ها بر مجموعه‌ای از رایانه‌ها که منبع احتمالی اسپم هستند، رفع گردد (چرا که آن‌ها در یک فهرست سیاه DNS قرار می‌گیرند). اینکار با استفاده از postgrey ممکن نیست اما از milter-greylist برای چنین مواقعی استفاده می‌گردد.

در این سناریو، از آنجا که فهرست‌های سیاه DNS منجر به رد قعطی یک پیام نمی‌شود، استفاده از فهرست‌های سیاه تهاجمی منطقی به نظر می‌رسد، از جمله آن‌هایی که نشانی‌های IP پویا رایانه‌های ISP را شامل می‌شوند (از جمله pbl.spamhaus.org یا dul.dnsbl.sorbs.net).

Since milter-greylist uses Sendmail's milter interface, the postfix side of its configuration is limited to “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. The greylist.conf(5) manual page documents /etc/milter-greylist/greylist.conf and the numerous ways to configure milter-greylist. You will also have to edit /etc/default/milter-greylist to actually enable the service.

11.1.5. سفارشی‌سازی فیلترها مبتنی بر گیرنده

قسمت‌های قسمت 11.1.3, “محدودیت برای ارسال و دریافت” و قسمت 11.1.4, “برپایی فهرست خاکستری” بسیاری محدودیت‌های ممکن را بررسی کرده‌اند. همگی آن‌ها کاربرد خود برای محدودکردن بخشی از اسپم‌ها را دارند اما شامل نواقصی نیز هستند. بنابراین بسیار متداول است که مجموعه فیلترهای بکار رفته روی گیرنده را سفارشی‌سازی کرد. در شرکت فالکوت، استفاده از فهرست خاکستری در کار اغلب کاربران مشکلی بوجود نمی‌آورد اما برخی نیز نیاز به تاخیر بسیار کمی در کار خود دارند (از جمله واحد پشتیبانی فنی). به همین شکل، واحد تجاری گاهی اوقات مشکلاتی با برخی مشتریان آسیایی دارد که در فهرست سیاه قرار گرفته‌اند؛ این واحد درخواست یک نشانی بدون فیلتر به منظور مکاتبه با آن‌ها را دارد.

Postfix با استفاده از مفهوم “کلاس محدودیت” امکان سفارشی‌سازی فیلترها را فراهم می‌کند. کلاس‌ها در پارامتر smtpd_restriction_classes قرار گرفته و به شیوه مشابه smtpd_recipient_restrictions تعریف شده‌اند. عبارت check_recipient_access نگاشتی بین یک گیرنده و مجموعه‌ای از محدودیت‌های آن برقرار می‌کند.

مثال 11.9. تعریف کلاس‌های محدودیت در main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive =
        reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_unauth_destination,
        check_recipient_access hash:/etc/postfix/recipient_access

مثال 11.10. فایل /etc/postfix/recipient_access

# Unfiltered addresses
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressive filtering for some privileged users
joe@falcot.com         aggressive

# Special rule for the mailing-list manager
sympa@falcot.com       reject_unverified_sender

# Greylisting by default
falcot.com             greylisting

11.1.6. Integrating an Antivirus Filter

The many viruses circulating as attachments to emails make it important to set up an antivirus solution at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages.

SECURITY Controversial Discussion of Anti-Virus Software

The usage of virus scanners, or so called antivirus software, is controversial. There is usually a gap between the release of some piece of malware and the addition of detection rules to the antivirus database. During this gap, there is no software-based protection. Further, the usage often requires to run additional software, for example, to uncompress archives and scan all kinds of executables, which drastically increases the exploit potential of the antivirus software itself. Usage of such software solutions can therefor never replace awareness campaigns and simple behavioral rules (never open unsolicited sent attachments, etc.).

The Falcot administrators selected clamav from the homonymous package.

وظیفه برقراری ارتباط بین آنتی‌ویروس و سرور ایمیل بر عهده clamav-milter است. یک milter (که مخفف mail filter است) یک برنامه فیلترکردن بخصوص است که برای تعامل با سرورهای ایمیل طراحی شده است. یک milter از یک رابط استاندارد برنامه‌نویسی یا API استفاده می‌کند که عملکرد بهتری در مقایسه با فیلترهای خارجی برای سرورهای ایمیل فراهم می‌کند. milterها در ابتدا توسط Sendmail معرفی شدند اما Postfix به زودی از آن‌ها پشتیبانی کرد.

نگاه سریع فیلتر ایمیل برای Spamassassin

بسته spamass-milter فیلتر ایمیلی مبتنی بر SpamAssassin فراهم می‌کند، برنامه معروف شناسایی ایمیل ناخواسته. می‌تواند برای پرچم‌گذاری پیام‌ها به عنوان اسپم احتمالی استفاده شود (با افزودن یک سرآیند اضافی) و/یا رد پیام‌هایی که امتیاز “spamminess” آن‌ها بیش از محدوده استاندارد باشد.

زمانی که بسته clamav-milter نصب شود، فیلتر ایمیل باید به گونه‌ای پیکربندی شود که روی یک درگاه TCP جدا از مقدار پیشفرض سوکت نامگذاری شده قرار بگیرد. اینکار با استفاده از dpkg-reconfigure clamav-milter صورت می‌گیرد. زمانی که پرسش “Communication interface with Sendmail” مطرح می‌شود، “inet:10002@127.0.0.1” را پاسخ دهید.

یادداشت درگاه واقعی TCP در مقایسه با سوکت نامگذاری شده

دلیلی که از درگاه واقعی TCP بجای سوکت نامگذاری شده استفاده می‌کنیم این است که فرآیندهای پس‌زمینه postfix اغلب به صورت chroot شده اجرا می‌گردند که در این حالت به دایرکتوری قرار گرفته در سوکت نامگذاری شده دسترسی ندارند. همچنین می‌توانید تصمیم بگیرید که هنگام استفاده از سوکت نامگذاری شده از یک محل درون chroot (/var/spool/postfix/) استفاده کنید.

پیکربندی استاندارد ClamAV برای اکثر موقعیت‌های مناسب است، اما برخی پارامترهای مهم هنوز می‌توانند با استفاده از دستور dpkg-reconfigure clamav-base سفارشی گردند.

گام آخر اطلاع‌رسانی به Postfix درباره فیلتر تازه-پیکربندی شده است که به سادگی افزودن عبارت زیر به /etc/postfix/main.cf است:

# Virus check with clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002

If the antivirus causes problems, this line can be commented out, and systemctl reload postfix should be run so that this change is taken into account.

در عمل آزمایش آنتی‌ویروس

Once the antivirus is set up, its correct behavior should be tested. The simplest way to do that is to send a test email with an attachment containing the eicar.com (or eicar.com.zip) file, which can be downloaded online:

→ https://2016.eicar.org/86-0-Intended-use.html

این فایل یک ویروس واقعی نیست، بلکه به عنوان فایل آزمایشی توسط تمام آنتی‌ویروس‌های موجود در بازار به منظور آزمایش عملکرد صحیح برنامه مورد استفاده قرار می‌گیرد.

اکنون تمام پیام‌های ارسالی به Postfix از طریق فیلتر آنتی‌ویروس عبور داده می‌شوند.

11.1.7. Fighting Spam with SPF, DKIM and DMARC

The high number of unsolicited email sent every day led to the creation of several standards, which aim at validating that the sending host of an email is authorized and that the email has not been tampered with. The following systems are all DNS-based and require the administrators to not only have control over the mail server, but over the DNS for the domain in question too.

CAUTION Controversial Discussion

Like any other tool, the following standards have limits and real effects if put to use. They can (and should) lead to emails being rejected or even just discarded. If that happens to some legitimate emails (sometimes sent from a misconfigured SMTP server), it usually causes anger and a lack of understanding by the user. Therefore these rules are often applied as a "soft fail" or a "soft reject", which usually means that failing the checks only leads to adding a (header) mark to the affected email. There are people who think that this makes these standards "broken by design". Decide for yourself and be careful about how strict you choose to apply these standards.

11.1.7.1. Integrating the Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is used to validate if a certain mail server is allowed to send emails for a given domain. It is mostly configured through DNS. The syntax for the entry to make is explained in detail at:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to send email for the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.

Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all

Let's take a quick look at the falcot.org entry.

# host -t TXT falcot.org
falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

It states that the IP of the sender must match the A record for the sending domain, or must be listed as one of the Mail Exchange Resource Records for the current domain, or must be one of the three mentioned IP4 addresses. All other hosts should be marked as not being allowed to send email for the sender domain. The latter is called a "soft fail" and is intended to mark the email accordingly, but still accept it.

The postfix mail server can check the SPF record for incoming emails using the postfix-policyd-spf-python package, a policy agent written in Python. The file /usr/share/doc/postfix-policyd-spf-python/README.Debian describes the necessary steps to integrate the agent into postfix, so we won't repeat it here.

The configuration is done in the file /etc/postfix-policyd-spf-python/policyd-spf.conf, which is fully documented in policyd-spf.conf(5) and /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. The main configuration parameters are HELO_reject and Mail_From_reject, which configure if emails should be rejected (Fail) or accepted with a header being appended (False), if checks fail. The latter is often useful, when the message is further processed by a spam filter.

If the result is intended to be used by opendmarc ( قسمت 11.1.7.3, “Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)” ), then Header_Type must be set to AR.

Note that spamassassin contains a plugin to check the SPF record.

11.1.7.2. Integrating DomainKeys (DKIM) Signing and Checking

The Domain Keys Identified Mail (DKIM) standard is a sender authentication system. The mail transport agent, here postfix, adds a digital signature associated with the domain name to the header of outgoing emails. The receiving party can validate the message body and header fields by checking the signature against a public key, which is retrieved from the senders DNS records.

→ http://dkim.org/

The necessary tools are shipped with the opendkim and opendkim-tools packages.

First the private key must be created using the command opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR must be a unique name for the key. It can be as simple as "mail" or the date of creation, if you plan to rotate keys.

مثال 11.11. Create a private key for signing E-Mails from falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*

This will create the files /etc/dkimkeys/mail.private and /etc/dkimkeys/mail.txt and set the appropriate ownership. The first file contains the private key, and the latter the public key that needs to be added to the DNS:

Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

The opendkim package in Debian defaults to a keysize of 2048 bit. Unfortunately some DNS servers can only handle text entries with a maximum length of 255 characters, which is exceeded by the chosen default keysize. In this case use the option -b 1024 to chose a smaller keysize. If opendkim-testkey succeeds, the entry has been successfully set up. The syntax of the entry is explained here:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

To configure opendkim, SOCKET and RUNDIR must be chosen in /etc/default/opendkim. Please note that SOCKET must be accessible from postfix in its chrooted environment. The further configuration is done in /etc/opendkim.conf. The following is a configuration excerpt, which makes sure that the Domain "falcot.com" and all subdomains (SubDomain) are signed by the Selector "mail" and the single private key (KeyFile) /etc/dkimkeys/mail.private. The "relaxed" Canonicalization for both the header and the body tolerates mild modification (by a mailing list software, for example). The filter runs both in signing ("s") and verification ("v") Mode. If a signature fails to validate (On-BadSignature), the mail should be quarantined ("q").

[...]
Domain                  falcot.com
KeyFile                 /etc/dkimkeys/mail.private
Selector                mail

[...]
Canonicalization        relaxed/relaxed
Mode                    sv
On-BadSignature         q
SubDomains              yes

[...]
Socket                  inet:12345@localhost

[...]
UserID                  opendkim

It is also possible to use multiple selectors/keys (KeyTable), domains (SigningTable) and to specify internal or trusted hosts (InternalHosts, ExternalIgnoreList), which may send mail through the server as one of the signing domains without credentials.

The following directives in /etc/postfix/main.cf make postfix use the filter:

milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345

To differentiate signing and verification it is sometimes more useful to add the directives to the services in /etc/postfix/master.cf instead.

More information is available in the /usr/share/doc/opendkim/ directory and the manual pages opendkim(8) and opendkim.conf(5).

Note that spamassassin contains a plugin to check the DKIM record.

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

The Domain-based Message Authentication, Reporting and Conformance (DMARC) standard can be used to define a DNS TXT entry with the name _dmarc and the action that should be taken when emails that contain your domain as the sending host fail to validate using DKIM and SPF.

→ https://dmarc.org/overview/

Let's have a look at the entries of two large providers:

# host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

Yahoo has a strict policy to reject all emails pretending to be sent from a Yahoo account but missing or failing DKIM and SPF checks. Google Mail (Gmail) propagates a very relaxed policy, in which such messages from the main domain should still be accepted (p=none). For subdomains they should be marked as spam (sp=quarantine). The addresses given in the rua key can be used to send aggregated DMARC reports to. The full syntax is explained here:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

The postfix mail server can use this information too. The opendmarc package contains the necessary milter. Similar to opendkim SOCKET and RUNDIR must be chosen in /etc/default/opendmarc (for Unix sockets you must make sure that they are inside the postfix chroot to be found). The configuration file /etc/opendmarc.conf contains detailed comments and is also explained in opendmarc.conf(5). By default, emails failing the DMARC validation are not rejected but flagged, by adding an appropriate header field. To change this, use RejectFailures true.

The milter is then added to smtpd_milters and non_smtpd_milters. If we configured the opendkim and opendmarc milters to run on ports 12345 and 54321, the entry in /etc/postfix/main.cf looks like this:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321

The milter can also be selectively applied to a service in /etc/postfix/master.cf instead.

11.1.8. SMTP احرازهویت شده

به منظور امکان ارسال ایمیل ابتدا باید به سرور SMTP دسترسی داشت؛ همچنین نیازمند سرور SMTP گفته شده به منظور ارسال ایمیل از درون خود است. برای کاربران رومینگ، اینکار نیازمند تغییر مداوم پیکربندی برنامه SMTP است چرا که سرور SMTP فالکوت پیام‌هایی را که نشانی‌های IP خارج از شرکت را داشته باشند رد می‌کند. دو راه حل موجود است: یا کاربر رومینگ سرور SMTP را روی رایانه خود نصب کند یا کماکان به شیوه‌ای از سرور شرکت استفاده کنند که به عنوان یک کارمند احرازهویت شوند. راه اول توصیه نمی‌شود چرا که رایانه ممکن است همیشه متصل نباشد و در صورت بروز مشکل امکان ارسال مجدد پیام وجود نخواهد داشت؛ ما روی راه حل دوم تمرکز می‌کنیم.

احرازهویت SMTP در Postfix نیازمند SASL یا Simple Authentication and Security Layer است. اینکار نیازمند نصب بسته‌های libsasl2-modules و sasl2-bin، سپس ثبت گذرواژه در پایگاه‌داده SASL برای هر کاربری که نیازمند احرازهویت با استفاده از سرور SMTP است. اینکار با استفاده از دستور saslpasswd2 انجام می‌شود که چندین پارامتر را دریافت می‌کند. گزینه -u دامنه احرازهویت را تعریف می‌کند که باید با پارامتر smtpd_sasl_local_domain در پیکربندی Postfix یکسان باشد. گزینه -c اجازه تعریف یک کاربر جدید و -f اجازه تعریف فایل پیکربندی آن را می‌دهد در صورتی که نیاز باشد پایگاه‌داده SASL در مسیر دیگری بجز /etc/sasldb2 قرار بگیرد.

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... type jean's password twice ...]

نکته اینکه پایگاه‌داده SASL در دایرکتوی Postfix ایجاده شده است. به منظور حصوص اطمینان از یکپارچگی، فایل /etc/sasldb2 را با دستور ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2 به یک پیوند نمادین پایگاه‌داده مورد استفاده Postfix تبدیل کرده‌ایم.

اکنون نیازمند پیکربندی Postfix برای استفاده از SALS هستیم. ابتدا کاربر postfix باید به گروه sasl اضافه گردد تا بتواند به پایگاه‌داده SASL دسترسی داشته باشد. برای فعال‌سازی SASL به چندین پارامتر دیگر نیاز است و پارامتر smtpd_recipient_restrictions نیز به منظور اجازه به برنامه‌های احرازهویت شده با SASL برای ارسال ایمیل، مورد نیاز است.

مثال 11.12. فعال‌سازی SASL در /etc/postfix/main.cf

# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]

It is usually a good idea to not send passwords over an unencrypted connection. Postfix allows to use different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the /etc/postfix/master.cf file. To turn off authentication at all for port 25 (smtpd service) add the following directive:

smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]

If for some reason clients use an outdated AUTH command (some very old mail clients do), interoperability with them can be enabled using the broken_sasl_auth_clients directive.

اضافی برنامه SMTP احرازهویت شده

اکثر برنامه‌های ایمیل قبل از ارسال پیام‌های خارجی، قادر به احزارهویت توسط سرور SMTP هستند که استفاده از این ویژگی به سادگی پیکربندی چند پارامتر متناسب با آن است. اگر برنامه مورد نظر چنین قابلیتی نداشته باشد، راهکار پیشنهادی استفاده از یک سرور Postfix محلی به منظور ارسال مجدد ایمیل از طریق سرور SMTP راه‌دور است. در این مورد، خود Postfix محلی برنامه‌ای است که با SASL احرازهویت می‌شود. پارامترهای مورد نیاز عبارتند از:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.falcot.com]

فایل /etc/postfix/sasl_passwd باید شامل نام کاربری و گذرواژه مورد نیاز برای احرازهویت در سرور mail.falcot.com است. برای نمونه:

[mail.falcot.com]   joe:LyinIsji

مانند تمام نگاشت‌های Postfix، نیاز است که این فایل توسط دستور postmap به /etc/postfix/sasl_passwd.db تبدیل شود.