Product SiteDocumentation Site

فصل 11. Network Services: 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. SMTP مع مصادقة
11.2. مخدم الوب (HTTP)
11.2.1. تثبيت أباتشي
11.2.2. إعداد مضيف ظاهري
11.2.3. التعليمات التوجيهية الشائعة
11.2.4. محللات السجلات
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. Real-Time Communication Services
11.8.1. DNS settings for RTC services
11.8.2. TURN Server
11.8.3. SIP Proxy Server
11.8.4. XMPP Server
11.8.5. Running services on port 443
11.8.6. Adding 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.
Many modern network services require encryption technology to operate reliably and securely, especially when used on the public Internet. X.509 Certificates (which may also be referred to as SSL Certificates or TLS Certificates) are frequently used for this purpose. A certificate for a specific domain can often be shared between more than one of the services discussed in this chapter.

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

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

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).
دور السجل MX (سجل DNS) أثناء إرسال البريد

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

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

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

# 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_command = procmail -a "$EXTENSION"
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.

مثال 11.2. السطور التي ستضاف إلى الملف /etc/postfix/main.cf

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual
The /etc/postfix/virtual file describes a mapping with a rather straightforward syntax: each line contains two fields separated by whitespace; the first field is the alias name, the second field is a list of email addresses where it redirects. The special @domain.com syntax covers all remaining aliases in a domain.

مثال 11.3. مثال عن ملف /etc/postfix/virtual

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

11.1.2.2. نطاقات صناديق البريد الظاهرية

تُخزَّن الرسائل المرسلة إلى نطاقات صناديق البريد الظاهرية في صناديق بريدية غير مرتبطة بأي مستخدم محلي للنظام.
لتفعيل نطاق صناديق بريد ظاهري يجب إضافة اسم هذا النطاق إلى المتغير virtual_mailbox_domains، والإشارة إلى ملف تقابل الصناديق البريدية في المتغير virtual_mailbox_maps. أما المتغير virtual_mailbox_base فيحوي المجلد الذي تخزن الصناديق البريدية فيه.
يشير المتغير virtual_uid_maps (أو المتغير virtual_gid_maps) إلى الملف الذي يحوي التقابلات بين العنوان البريدي ومستخدم النظام (أو المجموعة) الذي ”يملك“ هذا الصندوق البريدي. لمنح ملكية جميع الصناديق البريدية إلى مستخدم واحد أو مجموعة، يمكن استخدام الصيغة static:5000 التي تسند قيمة UID/GID ثابتة (القيمة 5000 هنا).

مثال 11.4. السطور التي ستضاف إلى الملف /etc/postfix/main.cf

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts
صيغة الملف /etc/postfix/vmailbox بسيطة جداً أيضاً: حقلين تفصلهما مسافة بيضاء. الحقل الأول هو عنوان بريد إلكتروني ضمن أحد النطاقات الظاهرية، والثاني موقع صندوق البريد المرتبط معه (نسبةً إلى المجلد المحدّد في virtual_mailbox_base). إذا انتهى اسم صندوق البريد بشرطة مائلة امامية (/)، ستخزّن الرسائل الإلكترونية في صيغة maildir؛ وإلا سوف تستخدم صيغة mbox التقليدية بدلاً منها. تَستخدِم صيغة maildir مجلداً كاملاً لتخزين صندوق البريد، وكل رسالة مفردة تُخزَّن في ملف منفصل. أما في صيغة mbox، فيخزن صندوق البريد كله في ملف واحد، وكل سطر يبدأ بالصيغة ”From “ (كلمة From تليها مسافة) تشير إلى بداية رسالة جديدة.

مثال 11.5. الملف /etc/postfix/vmailbox

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

11.1.3.1. تقييد الوصول حسب عناوين IP

يتحكم المتغير smtpd_client_restrictions بالأجهزة التي يسمح لها بالتواصل مع مخدم البريد الإلكتروني.

مثال 11.6. القيود المفروضة اعتماداً على عنوان العميل

smtpd_client_restrictions = permit_mynetworks,
    warn_if_reject reject_unknown_client,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client list.dsbl.org
