فصل 11. خدمات الشبكة: Postfix،‏ Apache،‏ NFS،‏ Samba،‏ Squid،‏ LDAP،‏ SIP،‏ XMPP،‏ TURN

خدمات الشبكة هي البرامج التي يتفاعل معها المستخدمون مباشرة في عملهم اليومي. فهي غيض من فيض نظام المعلومات، ويركز عليها هذا الفصل؛ الأجزاء المخفية التي يعتمدون عليها هي البنية التحتية التي وصفناها بالفعل. وهي عادة ما تتطلب تقنية التشفير الموصوفة في قسم 10.2, “X.509 certificates”.

11.1. مخدم البريد الإلكتروني

اختار مديرو النظم في شركة فلكوت Postfix كمخدم للبريد الإلكتروني، وذلك لموثوقيته وسهولة إعداده. وفعلاً، يفرض تصميمه استخدام عملية منفصلة تتمتع مجموعة صغيرة من الصلاحيات لكل واحدة من مهماته، وهذا إجراء ممتاز للحد من ضرر المشاكل الأمنية.

بدائل مخدم Exim4

تستخدم دبيان مخدم 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، حتى عندما يُعدِّل مدير النظام أو الحزم الأخرى على إعدادات Exim الافتراضية.

صيغة إعدادات Exim4 لها مميزاتها وتحتاج زمناً لتعلمها؛ لكن إذا فهمت هذه المميزات، فإن Exim4 هو خادم بريد إلكتروني مكتمل وقوي جداً، كما تشهد عشرات صفحات الوثائق.

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

11.1.1. تثبيت Postfix

تتضمن الحزمة postfix خدمة SMTP الرئيسية. أما الحزم الأخرى (مثل postfix-ldap وpostfix-pgsql) فهي تضيف وظائف زائدة إلى Postfix، منها الوصول إلى قواعد معطيات جهات الاتصال. عليك تثبيتها فقط إذا كنت تعرف أنك تحتاجها.

تطرح Debconf عدة أسئلة أثناء تثبيت الحزمة. تسمح الإجابات بتوليد نسخة أولية من ملف الإعداد /etc/postfix/main.cf.

يستفسر السؤال الأول عن نوع الإعداد. هناك إجابتين فقط من الإجابات المقترحة تناسب حالة المخدمات المتصلة بالإنترنت، هما ”Internet site“ و ”Internet with smarthost“. الأول مناسب للمخدمات التي تستقبل البريد الوارد وترسل البريد الصادر مباشرة إلى متلقيه، ولذلك فهو يناسب حالة شركة فلكوت تماماً. أما الثاني فيلائم المخدمات التي تستقبل البريد الوارد بشكل طبيعي، لكنها ترسل البريد الصادر عبر مخدم SMTP وسيط —”المضيف الذكي smarthost“— بدلاً من إرسالها مباشرة إلى المخدم المتلقي. يناسب هذا الخيار كثيراً الأفراد الذين يملكون عناوين IP ديناميكية، لأن العديد من مخدمات البريد الإلكتروني ترفض الرسائل الواردة من هذه العناوين. في هذه الحالة، سيكون المضيف الذكي عادة مخدم SMTP تابع لمزود خدمة الإنترنت، ويكون مُعدّاً بحيث يستقبل دوماً البريد الوارد من زبائن المزود وتوجيهها بشكل مناسب. هذا الإعداد (مع المضيف الذكي) يناسب أيضاً المخدمات التي لا تتصل بالإنترنت دائماً، حتى تتفادى إدارة رتل من الرسائل غير المسلّمة التي يجب إعادة محاولة إرسالها لاحقاً.

يهتم السؤال الثاني بالاسم الكامل للجهاز، الذي سيستخدم لتوليد عناوين البريد الإلكتروني اعتماداً على اسم المستخدم المحلي (هذا هو الجزء الذي يوضع خلف علامة ”@“). في حالة فلكوت، يجب أن تكون الإجابة mail.falcot.com. هذا هو السؤال الوحيد الذي يطرح افتراضياً، لكن الإعداد الناتج ليس كاملاً كفاية بالنسبة لحاجات فلكوت، لذلك استدعى مديرو النظم الأمر dpkg-reconfigure postfix حتى يتمكنوا من تخصيص المزيد من المتغيرات.

