Product SiteDocumentation Site

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

11.1. مخدم البريد الإلكتروني
11.1.1. تثبيت Postfix
11.1.2. إعداد النطاقات الظاهرية
11.1.3. قيود الاستقبال والإرسال
11.1.4. إعداد القوائم الرمادية
11.1.5. تخصيص المرشحات حسب المستقبل
11.1.6. التكامل مع مضاد فيروسات
11.1.7. Fighting Spam with SPF, DKIM and DMARC
11.1.8. SMTP مع مصادقة
11.2. مخدم الوب (HTTP)
11.2.1. تثبيت أباتشي
11.2.2. Adding support for SSL
11.2.3. إعداد مضيف ظاهري
11.2.4. التعليمات التوجيهية الشائعة
11.2.5. محللات السجلات
11.3. مخدم الملفات FTP
11.4. مخدم الملفات NFS
11.4.1. تأمين NFS
11.4.2. مخدم NFS
11.4.3. عميل NFS
11.5. إعداد مشاركات ويندوز باستخدام سامبا
11.5.1. مخدم سامبا
11.5.2. عميل سامبا
11.6. بروكسي HTTP/FTP
11.6.1. التثبيت
11.6.2. إعداد خدمة التخبئة
11.6.3. إعداد خدمة الترشيح
11.7. دليل LDAP
11.7.1. التثبيت
11.7.2. تعبئة الدليل
11.7.3. إدارة الحسابات باستخدام LDAP
11.8. خدمات التواصل في الزمن الحقيقي
11.8.1. إعدادات DNS لخدمات RTC
11.8.2. مخدم TURN
11.8.3. مخدم بروكسي SIP
11.8.4. مخدم XMPP
11.8.5. تشغيل الخدمات على المنفذ 443
11.8.6. إضافة WebRTC
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 كمخدم للبريد الإلكتروني، وذلك لموثوقيته وسهولة إعداده. وفعلاً، يفرض تصميمه استخدام عملية منفصلة تتمتع مجموعة صغيرة من الصلاحيات لكل واحدة من مهماته، وهذا إجراء ممتاز للحد من ضرر المشاكل الأمنية.

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 ديناميكية، لأن العديد من مخدمات البريد الإلكتروني ترفض الرسائل الواردة من هذه العناوين. في هذه الحالة، سيكون المضيف الذكي عادة مخدم SMTP تابع لمزود خدمة الإنترنت، ويكون مُعدّاً بحيث يستقبل دوماً البريد الوارد من زبائن المزود وتوجيهها بشكل مناسب. هذا الإعداد (مع المضيف الذكي) يناسب أيضاً المخدمات التي لا تتصل بالإنترنت دائماً، حتى تتفادى إدارة رتل من الرسائل غير المسلّمة التي يجب إعادة محاولة إرسالها لاحقاً.
يهتم السؤال الثاني بالاسم الكامل للجهاز، الذي سيستخدم لتوليد عناوين البريد الإلكتروني اعتماداً على اسم المستخدم المحلي (هذا هو الجزء الذي يوضع خلف علامة ”@“). في حالة فلكوت، يجب أن تكون الإجابة mail.falcot.com. هذا هو السؤال الوحيد الذي يطرح افتراضياً، لكن الإعداد الناتج ليس كاملاً كفاية بالنسبة لحاجات فلكوت، لذلك استدعى مديرو النظم الأمر dpkg-reconfigure postfix حتى يتمكنوا من تخصيص المزيد من المتغيرات.
أحد الأسئلة الإضافية يطلب جميع أسماء النطاقات المرتبطة بهذا الجهاز. تتضمن القائمة الافتراضية الاسم الكامل بالإضافة لبضعة مرادفات للاسم localhost. لكن يجب إضافة النطاق الرئيسي falcot.com يدوياً. بصورة عامة، يجب إجابة هذا السؤال بإعطاءه جميع أسماء النطاقات التي سيعمل هذا المخدم معها كمخدم MX؛ بكلمات أخرى، جميع أسماء النطاقات التي يبين مخدم DNS أنها تستطيع استقبال البريد الإلكتروني. ينتهي المطاف بهذه المعلومات في المتغير mydestination في الملف /etc/postfix/main.cf (ملف الإعداد الرئيسي لمخدم Postfix).
دور السجل MX (سجل DNS) أثناء إرسال البريد

شكل 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_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

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
myorigin = /etc/mailname
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
inet_protocols = all

11.1.2. إعداد النطاقات الظاهرية

يستطيع مخدم البريد استقبال الرسائل الإلكترونية المرسلة إلى نطاقات أخرى بالإضافة إلى النطاق الرئيسي؛ تُعرَف هذه النطاقات باسم النطاقات الظاهرية (Virtual Domains). في معظم الحالات التي يحدث فيها هذا، لا تكون الرسائل موجهة في النهاية إلى المستخدمين المحليين. يُقدِّم Postfix ميزتين تفيدان في إدارة النطاقات الظاهرية.

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.

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.
تسمح التعليمة الثالثة لمدير النظام بإعداد قائمة سوداء وقائمة بيضاء لمخدمات البريد الإلكتروني، تُخزَّن في الملف /etc/postfix/access_clientip. تعتبر المخدمات في القائمة البيضاء موثوقة، وبالتالي لا تمر الرسائل الواردة منها عبر قواعد الترشيح التالية.
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.

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 too many 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. القبول أو الرفض اعتماداً على المرسِل المُعلَن

