Работа с сервером для начинающих

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

участников являются сотрудниками ИТ-компаний

20% из них — совладельцы бизнеса

работают в ИТ-службах других компаний

Войти с помощью:

Авторизация

Новым пользователям

Зачем?

У вас есть вакансия системного администратора или быть может вы сами планируете занять такую вакансию? Какой минимальный набор знаний нужен человеку претендующему на эту позицию? Безусловно это хотя бы минимальные познания в пользовательских и операционных системах, представление о том, как работают сети, некоторые познания в ИТ-безопасности, а также умение решать массу повседневных задач пользователей. Вот далеко не исчерпывающий список того, что должен знать каждый начинающий системный администратор.

Добавление компьютеров в домен. Если вы можете добавить компьютер в рабочую группу, вы должны знать, как включить компьютер с Windows в домен. Это обязательный навык. Наряду с этим, вы должны знать, как кэшировать учетные данные на компьютере. Особенно это актуально для ноутбуков.

Устранение проблем печати. Принтеры — это настоящее проклятье. Даже если все правильно настроить, с печатью постоянно возникают проблемы. Вы должны знать способы устранения проблем локальной и сетевой печати, а также мочь удалить принтер из реестра Windows в случае серьезных проблем с компьютером.

Загрузка в безопасном режиме. Бывают ситуации, когда нужно загрузить компьютер в безопасном режиме. Если вы этого не умеете, вам не место в ИТ-отделе. Вы должны знать, как загрузиться в безопасном режиме с поддержкой сети, чтобы устранить неполадки компьютера, которые нельзя исправить в обычном режиме.

Установка операционной системы. Это еще один немаловажный навык системного администратора. Вы как минимум должны знать, как установить Windows 7/8, Windows Server, Linux и Mac OS. Также следует знать, как установить несколько операционных систем на один компьютер и настроить их загрузку.

Управление пользователями в Active Directory. Вам предстоит постоянно работать со службой Active Directory — добавлять, удалять, редактировать, блокировать и разблокировать профили пользователей или просто сбрасывать пароли. Если вы не сможете настроить Active Directory, работать с сетью будет очень тяжело.

Сброс пароля на сервере. Это не всегда просто. Бывают случаи, когда нужно изменить пароль администратора на компьютере, не входящем в домен Active Directory (и знать, как это может повлиять на такие вещи, как резервное копирование Acronis). Вы также должны знать, как сбросить пароль на компьютере с Linux или Mac OS.

Создание и настройка профилей в Outlook. Иногда единственный способ решить проблему с Outlook — это удаление профиль. На компьютерах с Windows, это довольно распространенное явление, поэтому вы должны знать, как удалять и создавать профили в Outlook.

Запуск CHKDSK. Оборудование ломается. В какой-то момент вам может потребоваться проверить жесткий диск на ошибки файловой системы. Для этого вы должны знать, как запустить CHKDSK при загрузке, в том числе и с автоматическим исправлением ошибок.

Резервное копирование Windows Server. Даже используя стороннее ПО для резервного копирования, все равно приходится пользоваться инструментом для очистки журнала сообщений Exchange. Вы должны знать, как запустить резервное копирование Windows Server и как настроить его в планировщике заданий.

Очистка пространства на диске C. Если диск С переполнен — жди неприятностей, особенно на сервере. Диск С нужно периодически очищать. Для этого есть что различные инструменты, таике как CCleaner, который удаляет временные файлы, или WinDirStat, который показывает, какие файлы занимают драгоценное дисковое пространство.

ИТ-специалисту приходится решать огромное количество задач, поэтому начинающему системному администратору нужно твердо знать хотя бы вышеперечисленное.

Разбираемся с тем, как стать системным администратором, и выполняя реальные задачи, получаем основные знания для работы и развития.

Статья-туториал, к которой нужно отнестись с полной серьёзностью и не приступать к её прочтению, пока вы не поймёте, стоит ли становиться системным администратором и сможете ли вы.

Как правило, системный администратор отвечает за технические вещи в организациях. Например, системные администраторы отвечают за то, что интернет-соединение в офисе работает, и что почтовый сервер в порядке, контролирует работу сетей, постоянно поддерживая их аппаратное и программное обеспечение, устанавливая обновления и многое другое, всё зависит от специализации.