عندما يحوي المتغير مجموعة من القواعد، كما في المثال أعلاه، تقيّم هذه القواعد بالترتيب، من الأولى حتى الأخيرة. كل قاعدة إما أن تقبل الرسالة، أو ترفضها، أو تترك القرار للقاعدة التالية. ولذلك فالترتيب مهم، ومجرد التبديل بين قاعدتين قد يؤدي لتغيير كبير في السلوك.
تقبل التعليمة التوجيهية permit_mynetworks المستخدمة كقاعدة أولى كل الرسائل الإلكترونية التي ترد من جهاز من الشبكة المحلية (المحددة في متغير الإعداد mynetworks).
أما التعليمة التوجيهية الثانية فترفض في الحالة الطبيعية الرسائل التي ترد من الأجهزة التي لا تملك إعدادات DNS صحيحة بالكامل. هذه الإعدادات الصحيحة بالكامل تعني أن استبيان عنوان IP يعطي اسماً، وأن استبيان الاسم يعطي بدوره عنوان IP نفسه. هذا القيد صارم جداً غالباً، لأن معظم مخدمات البريد الإلكتروني لا تملك DNS عكسي لعناوين IP الخاصة بها. ولهذا السبب سبق مديرو النظم في فلكوت التعليمة reject_unknown_client بالخيار warn_if_reject: يؤدي هذا الخيار لاستبدال عملية الرفض بتحذير بسيط يُسجَّل في السجلات. يستطيع بعدها مديرو النظم متابعة عدد الرسائل التي كانت سترفض لو كانت القاعدة نشطة فعلاً، واتخاذ قرار لاحق بعد حسن اطلاع لتفعيل هذا القيد أو عدم تفعيله.
The third 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 two rules reject any message coming from a server listed in one of the indicated blacklists. RBL is an acronym for Remote Black List; there are several such lists, but they all list 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

كل عملية تبادل SMTP تبدأ بأمر HELO (أو EHLO)، يتبعه اسم مخدم البريد المرسل؛ قد يكون التحقق من سلامة هذا الاسم مفيداً.

مثال 11.7. القيود المفروضة على الاسم المُعلَن في EHLO

smtpd_helo_restrictions = permit_mynetworks,
    reject_invalid_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_non_fqdn_hostname,
    warn_if_reject reject_unknown_hostname
تسمح التعليمة التوجيهية permit_mynetworks لجميع الأجهزة في الشبكة المحلية بتقديم نفسها كيفما اتفق. هذه مهم، لأن بعض برامج البريد الإلكتروني لا تحترم هذا الجزء من بروتوكول SMTP بشكل كاف، ويمكن أن تقدم نفسها بأسماء غير منطقية.
ترفض القاعدة reject_invalid_hostname الرسائل الإلكترونية عندما يعلن EHLO اسم مضيف صيغته غير صحيحة. وترفض القاعدة reject_non_fqdn_hostname الرسائل عندما لا يكون اسم المضيف المذكور اسم نطاق كامل التوصيف (fully-qualified، أي يتضمن اسم النطاق بالإضافة لاسم المضيف). ترفض القاعدة reject_unknown_hostname الرسائل إذا لم يكن الاسم المعلن مذكوراً في DNS. بما أن هذه القاعدة الأخيرة تؤدي لعمليات رفض كثيرة جداً لسوء الحظ، فقد حوّل مديرو النظم تأثيرها إلى مجرد تحذير باستخدام الخيار warn_if_reject كخطوة أولى؛ وقد يقررون إزالة هذا الخيار في مرحلة لاحقة، بعد فحص نتائج هذه القاعدة.
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, 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.8. التحقق من المرسل

smtpd_sender_restrictions = 
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain, reject_unlisted_sender,
    reject_non_fqdn_sender
يربط الجدول /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.

11.1.3.4. القبول أو الرفض اعتماداً على المستقبل

لكل رسالة مستقبل واحد على الأقل، يعلن عنه الأمر RCPT TO في بروتوكول SMTP. يضمن التحقق من هذه العناوين أيضاً شرعية الرسالة، حتى لو كانت أقل أهمية من التحقق من عنوان المرسل.

مثال 11.9. التحقق من المستقبل

smtpd_recipient_restrictions = permit_mynetworks, 
    reject_unauth_destination, reject_unlisted_recipient, 
    reject_non_fqdn_recipient