أحد الأسئلة الإضافية يطلب جميع أسماء النطاقات المرتبطة بهذا الجهاز. تتضمن القائمة الافتراضية الاسم الكامل بالإضافة لبضعة مرادفات للاسم localhost. لكن يجب إضافة النطاق الرئيسي falcot.com يدوياً. بصورة عامة، يجب إجابة هذا السؤال بإعطاءه جميع أسماء النطاقات التي سيعمل هذا المخدم معها كمخدم MX؛ بكلمات أخرى، جميع أسماء النطاقات التي يبين مخدم DNS أنها تستطيع استقبال البريد الإلكتروني. ينتهي المطاف بهذه المعلومات في المتغير mydestination في الملف /etc/postfix/main.cf (ملف الإعداد الرئيسي لمخدم Postfix).

شكل 11.1. دور السجل MX (سجل DNS) أثناء إرسال البريد

في بعض الحالات، قد يسأل التثبيت أيضاً عن الشبكات التي يجب السماح لها بإرسال البريد عبر الجهاز. في الإعداد الافتراضي، يقبل Postfix الرسائل الإلكترونية التي ترد من الجهاز نفسه فقط؛ لذلك نحتاج إضافة الشبكة المحلية عادة. أضاف مديرو النظم في شركة فلكوت 192.168.0.0/16 إلى الإجابة الافتراضية. إذا لم يطرح عليك هذا السؤال، فالمتغير الموافق له في ملف الإعداد هو mynetworks، كما هو واضح في المثال أدناه.

كما يمكن تسليم البريد الإلكتروني المحلي من خلال procmail. هذه الأداة تسمح للمستخدمين بفرز بريدهم الإلكتروني الوارد وفقًا للقواعد المخزنة في ملف ~/.procmailrc . يقترح كل من Postfix و Exim4 procmail بشكل افتراضي ، ولكن هناك بدائل مثل maildrop أو مرشحات منخل(Sieve).

بعد هذه الخطوة الأولى، حصل مديرو النظم على ملف الإعداد التالي؛ الذي سيستخدمونه كنقطة انطلاق لإضافة بعض الوظائف الأخرى كما هو مشروح في الأقسام التالية.

مثال 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

أمن شهادات زيت الثعبان

الشهادات التي تدعى شهادات زيت الثعبان (snake oil)، مثل ”دواء“ زيت الثعبان الذي كان يبيعه المشعوذون عديمو الضمير في الأيام الخالية، ليس لها أي قيمة على الإطلاق: فلا يمكنك الاعتماد عليها للتحقق من هوية المخدم لأنها تولَّد آلياً ومُوقّعة ذاتياً (self-signed). لكنها تفيد في زيادة خصوصية التبادلات على أي حال.

بشكل عام يجب أن تستخدم فقط لأغراض الاختبار، والخدمة العادية يجب أن تستخدم شهادات حقيقية. دعونا تشفير تقدم مبادرة مجانية وموثوق بها SSL / TLS الشهادات، والتي يمكن إنشاؤها باستخدام certbot حزمة كما هو موضح في قسم 11.2.2, “Adding support for SSL” ثم استخدامها في postfix مثل هذا:

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. النطاقات الظاهرية للأسماء المستعارة

لا يحوي نطاق الأسماء المستعارة الظاهري إلا أسماء مستعارة (aliases) فقط، أي عناوين تستخدم لتوجيه الرسائل إلى عناوين أخرى فقط.

تُنشّط هذه النطاقات بإضافة أسمائها إلى المتغير 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. نطاقات صناديق البريد الظاهرية

تُخزَّن الرسائل المرسلة إلى نطاقات صناديق البريد الظاهرية في صناديق بريدية غير مرتبطة بأي مستخدم محلي للنظام.

لتفعيل نطاق صناديق بريد ظاهري يجب إضافة اسم هذا النطاق إلى المتغير 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 التي تسند قيمة UID/GID ثابتة (القيمة 5000 هنا).