Специализации

1. Универсальный сисадмин

Такой человек занимается операционными системами (Linux, Windows Server, Sun Solaris, BSD и др.) и их службами.

2. Сисадмин с узкой специализацией

Сюда можно отнести и тех кто работает с базами данных, кластерами, сетями, и тех, кто работает с чем-то другим. Главное отличие от других сисадминов — работа над конкретными узкопрофильными задачами. Этим обычно занимаются бывшие универсалы, которые выросли и хотят заниматься чем-то конкретным. Кстати, зачастую, зарплаты выше, но могут возникнуть сложности, если у вас совсем уж узкая специализация.

3. Build/Release инженер/Configuration manager

Некогда сисадмины, которые перешли к работе с IDE и серверами. В их обязанности входит статический анализ, модульное тестирование, компиляция, тестирование, работа с репозиториями, настройка сервера. Это самые узкопрофильные специалисты, которые стоят много денег и всегда пользуются спросом.

В статье рассмотрена именно первая специализация, как первоначальная ступень начинающего сисадмина. Как известно, большинство важных компаний работают с системами Linux. На это есть свои причины, связанные ограничениями в скорости, нагрузке, прозрачности. Так что, всё, что написано ниже, про Linux.

Всего существует три вида Linux: Debian, RHEL, Slackware. Всё остальное произошло от них же. Есть мнение, что лучше всего начинать с Debian, мы так и сделаем. Ещё один важный момент: можете закрыть эту статью, пока не дотянете английский до минимального уровня, просто потому что вы будете никому не нужны.

Далее, в процессе чтения этой статьи вы будете получать задания, которые нужно последовательно выполнять. Ну и таким образом знакомиться с тем, как и что работает.

Оговорка: не пытайтесь нигде поставить русский, потом могут быть проблемы.

Задание №1

• Скачиваем или покупаем программу VMware Workstation
• Устанавливаем на Windows
• Пока идёт процесс, знакомимся с тем, что такое виртуальная и хост-машина

Задание №2

• Скачиваем дистрибутив Windows
• Создаём гостевую машину
• Запускаем виртуальную машину
• Устанавливаем на неё Windows

Задание №3

• Выключаем виртуальную машину
• Экспортируем её в .OVA образ
• На его основе создаём ещё одну виртуальную машину
• Запускаем обе

Задание №4

• Пингуем адрес 127.0.0.1
• Запускаем на двух виртуальных и хост-машине cmd
• Узнаём их адреса
• Настраиваем сетевые интерфейсы виртуальных машин и конфигуратора сетей VMware, чтобы хост-машина могла пинговать виртуальные машины, а каждая из них могла пинговать другую
• Проверяем, что всё работает

Задание №5

• Загружаем Debian
• Устанавливаем её на первой виртуальной машине
• На этапе разметки диска делаем автоматическую
• На этапе выбора сервисов выбираем только базовые утилиты и SSH-сервера, когда спросит, устанавливаем загрузчик Grub

Задание №6