reject_unauth_destination is the basic rule that requires outside messages to be addressed to us; messages sent to an address not served by this server are rejected. Without this rule, a server becomes an open relay that allows spammers to send unsolicited emails; this rule is therefore mandatory, and it will be best included near the beginning of the list, so that no other rules may authorize the message before its destination has been checked.
ترفض القاعدة reject_unlisted_recipient الرسائل المرسلة إلى مستخدمين محليين لا وجود لهم، وهذا منطقي. أخيراً، ترفض القاعدة reject_non_fqdn_recipient العناوين ذات التوصيف غير الكامل؛ هذا يمنع إرسال رسالة إلى jean أو jean@machine، بل يجب استخدام العنوان الكامل بدلاً من ذلك، مثل jean@machine.falcot.com أو jean@falcot.com.

11.1.3.5. القيود المتعلقة بالأمر DATA

يُرسَل الأمر DATA التابع لبروتوكول SMTP قبل إرسال محتويات الرسالة. لا يقدّم هذا الأمر أي معلومات بحد ذاته، فيما عدا الإعلان عما سيرد تالياً. لكن لا يزال إخضاعه للفحوصات ممكناً.

مثال 11.10. التحقق من DATA

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

11.1.3.6. تطبيق القيود

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

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

The validation and restriction system would not be complete without a way to apply checks to the message contents. Postfix differentiates the checks applying to the email headers from those applying to the email body.

مثال 11.11. تفعيل المرشحات التي تعتمد على المحتوى

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks
يحوي كل ملف قائمة من التعابير المنتظمة (تعرف عادة باسم regexps أو regexes) والإجراءات المرتبطة معها التي تنشط عند مطابقة ترويسات الرسالة (أو متنها) للتعبير المنتظم:

مثال 11.12. مثال عن ملف /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” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted on a further try after 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
في كل مرة يصل فيها Postfix لهذه القاعدة، سيتصل بخدمة postgrey ويرسل لها معلومات تخص الرسالة المعنية. ينظر Postgrey بدوره إلى ثلاثية (عنوان IP، المرسل، المستقبل) ويتحقق من رؤيته لهذه الثلاثية نفسها مؤخراً عبر قاعدة بياناته. إذا حدث ذلك، يرد Postgrey بأن الرسالة يجب أن تُقبَل؛ وإلا فإنه يرد بأن الرسالة يجب رفضها مؤقتاً، وتُسجَّل الثلاثية في قاعدة البيانات.
السيئة الرئيسية للقوائم الرمادية هي تأخر استلام الرسائل المشروعة، وهذا غير مقبول دائماً. كما يزيد العبئ على المخدمات التي ترسل الكثير من الرسائل المشروعة.

11.1.5. تخصيص المرشحات حسب المستقبل

قسم 11.1.3, “قيود الاستقبال والإرسال” and قسم 11.1.4, “إعداد القوائم الرمادية reviewed many of the possible restrictions. They all have their use in limiting the amount of received spam, but they also all have their drawbacks. It is therefore more and more common to customize the set of filters depending on the recipient. At Falcot Corp, greylisting is interesting for most users, but it hinders the work of some users who need low latency in their emails (such as the technical support service). Similarly, the commercial service sometimes has problems receiving emails from some Asian providers who may be listed in blacklists; this service asked for a non-filtered address so as to be able to correspond.
يقدم Postfix ميزة تخصيص للمرشحات عبر مفهوم ”فئات التقييد restriction class“. يصرح عن الفئات في المتغير smtpd_restriction_classes، وتُعرَّف بنفس أسلوب smtpd_recipient_restrictions. بعدها تحدد التعليمة check_recipient_access جدولاً يقابل بين المستقبل المحدد ومجموعة القيود المناسبة.

مثال 11.13. تعريف فئات التقييد في 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.14. الملف /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 service postfix reload should be run so that this change is taken into account.
ستمر جميع الرسائل التي يعالجها Postfix الآن عبر مرشح مكافحة الفيروسات.

11.1.7. SMTP مع مصادقة

Being able to send emails requires an SMTP server to be reachable; it also requires said SMTP server to send emails through it. For roaming users, this may need regularly changing the configuration of the SMTP client, since Falcot's SMTP server rejects messages coming from IP addresses apparently not belonging to the company. Two solutions exist: either the roaming user installs an SMTP server on their computer, or they still use the company server with some means of authenticating as an employee. The former solution is not recommended since the computer won't be permanently connected, and it won't be able to retry sending messages in case of problems; we will focus on the latter solution.
تعتمد مصادقة 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.15. تفعيل 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_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
[...]