صيغة الملف /etc/postfix/vmailbox بسيطة جداً أيضاً: حقلين تفصلهما مسافة بيضاء. الحقل الأول هو عنوان بريد إلكتروني ضمن أحد النطاقات الظاهرية، والثاني موقع صندوق البريد المرتبط معه (نسبةً إلى المجلد المحدّد في virtual_mailbox_base). إذا انتهى اسم صندوق البريد بشرطة مائلة امامية (/)، ستخزّن الرسائل الإلكترونية في صيغة maildir؛ وإلا سوف تستخدم صيغة mbox التقليدية بدلاً منها. تَستخدِم صيغة maildir مجلداً كاملاً لتخزين صندوق البريد، وكل رسالة مفردة تُخزَّن في ملف منفصل. أما في صيغة mbox، فيخزن صندوق البريد كله في ملف واحد، وكل سطر يبدأ بالصيغة ”From “ (كلمة 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.

يحاول جميع مديرو النظم مجابهة هذا الإزعاج بمرشحات الرسائل الدعائية، لكن طبعاً يستمر spammers في التكيف في سبيل المرور عبر هذه المرشحات. بل إن بعضهم يطلب خدمات من جماعات إجرامية لاستئجار شبكات من الأجهزة المصابة بدودة. تقدر الإحصائيات الأخيرة أن الرسائل الدعائية تشكل حتى 95% من مجمل الرسائل الإلكترونية التي تنتقل عبر الإنترنت!

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.

تلميح جداول access

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 one 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.

هذا يعني أنه حتى لو رفضت الرسالة نتيجة أمر EHLO خاطئ، سيعلم Postfix من هو المرسل ومن المستقبل عند إعلان الرفض. ويستطيع عندها تسجيل رسالة أوضح في السجلات وهذا غير ممكن إذا قوطعت عملية التبادل منذ البداية. بالإضافة لذلك، لا يتوقع بعض عملاء SMTP إخفاق عملية التبادل عند أوامر SMTP الأولية، وسيقل تشوش هذه العملاء عند استلام الرفض في وقت متأخر.

هناك ميزة أخيرة لهذا الخيار هي أن القواعد تستطيع جمع المعلومات أثناء المراحل المتنوعة لعملية تبادل SMTP؛ وهذا يسمح بتعريف صلاحيات أدق، مثل رفض اتصال غير محلي إذا أعلن أن مرسله مرسل محلي.

The default behavior is controlled by the smtpd_delay_reject rule.

11.1.3.7. الترشيح اعتماداً على محتويات الرسالة

لن يكتمل نظام التقييد والتحقق دون طريقو لتطبيق الفحوضات على محتويات الرسائل. يفرق Postfix بين الفحوصات المطبّقة على ترويسات البريد الإلكتروني من تلك التي تطبق على متن (body) الرسالة.

مثال 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، سوف يعمل كخدمة وينصت للمنفذ 10023. يمكن عندها ضبط Postfix لاستخدامه، بإضافة المتغير check_policy_service كقيد إضافي:

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.

السيئة الرئيسية للقوائم الرمادية هي تأخر استلام الرسائل المشروعة، وهذا غير مقبول دائماً. كما يزيد العبئ على المخدمات التي ترسل الكثير من الرسائل المشروعة.

ممارسة عملية عيوب القوائم الرمادية

نظرياً، يفترض أن تؤخر القوائم الرمادية الرسالة الأولى من مرسل معين إلى مستقبل معين، وأن التأخير نموذجياً لا يتعدى دقائق. لكن الواقع قد يختلف قليلاً. بعض ISP يستخدمون عناقيد من مخدمات SMTP، وعند رفض الرسالة اول مرة، قد يحاول مخدم آخر مختلف عن الأول إعادة إرسالها. عندما يحدث ذلك، يحصل المخدم الثاني أيضاً على رسالة خطأ مؤقت نتيجة استخدام القوائم الرمادية، وهكذا؛ قد تستغرق عملية الإرسال عدة ساعات قبل أن يحاول أحد المخدمات التي حاولت من قبل إعادة الإرسال، وذلك لأن مخدمات SMTP ترزيد عادة التأخير بين المحاولات بعد كل محاولة فاشلة.

نتيجة لذلك، قد يتغير مع الزمن عنوان IP لنفس المخدم المرسل أيضاً. بل وأكثر من ذلك، قد يتغير عنوان المرسل حتى. مثلاً، تُشفِّر الكثير من مخدمات القوائم البريدية معلومات إضافية في عنوان المرسل بحيث تتمكن من معالجة رسائل الأخطاء (تدعى bounces). كل رسالة جديدة ترسل إلى القائمة البريدية عليها عنئذ المرور عبر القوائم الرمادية، وهذا يعني أنه يجب تخزينها (مؤقتاً) على مخدم المرسل. بالنسبة للقوائم البريدية الكبيرة جداً (التي تحوي عشرات ألوف المشتركين)، سرعان ما يصبح هذا الأمر مشكلة.

لتخفيف هذه الأضرار، يدير Postgrey قائمة بيضاء بهذه المواقع، ويقبل الرسائل التي ترد منها فوراً. يمكن ملائمة هذه القائمة مع الاحتياجات المحلية بسهولة، إذ أنها مخزنة في الملف /etc/postgrey/whitelist_clients.

التعمق أكثر الاستخدام الانتقائي للقوائم الرمادية باستخدام milter-greylist

يمكن تخفيف أضرار القوائم الرمادية باستخدامها فقط على مجموعة جزئية من العملاء الذي اعتبروا كمصدر للرسائل الدعائية مسبقاً (لأنهم مذكورون في قائمة DNS سوداء). هذا غير ممكن في postgrey ولكن يمكن استخدام milter-greylist بهذه الطريقة.

في تلك الحالة، يصبح استخدام القوائم السوداء الصارمة حلاً منطقياً، بما فيها القوائم التي تذكر جميع عناوين IP الديناميكة التابعة لعملاء ISP ما (مثل pbl.spamhaus.org أو dul.dnsbl.sorbs.net)، لأن قوائم DNS السوداء لن تسبب رفضاً قاطعاً.

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 ميزة تخصيص للمرشحات عبر مفهوم ”فئات التقييد restriction class“. يصرح عن الفئات في المتغير 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) هو برنامج ترشيح مصمم خصيصاً للتواصل مع مخدمات البريد الإلكتروني. يستخدم الملتر واجهة برمجية تطبيقات (API أو application programming interface) تعطي أداءً أفضل بكثير من المرشحات الخارجية. قدم Sendmail الملاتر أول مرة، لكن سرعان ما لحق Postfix به.