لكل رسالة هناك مرسل، يُعلِن عنه الأمر 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 بعض المعاملات الخاصة ببعض المرسلين. هذا يعني إضافة بعض المرسلين إلى قائمة بيضاء أو سوداء عادة.
تتطلب القاعدة reject_unknown_sender_domain أن يكون نطاق المرسل سليماً، لأنه لازم للعناوين الصحيحة. ترفض القاعدة reject_unlisted_sender المرسلين المحليين إذا لم يكن العنوان موجوداً؛ هذا يمنع إرسال الرسائل الإلكنرونية من عنوان غير صحيح في النطاق falcot.com، ولن تُقبَل الرسائل المنبعثة من joe.bloggs@falcot.com مثلاً إلا إذا كان هذا العنوان موجوداً فعلاً.
أخيراً، ترفض القاعدة 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. القبول أو الرفض اعتماداً على المستقبل

لكل رسالة مستقبل واحد على الأقل، يعلن عنه الأمر 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
يتحقق الأول من الترويسة التي تذكر برنامج البريد الإلكتروني؛ فإذا وجدت العبارة GOTO Sarbacane (برنامج لإرسال البريد بالكميات)، سوف ترفض الرسالة. يتحكم التعبير الثاني بموضوع الرسالة؛ فإذا كان يذكر تحذيراً من فيروس، يمكننا ألا نرفض الرسالة ولكن نحذفها مباشرة بدلاً من ذلك.
استخدام هذه المرشحات سيف ذو حدين، لأنه يسهل بناء قواعد عامة جداً وخسارة رسائل مشروعة نتيجة لذلك. في هذه الحالات، لن نخسر الرسائل وحسب، بل سيحصل مرسلوا هذه الرسائل على رسائل أخطاء غير مرغوبة (ومزعجة غالباً).

11.1.4. إعداد القوائم الرمادية

“القوائم الرمادية“ (Greylisting) هي تقنية ترشيح تعتمد على رفض الرسالة في البداية مع الرد برمز خطأ مؤقت، وقبولها إذا أعيدت محاولة إرسالها ثانية بعد بعض الوقت. هذه التقنية فعالة خصوصاً لترشيح الرسائل الدعائية التي ترسلها العديد من الجهزة المصابة بالديدان والفيروسات، لأن هذه البرمجيات نادراً ما تتصرف كعميل SMTP كامل؛ فهي لا تتحقق من رمز الخطأ وتحاول إعادة إرسال الرسائل التي فشل إرسالها لاحقاً، خصوصاً وأن معظم العناوين المحصودة غير صحيحة أصلاً وإعادة محاولة الإرسال لا تعني إلا خسارة الوقت.
لا يدعم Postfix القوائم الرمادية داخلياً، لكن هناك ميزة تسمح بتوكيل برنامج خارجي لاتخاذ قرار قبول أو رفض رسالة معينة. هناك برنامج كهذا في الحزمة postgrey، مصمم ليرتبط مع خدمة توكيل سياسة القبول.
بعد تثبيت postgrey، سوف يعمل كخدمة وينصت للمنفذ 10023. يمكن عندها ضبط Postfix لاستخدامه، بإضافة المتغير check_policy_service كقيد إضافي:
smtpd_recipient_restrictions =
    permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023
في كل مرة يصل فيها Postfix لهذه القاعدة، سيتصل بخدمة postgrey ويرسل لها معلومات تخص الرسالة المعنية. ينظر Postgrey بدوره إلى ثلاثية (عنوان IP، المرسل، المستقبل) ويتحقق من رؤيته لهذه الثلاثية نفسها مؤخراً عبر قاعدة بياناته. إذا حدث ذلك، يرد Postgrey بأن الرسالة يجب أن تُقبَل؛ وإلا فإنه يرد بأن الرسالة يجب رفضها مؤقتاً، وتُسجَّل الثلاثية في قاعدة البيانات.
السيئة الرئيسية للقوائم الرمادية هي تأخر استلام الرسائل المشروعة، وهذا غير مقبول دائماً. كما يزيد العبئ على المخدمات التي ترسل الكثير من الرسائل المشروعة.

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. التكامل مع مضاد فيروسات

الفيروسات العديدة التي تتجوّل كمرفقات بريدية تضطرنا لإعداد مضاد فيروسات عند نقطة الدخول إلى شبكة الشركة، لأن بعض المستخدمين سيفتحون الملفات المرفقة مع الرسائل التي تبدو مشبوهة بشكل واضح، رغم حملات التوعية.
اختار مديرو النظم في شركة فلكوت clamav كمضاد فيروسات مجاني. الحزمة الرئيسية هي clamav، لكنهم ثبّتوا أيضاً حزماً إضافية مثل arj، وunzoo، وunrar وlha، لأن مضاد الفيروسات يحتاجها حتى يتمكن من تحليل المرفقات المضغوطة بإحدى هذه الصيغ.
يتولى 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“.
تناسب إعدادات 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.
ستمر جميع الرسائل التي يعالجها 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.

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:
The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to email 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.
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:
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, which contain your domain as sending host, fail to validate using DKIM and SPF.
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:dmarc_y_rua@yahoo.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:
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.