• Когда появится чёрный экран, набираем логин root и пароль, указанный при установке (мы не увидим, как набираем символы)
• Переходим в директорию /var
• С помощью команды узнаём, в какой директории находимся
• Читаем мануал по команде ls (только основное положение и про флаги -l, -t, -r, -A)
• Отображаем список директорий и файлов
• Переходим в директорию /var/log (без упоминания “var” в команде
• Переходим в директорию /var (снова без упоминания “var”)
• Создаём директорию /tmp/lesson/
• Переходим туда, задав абсолютный путь
• Создаём здесь файл с названием hello.txt и ставим права на файл “0777”
• Пингуем внешний адрес 8.8.8.8

Если последнее действие не получается, значит где-то накосячили, ищем ошибку сами или гуглим.

Задание №7

• Загружаем, устанавливаем и запускаем программу Putty
• Смотрим адрес виртуальной машины
• В программе подключаемся по SSH на нужный IP и далее работаем с системой только через SSH

Задание №8

• Отображаем содержимое /etc/apt/sources.list, используя команду cat
• С её же помощью и символа “>” записываем в файл следующие данные:

## Debian Jessie base:
deb http://ftp.debian.org/debian/ jessie main contrib non-free
#deb-src http://ftp.debian.org/debian/ jessie main contrib non-free

## Debian Jessie security updates:
deb http://security.debian.org/ jessie/updates main contrib non-free
#deb-src http://security.debian.org/ jessie/updates main contrib non-free

# Debian Jessie updates:
deb http://ftp.debian.org/debian/ jessie-updates main contrib non-free
#deb-src http://ftp.debian.org/debian/ jessie-updates main contrib non-free

• Обновляем кэш менеджера пакетов apt-get
• С помощью этой команды устанавливаем пакет vim

Задание №9

• Читаем про vi или vim
• Открываем на редактирование /tmp/lesson/hello.txt с помощью vi
• Печатаем любой текст на 40-50 строк (нужно, чтобы в каждой строке были буквы “abc” в такой же последовательности)
• Сохраняем и выходим
• Отображаем содержимое с помощью cat, затем less
• Отображаем только последние 10 строк, затем первые 7 строк
• Считаем количество строк в файле

Задание №10

• Узнаём, что такое конвейер и “pipe”
• Отображаем содержимое /tmp/lesson/hello.txt и перенаправляем результат по конвейеру в подсчёт строк
• Отображаем содержимое /tmp/lesson/hello.txt и перенаправляем результат по конвейеру в grep
• Отправляем дальше по конвейеру в подсчёт строк
• Отображаем содержимое /tmp/lesson/hello.txt и вывод перенаправляем в grep

Задание №11

• Читаем мануал по shutdown
• С её помощью выключаем виртуальную машину

Задание №12

• Склонируем диск первой виртуальной машины на вторую
• Запускаем вторую
• Входим с логином root
• Меняем название, чтобы знать, что это вторая виртуальная машина
• С помощью shutdown перезагружаем сервер

Задание №13

• Запускаем первый сервер (второй уже запущен, должно быть)
• Смотрим через консоль IP (должны отличаться)
• Читаем про IPv4 и маску подсети
• Знакомимся с DHCP
• Вписываем IP в конфигурационный файл сети на обеих виртуальных машинах (IP+маска+шлюз)
• Перезагружаем обе машины
• Проверяем, что с хост-машины пингуются виртуальные
• Сохраняем настройки сессий в putty для обеих виртуальных машин
• Выключаем вторую виртуальную машину (второй сервер)

Фух, теперь про повседневные задачи сисадмина.

Задание №14

• Запускаем командную строку
• Создаём переменную и присваиваем любое значение
• Отображаем её
• Проверяем, что переменная сохраняет своё значение после рестарта с помощью echo $a
• Отображаем переменную $PATH
• Разбираемся с тем как она работает
• Делаем так, чтобы добавился ещё один путь — /tmp

Задание №15

• Разбираемся с BASH и sha-bang
• Пишем пустой скрипт с расширением .sh и запускаем его
• Делаем так, чтобы скрипт можно было запускать без указания пути

Задание №16

• Делаем так, чтобы скрипт инициализировал DATE и задавал значение времени, затем выводил на экран
• Делаем так, чтобы вместо вывода на экран создавался файл в директории подобный /tmp/2017-08-17.txt
• Делаем так, чтобы в файл записывалось время создания

Задание №17

• Используя CRON заставляем скрипт исполняться ежеминутно
• Через 10 минут проверяем, чтобы в директории было столько же файлов, сколько прошло минут
• Обнаруживаем ошибку
• Используя find делаем так, чтобы директория проверялась раз в 10 минут и удаляла файлы, созданные больше, чем 17 минут назад

Задание №18

• Создаём пустой файл и вписываем что-нибудь
• Копируем с сохранением всех прав в другой файл с любым названием и содержимым
• Сравниваем контрольные суммы
• Меняем содержимое любого из файлов и смотрим разницу в контрольных суммах

Задание №19

• Создаём пользователя и задаём ему пароль
• Разбираемся с /etc/passwd, /etc/shaddow, /etc/group
• Делаем так, чтобы, если нет файла /tmp/passwd.backup, /etc/passwd копировался в /tmp/passwd.backup, а если /tmp/passwd.backup есть, то сравнивался с /etc/passwd
• Если различаются, то пусть копируется, если нет, пусть завершает работу скрипта

Задание №20

• Используя apt-get устанавливаем Apache2 на виртуальную машину
• С браузера хост-машины по IP-адресу виртуальной машины видим приветствие
• Меняем порт на :8080
• Снова выполняем то, что делали два шага назад, но с указанием порта
• Меняем порт обратно и проверяем как работает заглушка
• В hosts хост-машины создаём три домена: a1.com, b2.com, c3.com и связываем с IP виртуальной машины с Apache
• Для каждого домена проверяем всё ли правильно, с помощью ping
• Заходим на все три домена, написав их вместо IP виртуальной машины

Задание №21

• Создаём директории /var/www/a1.com, /var/www/b2.com, /var/www/c3.com
• В каждой из них создаём пустой index.html
• В каждом что-нибудь пишем
• Делаем так, чтобы открывался личный сайт из директории, а не общая заглушка

Задание №22

• Меняем index.html на index.php и добавляем следующую запись:

• Видим ошибку
• Через apt-get активируем mod_php
• Создаём инструкцию для Apache, чтобы все php файлы обрабатывались этим модулем
• Настраиваем такие же модули с инструкциями для Perl и Python
• b2.com и c3.com переводим на index.pl и index.py
• Создаём приветствия

Задание №23

• Читаем про HTML Basic вот здесь
• Про PHP Basic здесь

Задание №24

• Устанавливаем mysql-server
• С помощью mysql подключаемся через командную строку к серверу
• Создаём базу данных mydatabase и пользователя myuser
• Читаем раздел SQL Basic здесь
• Устанавливаем Joomla на a1.com
• WordPress на b2.com

Задание №25

• Читаем про реверс-прокси
• Устанавливаем Nginx
• Делаем так, чтобы 8080 порт Apache получал запросы 80 порта Nginx
• Проверяем a1.com, Nginx access.log должен пополняться при обращении к сайту
• Делаем, чтобы Nginx всё, кроме jpg и png файлов передавал Apache

Задание №26

• Включаем второй сервер
• Собираем MySQL Cluster на двух серверах
• Создаём базу данных с простыми таблицами, заполненными рандомными данными для тестирования
• Вносим изменения на один из серверов и проверяем на другом
• Выключаем второй сервер
• Рушим файлы базы вручную (всё для проверки)
• Делаем так, чтобы база восстановилась и появилась в кластере (думайте, как)

Задание №27

• Выключаем оба сервера
• Добавляем каждому серверу по одному диску на 700 Мб
• Включаем обратно
• С помощью fdisk проверяем, как обозначены диски
• С помощью DRBD соединяем диски серверов, чтобы изменения отображались на обоих (оба должны быть смонтированы в /mnt/drbd-disk)

Задание №28

• Выключаем первый сервер
• Добавляем ещё диски по 200 Мб
• Включаем сервер
• С помощью fdisk отображаем структуру дисков, должно быть четыре диска, из которых два не размечены
• С помощью mraid соединяем в RAID диски, с которыми не работали
• Монтируем /dev/md0 в /mnt/raid-disk

Задание №29

• Выключаем второй сервер
• Добавляем диск на 2Гб
• Включаем, настраиваем LVM и монтируем в /mnt/lvm-disk1
• Уменьшаем размер диска LVM вдвое и создаём такой же
• Монтируем в /mnt/lvm-disk1 и /mnt/lvm-disk2

Задание №30

• Ликвидируем exim4-config (если был)
• Ставим postfix
• Настраиваем пересылку почты с сервера к себе в почтовый ящик с помощью swaks

Задание №31

• Настраиваем на первом сервере в Nagios мониторинг обоих серверов
• Подключаем уведомления на свою почту (на всякий случай)
• Имитируем поломку MySQL и ждём сообщения о неисправности на почту

Задание №32

• На втором сервере поднимаем SVN-репозиторий scripts
• Делаем его доступным на любом сервере через svnserve
• На первом сервере склонируем в директорию /opt/scripts/
• На хост-машине в D:scripts

Задание №33

Так, сейчас работаем только в vi.

• На первом сервере пишем скрипт /opt/scripts/backup.sh, чтобы он: на наших сайтах запаковывал директории с файлами в tar и сжимал в gz, снимал MySQL-дамп базы сайта в формате .sql, складывал всё это в /var/backups/www/имя_сайта, проверял содержимое файлов и так со всеми, а в конце, нужно, чтобы он отправлял на почту отчёт
• Фиксируем скрипт в репозитории

Задание №34

• Обновляем SVN-репозиторий
• Копируем файл из репозитория второго сервера в D:scripts
• Устанавливаем вот это
• Через GVim добавляем рандомную строку
• Коммитим скрипт в репозиторий
• В /opt/scripts обновляемся
• Хотим увидеть изменения в скрипте

Задание №35

• Переписываем бэкап скрипт так, чтобы не нужно было перечислять существующие сайты, он должен обнаруживать их в конфигурации Apache
• Коммитим
• Переписываем бэкап скрипт так, чтобы все сообщения он писал и в консоль, и в syslog
• Коммитим
• Вносим синтаксическую ошибку в скрипт
• Коммитим с ошибкой
• Откатываем до последней рабочей версии

Задание №36

• Переписываем бэкапный скрипт так, чтобы, он определял CMS сайта и собирал данные доступа к базе
• Коммитим

Задание №37

• Настраиваем rsyslog первого сервера, чтобы логи бэкапного скрипта писались в ar/log/backup.log
• Настраиваем сбор логов на первом сервере
• Активируем LogAnalyzer здесь же

Задание №38

• Переписываем бэкап скрипт так, чтобы по завершению запускалась синхронизация директорий /var/backups/www между серверами
• Коммитим
• Повторяем, используя lftp mirror

Задание №39

• Читаем здесь и здесь

Задание №40

• Активируем puppet на втором сервере
• Отдаём ему под управление /etc/passwd

Задание №41

• Читаем про init
• Загружаемся в разные init-уровни
• Перезагружаем сервер с помощью init
• Выключаем сервер с помощью init
• Включаем обратно

Задание №42

• Пробуем восстановить пароль от root, загрузив ядро с параметром init=/bin/bash

Задание №43

• Читаем про различие аутентификации и авторизации
• Разбираемся с PAM здесь и здесь
• Разбираемся, зачем нужен файл /etc/nsswitch.conf
• Делаем авторизацию SSH в MySQL (files оставляем про запас)

Задание №44

• На bash пишем скрипт в /opt/scrpts/my_daemon.sh, чтобы он: отцеплялся от STDIN,STDOUT,STDERR, менял рабочую директорию на /, закрывал все дескрипторы, выводил количество минут до перезагрузки

Задание №45

• Создаём init-скрипт в /etc/init.d/my_daemon с LSB-тэгами
• Пробуем запустить и остановить скрипт /opt/scrpts/my_daemon.sh используя init-скрипт /etc/init.d/my_daemon
• Запускаем, останавливаем и смотрим статус скрипта, используя service
• Ставим daemon на автозагрузку

Задание №46

• Меняем скрипт с SysVinit на systemd
• Запускаем, останавливаем и смотрим статус скрипта, используя systemctl

Задание №47

• Проходим онлайн-курсы по сетям
• Знакомимся с OSI, TCP/IP, NAT и прочими штуками по теме

Задание №48

• Ставим на обычный ПК Cygwin (выбираем python, vim, git, openssh и все паке, которыми пользовались на Linux)
• Добавляем путь к бинарным файлам Cygwin в %PATH%
• Запускаем cmd, пробуем работать в нём на Windows
• Ставим что-нибудь более удобное

Задание №49

• Удаляем все виртуальные машины
• Удаляем на Windows VMware-продукты
• Ставим VirtualBox , Vagrant
• Создаём директорию C:VMserver1 и переходим к ней
• Инициализируем Debian с помощью Vagrant, запускаем его
• Открываем VirtualBox и проверяем, что создалась новая виртуальная машина
• Останавливаем и удаляем виртуальную машину
• Регулируем имя, 3 CPU, RAM 1Gb, проброс порта 22
• Запускаем её и подсоединяемся по SSH через putty

Задание №50

• На Cygwin ставим Ansible
• Включаем Vagrantfile в самом конце провиженинг Ansible
• Дополняем Ansible: apt-get: git, curl, pyenv, python3.6 при помощи pyenv, делаем python3.6 дефолтным глобально
• Устанавливаем Logbook, paramiko, lxml
• Создаём с нуля виртуальную машину

Задание №51

• Проверяем знания по тесту

Так, теперь переходим к очень важному моменту. Всегда очень круто, когда сисадмин дружит с Python. Так что если ещё не начали изучать, приступайте.

Технический блог специалистов ООО"Интерфейс"

• Главная
• Почтовый сервер для начинающих. Структура и принцип работы

Почтовый сервер для начинающих. Структура и принцип работы

• Автор: Уваров А.С.
• 26.09.2010

Многие системные администраторы испытывают определенные трудности при работе с системами электронной почты. Это неудивительно, почтовый сервер имеет гораздо более сложную структуру, чем файловый сервер, роутер или сервер терминалов. В этой статье мы рассмотрим структуру и принцип работы почтовых серверов, без понимания которых настройка системы электронной почты вполне способна превратиться в шаманские танцы с бубном.

Данный материал содержит довольно много упрощений и обобщений, с целью дать системным администраторам необходимый минимум знаний. На наш взгляд, ради администрирования одного-двух почтовых серверов начального уровня становиться специалистом в области электронной почты совсем не обязательно.

Для большинства пользователей и начинающих администраторов почтовый сервер представляет собой некий "черный ящик", который получив письмо "неведомыми" путями доставляет его адресату и наоборот. Все взаимодействие с таким сервером заключается в обращении почтового клиента к определенным портам, а то и вообще через веб-интерфейс. Однако внутри скрыт целый механизм, понимание работы которого имеет ключевое значение для успешной настройки и обслуживания системы электронной почты. Это особенно важно для администрирования серверов на платформе Linux. В отличии от Windows, где почтовый сервер представляет собой законченное программное решение и о внутреннем взаимодействии уже позаботились разработчики, в Linux компоненты почтового сервера представляют собой отдельные программы и настраивать их взаимодействие нужно самостоятельно.

Рассмотрим структуру почтового сервера, а также что происходит когда пользователь пытается отправить почту.

Важнейшей часть почтового сервера является MTA (Mail Transfer Agent — агент пересылки почты) в задачи которого входит прием и передача почты. Очень часто (в Linux / UNIX) МТА называют также почтовым сервером. MTA работает по протоколу SMTP, и его одного, в принципе, уже достаточно для создания системы электронной почты. Когда-то давно именно так и было и для доступа к своему почтовому ящику требовалось обладать определенными техническими знаниями.

Однако прогресс не стоит на месте, MTA, получая письмо, помещает его в почтовый ящик пользователя на сервере, к которому последний должен получить доступ, желательно наиболее простым и понятным способом. Вот здесь на сцену выходит MDA (Mail Delivery Agent — агент доставки почты), его задача по запросу почтового клиента передать ему почту из почтового ящика на сервере. MDA может работать по протоколам POP3 или IMAP, в ряде случаев для "общения" почтового клиента и агента доставки могут применяться собственные протоколы, обладающие расширенной функциональностью, например MAPI (Exchange Server).

Вопреки распространенному заблуждению, MDA не имеет никакого отношения к процессу передачи почты. Это прерогатива MTA. Если провести аналогию, MTA можно представить как почтовое отделение, которое занимается приемом и отправкой почты, а MDA с почтальоном, который приносит пришедшую корреспонденцию к вам домой. Если почтальон заболел, то это никак не скажется на работе почты, просто вы не получите письма на дом. Также и MDA, его отказ не приводит к неработоспособности почтового сервера, становится недоступно только получение почты почтовым клиентом, в то же время к ней можно спокойно получить доступ другими путями, например, через веб интерфейс.

Посмотрим, что происходит при отправке почты. В нашем примере пользователь Иванов, находящийся в домене example.org ([email protected]), пишет письмо Козлову в домен example.com ([email protected]). Для Иванова процесс отправки почты состоит из создания сообщения и нажатия кнопки "Отправить" в почтовом клиенте. Почтовый клиент соединяется с МТА по протоколу SMTP и первым делом сообщает свои учетные данные. Авторизовав пользователя, MTA принимает сообщение и пытается доставить его дальше.

Вообще-то авторизация не является обязательной процедурой для MTA, но без авторизации мы получим открытый релей, т.е. любой может воспользоваться нашим сервером для пересылки почты, а как спамеры обрадуются! В настоящее время открытые релеи возникают в основном из-за ошибок настройки сервера. Однако вполне допустима ситуация, когда MTA без авторизации принимает почту от доверенных пользователей, например из локальной сети предприятия.

Для авторизации MTA может использовать собственный список пользователей, системный список, списки пользователей LDAP или AD. Также существует способ: авторизация POP прежде SMTP, когда пользователь перед отправкой почты авторизуется на MDA, который, в свою очередь подтверждает аутентификацию пользователя для MTA.

Следующим шагом MTA анализирует служебную информацию письма, определяя домен получателя, если он относится к доменам обслуживаем данным МТА, производится поиск получателя и письмо помещается в его ящик. Так произошло, если бы Иванов написал письмо Петрову или Сидорову.

Если домен получателя не обслуживается MTA, формируется DNS-запрос, запрашивающий MX-записи для данного домена. MX-запись представляет особый вид DNS-записи, которая содержит имена почтовых серверов, обрабатывающих входящую почту для данного домена. MX-записей может быть несколько, в этом случае MTA пробует последовательно установить соединение, начиная с сервера с наибольшим приоритетом. При отсутствии MX-записи запрашивается A-запись (запись адреса, сопоставляющая доменное имя с IP-адресом) и выполняется попытка доставить почту на указанный там хост. При невозможности отправить сообщение, оно возвращается отправителю (помещается в почтовый ящик пользователя) с сообщением об ошибке.

Мы не будем рассматривать работу принимающего сервера, будем считать что все прошло нормально, Козлов получил письмо от Иванова и написал ему ответ. Сервер, обслуживающий домен example.com, проводит точно такие же действия и пробует передать почту нашему серверу. Получив входящее сообщение MTA, как и в случае с локальным отправителем, проверяет домен получателя, если он входит в число обслуживаемых MТА, обработка сообщения продолжается, иначе сервер отказывается принимать почту. После проверки домена проверяется получатель, если он присутствует в списке пользователей, сообщение доставляется в его ящик, в противном случае возможны два варианта: отказ от приема сообщения или прием сообщения в общий почтовый ящик (ящик администратора). С одной стороны такая настройка увеличивает число принимаемого спама, с другой позволяет не потерять письма с ошибками в написании адреса.

Еще одной мерой защиты от спама является запрос PTR-записи. PTR-запись (запись указателя) связывает IP-адрес с именем домена. Запрашивая PTR, MTA принимает почту только в том случае если домен отправителя совпадает с доменом отправляющего сервера.

Рассмотрим пример более подробно. Некий спамерский сервер spam.com пытается рассылать письма с поддельным отправителем, якобы от известного нам сервера example.com. В случае фильтрации по белым / черным спискам такое письмо будет доставлено, так как отправителем числится пользователь из доверенного домена (на что и рассчитывали спамеры). В целях борьбы со спамом MTA формирует запрос PTR записи для IP-адреса отправляющего сервера, который он сообщает в процессе SMTP сессии. Для адреса y.y.y.y PTR-запрос вернет имя домена spam.com, которое не совпадает с доменом отправителя, что будет причиной отказа в приеме данного сообщения. В то-же время сообщения от сервера x.x.x.x будут получены, так как домен из PTR-записи для x.x.x.x (example.com) совпадает с доменом отправителя.

Итак, сообщение получено и находится в почтовом ящике пользователя. Как его прочитать? Почтовое хранилище, где находятся ящики пользователей, может быть организовано самыми различными способами: начиная от банальных папок и фалов, заканчивая базой данных. Не обладая техническими знаниями, прочитать собственную почту вряд-ли удастся. Но разве это должно волновать пользователя Иванова? Для него процесс получения почты сводится к нажатию кнопки "Получить" в почтовом клиенте.

Для получения почты клиент устанавливает соединение с MDA по протоколу POP3 или IMAP, обязательно передавая данные для авторизации. MDA проверяет наличие пользователя в списках и, при успешной проверке, передает клиенту все новые сообщения находящиеся в его почтовом ящике. Пользователь Иванов получает свою корреспонденцию и может работать с ней удобным ему способом.

На этом наша статья заканчивается, мы настоятельно рекомендуем вдумчивое прочтение и усвоение изложенного в ней материала. В последующем, при рассмотрении практических реализаций почтовых серверов мы будем подавать материал из расчета, что читатель имеет знания в объеме не менее данной статьи.