فور تثبيت الحزمة clamav-milter، يجب إعادة ضبط الملتر ليعمل على منفذ TCP بدلاً من استخدام المقبس الشبكي المسمّى الافتراضي. يمكن تنفيذ ذلك باستخدام dpkg-reconfigure clamav-milter. عند طلب ”Communication interface with Sendmail“، أجب عليه بإدخال ”inet:10002@127.0.0.1“.

ملاحظة منفذ TCP حقيقي أو مقبس مسمّى

سبب استعمالنا لمنفذ TCP حقيقي بدلاً من مقبس شبكي مسمّى هو أن خدمات Postfix تعمل تحت جذر مختلف (chrooted) غالباً ولا يمكنها الوصول للمجلد الذي يحوي المقبس المسمّى. يمكنك أيضاً أن تختار استخدام مقبس مسمّى لكن مع اختيار موقع ضمن الجذر المغيّر إليه (وهو /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 أيضاً رابطاً رمزياً يشير إلى قاعدة البيانات التي يستخدمها Postfix، باستخدام الأمر ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

نحتاج الآن إعداد Postfix بحيث يستخدم SASL. أولاً يجب إضافة المستخدم 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 البعيد. في تلك الحالة، يصبح مخدم Posfix المحلي نفسه عميلاً يجري عملية المصادقة باستخدام 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، يجب تحويل هذا الملف إلى /etc/postfix/sasl_passwd.db باستخدام الأمر postmap.