Поиск по сайту:

Как создать собственное облако для себя и своих друзей на Debian Wheezy


На этой странице

  1. Верните свою конфиденциальность и контроль над своими данными всего за несколько часов: создайте собственное облако для себя и своих друзей.
    1. Некоторые наиболее личные части вашей личности хранятся на серверах по всему миру вне вашего контроля.
    2. Ваша ежедневная привычка делиться самой личной информацией повлияет на вашу жизнь таким образом, что никто даже не может предвидеть.
    3. Защитите свою конфиденциальность и конфиденциальность близких вам людей всего за 5 часов
    4. Эта статья основана на предыдущей работе

    1. Концепция политики в отношении отправителей
    2. Обратный PTR
    3. ОпенДКИМ

    Верните свою конфиденциальность и контроль над своими данными всего за несколько часов: создайте собственное облако для себя и своих друзей

    Руди Жхаусс <[email >

    40000+ поисков за 8 лет! Это моя история поиска в Google. Как насчет твоей? (Вы можете узнать сами здесь) С таким большим количеством данных за столь долгое время у Google есть очень точное представление о том, что вас интересовало, о чем вы думали, о чем беспокоились и как все это изменилось. за годы, прошедшие с тех пор, как вы впервые получили эту учетную запись Google.

    Некоторые из самых личных частей вашей личности хранятся на серверах по всему миру вне вашего контроля.

    Допустим, вы были пользователем Gmail в период с 2006 по 2013 год, как и я, то есть вы получили более 30 000 электронных писем и написали около 5 000 электронных писем за этот 7-летний период. Некоторые электронные письма, которые вы отправляли или получали, были очень личными, возможно, настолько личными, что вы, вероятно, не хотели бы, чтобы даже некоторые члены семьи или близкие друзья просматривали их систематически. Возможно, вы также написали несколько писем, которые так и не отправили, потому что передумали в последнюю минуту. Но даже если вы никогда их не отправляли, эти электронные письма все равно хранятся где-то на сервере. В результате будет справедливо сказать, что серверы Google знают о вашей личной жизни больше, чем ваши самые близкие друзья или ваша семья.

    Статистически можно с уверенностью считать, что у вас есть смартфон. Вы едва ли можете использовать телефон без использования приложения для контактов, которое по умолчанию хранит ваши контакты в Google Contact на серверах Google. Таким образом, Google знает не только о ваших электронных письмах, но и о ваших офлайн-контактах: кому вы любите звонить, кто звонит вам, кому вы пишете и о чем вы им пишете. Вам не нужно верить мне на слово, вы можете убедиться сами, взглянув на разрешения, которые вы дали приложениям, таким как сервис Google Play, на чтение списка людей, которые вам звонили, и SMS, которые вы получили. Вы также используете приложение календаря, которое поставляется с вашим телефоном? Если вы явно не отказались от этого при настройке календаря, это означает, что Google точно знает, чем вы занимаетесь в любое время дня, день за днем, год за годом. То же самое применимо, если вы выбрали iPhone вместо телефона Android, за исключением того, что Apple узнает о вашей переписке, контактах и расписании вместо Google.

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

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

    Подводя итог, если вы обычный пользователь Интернета, у Google есть актуальная и подробная информация о ваших интересах, заботах, увлечениях и вопросах за почти 10 лет. В нем собраны некоторые из ваших самых личных сообщений (электронные письма, SMS), почасовая информация о ваших ежедневных действиях и местоположении, а также высококачественное изображение вашей социальной сети. Такое глубокое знание вас, вероятно, выходит за рамки того, что знают о вас ваши самые близкие друзья, семья или ваша возлюбленная.

    Не приходит в голову передать эту массу глубоко личной информации совершенно незнакомым людям, например, поместив все это на флешку и оставив на столике в случайном кафе с запиской «Персональные данные Оливье Мартена, используйте по назначению». пожалуйста. Кто знает, кто может его найти и что с ним делать? Тем не менее, у нас нет проблем с передачей основных частей вашей личности незнакомцам из ИТ-компаний, проявляющих большой интерес к нашим данным (именно так они зарабатывают свой хлеб), и экспертам мирового уровня в области анализа данных, возможно, просто потому, что это происходит по умолчанию без мы думаем об этом, когда нажимаем зеленую кнопку «Принять».

    С таким большим количеством высококачественной информации за эти годы Google вполне может узнать вас лучше, чем вы когда-либо могли надеяться узнать себя: черт возьми, прямо сейчас ползая по моему цифровому прошлому, я не могу вспомнить, что написал половину электронных писем, которые я отправил пять лет назад. Я удивлен и рад вновь открыть для себя мой интерес к марксизму в 2005 году и мое присоединение, так же, как Sony был недавно взломан, и все ваши личные данные навсегда оказались в публичной сфере?

    Одна из причин, по которой большинство из нас доверили свои личные данные этим компаниям, заключается в том, что они предоставляют свои услуги бесплатно. Но насколько это бесплатно на самом деле? Стоимость средней учетной записи Google варьируется в зависимости от метода, используемого для ее оценки: 500 долларов США в год. Так что услуга не совсем бесплатная: вы платите за нее за счет рекламы и неизвестных пока применений, которые наши данные могут найти в будущем.

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

    Верните свою конфиденциальность и конфиденциальность людей, о которых вы заботитесь, всего за 5 часов

    Так быть не должно. Вы можете жить в 21 веке, иметь смартфон, ежедневно пользоваться электронной почтой и GPS и при этом сохранять конфиденциальность. Все, что вам нужно сделать, это вернуть контроль над вашими личными данными: электронной почтой, календарем, контактами, файлами и т. д. На веб-сайте Prism-Break.org есть программное обеспечение, помогающее контролировать судьбу ваших личных данных. Помимо этих вариантов, самый безопасный и самый эффективный способ вернуть себе контроль над вашими личными данными — это самостоятельно разместить свое облако, создав собственный сервер. Но у вас может просто не быть времени и энергии, чтобы исследовать, как именно это сделать и заставить это работать гладко.

    Вот где эта статья подходит. Всего за 5 часов мы настроим сервер для размещения ваших электронных писем, контактов, календарей и файлов для вас, ваших друзей и вашей семьи. Сервер предназначен для работы в качестве концентратора или облака для ваших личных данных, так что вы всегда сохраняете полный контроль над ними. Данные будут автоматически синхронизированы между вашим ПК/ноутбуком, телефоном и планшетом. По сути, мы создадим систему, которая заменит Gmail, Google Drive/Dropbox, Google Contacts, Google Calendar и Picasa.

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

    Мы построим систему, которая

    1. поддерживает произвольное количество доменов и пользователей. Это позволяет легко делиться своим сервером с семьей и друзьями, так что они также получают контроль над своими личными данными и могут разделить с вами стоимость сервера. Люди, совместно использующие ваш сервер, могут использовать свое собственное доменное имя или совместно использовать ваше.
    2. позволяет отправлять и получать электронную почту из любой сети после успешного входа на сервер. Таким образом, вы можете отправлять электронные письма с любого из ваших адресов электронной почты, с любого устройства (ПК, телефона, планшета) и из любой сети (дома, на работе, из общедоступной сети, ...)
    3. шифрует сетевой трафик при отправке и получении электронной почты, поэтому люди, которым вы не доверяете, не смогут узнать ваш пароль и прочитать ваши личные электронные письма.
    4. предлагает самые современные средства защиты от спама, объединяющие черные списки известных спамеров, автоматический серый список и адаптивную фильтрацию спама. Переобучение адаптивного спам-фильтра, если электронное письмо неправильно классифицировано, просто выполняется путем перемещения спама в папку «Спам/Спам» или из нее. Кроме того, сервер будет способствовать усилиям сообщества по борьбе со спамом.
    5. иногда требуется всего несколько минут обслуживания, в основном для установки обновлений безопасности и краткой проверки журналов сервера. Добавление нового адреса электронной почты сводится к добавлению одной записи в базу данных. Кроме того, вы можете просто забыть об этом и жить своей жизнью. Я установил систему, описанную в этой статье, 14 месяцев назад, и с тех пор все работает без сбоев. Так что я совершенно забыл об этом, пока недавно не улыбнулся мысли о том, что случайное нажатие кнопки «Проверить электронную почту» на моем телефоне заставило электроны путешествовать до Исландии (где находится мой сервер) и обратно.

    Чтобы пройти эту статью, вам потребуется минимум технических возможностей. Если вы знаете, в чем разница между SMTP и IMAP, что такое DNS, и имеете базовое представление о TCP/IP, вы знаете достаточно, чтобы довести дело до конца. Вам также потребуются базовые рабочие знания Unix (работа с файлами из командной строки, базовое системное администрирование). И вам потребуется в общей сложности 5 часов времени, чтобы настроить его.

    Вот обзор того, что мы будем делать:

    1. Получите виртуальный частный сервер, доменное имя и настройте их.
    2. Настройте postfix и dovecot для отправки и получения электронной почты.
    3. Предотвратите попадание спама в ваш ВХОДЯЩИЙ ЯЩИК
    4. Убедитесь, что отправляемые вами электронные письма проходят через спам-фильтры.
    5. Размещение календарей, контактов и файлов с помощью Owncloud и настройка веб-почты
    6. Синхронизируйте свои устройства с облаком

    Эта статья была вдохновлена предыдущей работой и основана на ней.

    Эта статья во многом основана на двух других статьях, а именно: «Введение Дрю Кроуфорда в самостоятельное размещение электронной почты».

    Статья включает в себя все функции статей Xaviers и Draws, за исключением трех функций, которые были у Дрю и которые мне не нужны, а именно поддержка push для электронной почты (я люблю проверять электронную почту только тогда, когда решаю, иначе я все время отвлекаюсь) , полнотекстовый поиск в электронной почте (который мне не нужен) и хранение электронных писем в зашифрованном виде (мои электронные письма и данные не критичны до такой степени, что мне приходится шифровать их локально на сервере). Если вам нужны какие-либо из этих функций, не стесняйтесь просто добавлять их, следуя соответствующему разделу статьи Drews, который совместим с текущим.

    По сравнению с работой Ксавьера и Дрю, настоящая статья улучшает несколько аспектов:

    • в нем исправлены ошибки и опечатки, основанные на моем опыте работы со статьей Дрю и многочисленных комментариях к его оригинальной статье. Я также просмотрел данную статью, несколько раз настроив сервер с нуля, чтобы воспроизвести его и убедиться, что он будет работать прямо из коробки.
    • низкие эксплуатационные расходы: по сравнению с работой Ксавьера в настоящей статье добавлена поддержка нескольких доменов электронной почты на сервере. Для этого требуется минимально возможное обслуживание сервера: в основном, чтобы добавить домен или пользователя, просто добавьте одну строку в таблицу mysql и все (нет необходимости добавлять скрипты sieve, ...).
    • Я добавил веб-почту.
    • Я добавил раздел по настройке облака, чтобы хранить не только ваши электронные письма, но и ваши файлы, вашу адресную книгу/контакты (электронные письма, номера телефонов, дни рождения, ...), календари и изображения для использования на ваших устройствах.

    Получите виртуальный частный сервер, доменное имя и настройте их.

    Давайте начнем с настройки базовой инфраструктуры: нашего виртуального частного сервера и нашего доменного имени.

    У меня был отличный опыт работы с виртуальными частными серверами (VPS) бесплатного программного обеспечения.

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

    Для регистрации доменного имени пользуюсь услугами ганди уже более 10 лет, тоже с удовольствием. Для этой статьи мы создадим зону с именем jhausse.net. Затем мы добавляем к нему хост с именем cloud.jhausse.net, устанавливаем запись MX для этого хоста. Пока вы это делаете, установите короткое время жизни (TTL) для ваших записей, например 300 секунд, чтобы вы могли вносить изменения в свою зону и быстро проверять результат во время настройки сервера.

    Наконец, установите эту статью, чтобы получить фон. Если вы используете Linode, вы можете установить PTR-запись в панели управления в разделе «Удаленный доступ». С 1984 обратитесь в техподдержку, которая вам в этом поможет.

    На сервере мы начнем с добавления непривилегированного пользователя, чтобы нам не приходилось все время работать от имени пользователя root. Кроме того, для входа в систему с правами root потребуется дополнительный уровень безопасности.

    adduser roudy
    

    Затем в /etc/ssh/sshd_config устанавливаем

    PermitRootLogin no
    

    и перезагрузить ssh сервер

    service ssh reload
    

    Затем нужно изменить имя хоста сервера. Отредактируйте /etc/hostname так, чтобы в нашем случае в нем была только одна строка с вашим именем хоста.

    cloud
    

    Затем отредактируйте файлы открытых ключей ssh-серверов /etc/ssh/ssh_host_rsa_key.pub, /etc/ssh/ssh_host_dsa_key.pub, /etc/ssh/ssh_host_ecdsa_key.pub, чтобы конец файла отражал ваше имя хоста или экземпляр [email защищен]. Затем перезапустите систему, чтобы убедиться, что имя хоста исправлено везде, где оно должно быть.

    reboot
    

    Мы обновим систему и удалим ненужные нам службы, чтобы снизить риск удаленных атак.

    apt-get update
    apt-get dist-upgrade
    service exim4 stop
    apt-get remove exim4 rpcbind
    apt-get autoremove
    apt-get install vim
    

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

    syn on

    в ~/.vimrc.

    Настройте postfix и dovecot для отправки и получения электронной почты.

    apt-get install postfix postfix-mysql dovecot-core dovecot-imapd dovecot-mysql mysql-server dovecot-lmtpd postgrey
    

    В меню конфигурации Postfix мы выбираем Internet Site и устанавливаем системное почтовое имя jhausse.net.

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

    mysqladmin -p create mailserver
    mysql -p mailserver
    mysql> GRANT SELECT ON mailserver.* TO 'mailuser'@'localhost' IDENTIFIED BY 'mailuserpass';
    mysql> FLUSH PRIVILEGES;
    mysql> CREATE TABLE `virtual_domains` (
      `id` int(11) NOT NULL auto_increment,
      `name` varchar(50) NOT NULL,
      PRIMARY KEY (`id`)
      ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
    mysql> CREATE TABLE `virtual_users` (
      `id` int(11) NOT NULL auto_increment,
      `domain_id` int(11) NOT NULL,
      `password` varchar(106) NOT NULL,
      `email` varchar(100) NOT NULL,
      PRIMARY KEY (`id`),
      UNIQUE KEY `email` (`email`),
      FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE
      ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
    mysql> CREATE TABLE `virtual_aliases` (
      `id` int(11) NOT NULL auto_increment,
      `domain_id` int(11) NOT NULL,
      `source` varchar(100) NOT NULL,
      `destination` varchar(100) NOT NULL,
      PRIMARY KEY (`id`),
      FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE
      ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
    

    Мы разместим домен jhausse.net. Если есть другие домены, которые вы хотели бы разместить, вы также можете добавить их. Мы также настроили адрес администратора почты для каждого домена, который перенаправляет на [email .

    mysql> INSERT INTO virtual_domains (`name`) VALUES ('jhausse.net');
    mysql> INSERT INTO virtual_domains (`name`) VALUES ('otherdomain.net');
    mysql> INSERT INTO virtual_aliases (`domain_id`, `source`, `destination`) VALUES ('1', 'postmaster', '');
    mysql> INSERT INTO virtual_aliases (`domain_id`, `source`, `destination`) VALUES ('2', 'postmaster', '');
    

    Теперь мы добавляем локальную учетную запись электронной почты [email . Во-первых, мы генерируем для него хэш пароля:

    doveadm pw -s SHA512-CRYPT

    а затем добавить хэш в базу данных

    mysql> INSERT INTO `mailserver`.`virtual_users` (`domain_id`, `password`, `email`) VALUES ('1', '$6$YOURPASSWORDHASH', '');
    

    Теперь, когда наш список доменов, псевдонимов и пользователей готов, мы настроим постфикс (SMTP-сервер для исходящей почты). Замените содержимое /etc/postfix/main.cf следующим:

    myhostname = cloud.jhausse.net
    myorigin = /etc/mailname
    mydestination = localhost.localdomain, localhost
    mynetworks_style = host
    
    # We disable relaying in the general case
    smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
    # Requirements on servers that contact us: we verify the client is not a
    # known spammer (reject_rbl_client) and use a graylist mechanism
    # (postgrey) to help reducing spam (check_policy_service)
    smtpd_client_restrictions = permit_mynetworks, reject_rbl_client zen.spamhaus.org, check_policy_service inet:127.0.0.1:10023
    disable_vrfy_command = yes
    inet_interfaces = all
    smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
    biff = no
    append_dot_mydomain = no
    readme_directory = no
    
    # TLS parameters
    smtpd_tls_cert_file=/etc/ssl/certs/cloud.crt
    smtpd_tls_key_file=/etc/ssl/private/cloud.key
    smtpd_use_tls=yes
    smtpd_tls_auth_only = yes
    smtp_tls_security_level=may
    smtp_tls_loglevel = 1
    smtpd_tls_loglevel = 1
    smtpd_tls_received_header = yes
    smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
    smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
    
    # Delivery
    alias_maps = hash:/etc/aliases
    alias_database = hash:/etc/aliases
    message_size_limit = 50000000
    recipient_delimiter = +
    
    # The next lines are useful to set up a backup MX for myfriendsdomain.org
    # relay_domains = myfriendsdomain.org
    # relay_recipient_maps =
    
    # Virtual domains
    virtual_transport = lmtp:unix:private/dovecot-lmtp
    virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
    virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
    virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf
    local_recipient_maps = $virtual_mailbox_maps
    

    Теперь нам нужно научить postfix выяснять, какие домены мы хотели бы, чтобы он принимал электронные письма для использования базы данных, которую мы только что создали. Создайте новый файл /etc/postfix/mysql-virtual-mailbox-domains.cf и добавьте следующее:

    user = mailuser
    password = mailuserpass
    hosts = 127.0.0.1
    dbname = mailserver
    query = SELECT 1 FROM virtual_domains WHERE name='%s'
    

    Мы учим postfix узнавать, существует ли данная учетная запись электронной почты, создавая /etc/postfix/mysql-virtual-mailbox-maps.cf со следующим содержимым

    user = mailuser
    password = mailuserpass
    hosts = 127.0.0.1
    dbname = mailserver
    query = SELECT 1 FROM virtual_users WHERE email='%s'
    

    Наконец, postfix будет использовать /etc/postfix/mysql-virtual-alias-maps.cf для поиска почтовых псевдонимов.

    user = mailuser
    password = mailuserpass
    hosts = 127.0.0.1
    dbname = mailserver
    query = SELECT virtual_aliases.destination as destination FROM virtual_aliases, virtual_domains WHERE virtual_aliases.source='%u' AND virtual_aliases.domain_id = virtual_domains.id AND virtual_domains.name='%d'
    

    Теперь, когда все это готово, пришло время проверить, может ли postfix правильно запрашивать нашу базу данных. Мы можем сделать это с помощью postmap:

    postmap -q jhausse.net mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
    postmap -q  mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
    postmap -q  mysql:/etc/postfix/mysql-virtual-alias-maps.cf
    postmap -q  mysql:/etc/postfix/mysql-virtual-alias-maps.cf
    

    Если вы все настроили правильно, первые два запроса должны возвращать 1, третий запрос должен возвращать [email , а последний не должен возвращать вообще ничего.

    Теперь давайте настроим dovecot (сервер IMAP для получения входящей почты на сервер с наших устройств). Отредактируйте /etc/dovecot/dovecot.conf, чтобы установить следующие параметры:

    # Enable installed protocol
    # !include_try /usr/share/dovecot/protocols.d/*.protocol 
    protocols = imap lmtp
    

    который будет включать только imap (чтобы мы могли получать электронные письма) и lmtp (который postfix будет использовать для передачи входящих электронных писем в dovecot). Отредактируйте /etc/dovecot/conf.d/10-mail.conf, чтобы установить следующие параметры:

    mail_location = maildir:/var/mail/%d/%n
    [...]
    mail_privileged_group = mail
    [...]
    first_valid_uid = 0
    

    который будет хранить электронные письма в /var/mail/domainname/username. Обратите внимание, что эти настройки разбросаны по разным местам в файле, и иногда мы уже можем их задать: нам просто нужно их закомментировать. Остальные настройки, которые уже есть в файле, можно оставить как есть. Нам нужно будет сделать то же самое, чтобы обновить настройки во многих других файлах в оставшейся части этой статьи. В /etc/dovecot/conf.d/10-auth.conf задайте параметры:

    disable_plaintext_auth = yes
    auth_mechanisms = plain
    #!include auth-system.conf.ext
    !include auth-sql.conf.ext
    

    В /etc/dovecot/conf.d/auth-sql.conf.ext установите следующие параметры:

    passdb {
      driver = sql
      args = /etc/dovecot/dovecot-sql.conf.ext
    }
    userdb {
      driver = static
      args = uid=mail gid=mail home=/var/mail/%d/%n
    }
    

    где мы только что научили dovecot тому, что пользователи хранят свою электронную почту в /var/mail/domainname/username и ищут пароли в базе данных, которую мы только что создали. Теперь нам еще нужно научить dovecot, как именно пользоваться базой данных. Для этого поместите в /etc/dovecot/dovecot-sql.conf.ext следующее:

    driver = mysql
    connect = host=localhost dbname=mailserver user=mailuser password=mailuserpass
    default_pass_scheme = SHA512-CRYPT
    password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';
    

    Теперь мы исправляем разрешения для файлов конфигурации

    chown -R mail:dovecot /etc/dovecot
    chmod -R o-rwx /etc/dovecot
    

    Почти готово! Нам просто нужно отредактировать еще пару файлов. В /etc/dovecot/conf.d/10-master.conf задайте следующие параметры:

    service imap-login {
      inet_listener imap {
        #port = 143
        port = 0
      }
      inet_listener imaps {
        port = 993
        ssl = yes
      }
    }
    
    service pop3-login {
     inet_listener pop3 {
        #port = 110
        port = 0
      }
      inet_listener pop3s {
        #port = 995
        #ssl = yes
        port = 0
      }
    }
    
    service lmtp {
      unix_listener /var/spool/postfix/private/dovecot-lmtp {
        mode = 0666
        group = postfix
        user = postfix
      }
      user = mail
    }
    
    service auth {
      unix_listener auth-userdb {
        mode = 0600
        user = mail
        #group = 
      }
    
      # Postfix smtp-auth
      unix_listener /var/spool/postfix/private/auth {
        mode = 0666
        user = postfix
        group = postfix
      }
    
      # Auth process is run as this user.
      #user = $default_internal_user
      user = dovecot
    }
    
    service auth-worker {
      user = mail
    }
    

    Обратите внимание, что мы устанавливаем порты для всех служб, кроме imap, равными 0, что фактически отключает их. Затем в файле /etc/dovecot/conf.d/15-lda.conf укажите адрес электронной почты для постмастера:

    postmaster_address = 
    

    И последнее, но не менее важное: нам нужно сгенерировать пару открытого и закрытого ключа для сервера, которые мы будем использовать как в dovecot, так и в postfix:

    openssl req -new -newkey rsa:4096 -x509 -days 365 -nodes -out "/etc/ssl/certs/cloud.crt" -keyout "/etc/ssl/private/cloud.key"
    

    Убедитесь, что вы указали полное доменное имя (FQDN) сервера, в нашем случае:

    Common Name (e.g. server FQDN or YOUR name) []:cloud.jhausse.net
    

    Если вы этого не сделаете, наши клиенты могут пожаловаться на то, что имя сервера в SSL-сертификате не соответствует имени сервера, к которому они подключаются. Мы говорим dovecot использовать эти ключи, устанавливая следующие параметры в /etc/dovecot/conf.d/10-ssl.conf:

    ssl = required
    ssl_cert = </etc/ssl/certs/cloud.crt
    ssl_key = </etc/ssl/private/cloud.key
    

    Вот и все! Теперь приступим к тестированию серверов postfix и dovecot!

    service dovecot restart
    service postfix restart
    

    С самого сервера попробуйте отправить электронное письмо локальному пользователю:

    telnet localhost 25
    EHLO cloud.jhausse.net
    MAIL FROM:
    rcpt to:
    data
    Subject: Hallo!
    
    This is a test, to check if cloud.jhausse.net is ready to be an MX!
    
    Cheers, Roudy
    .
    QUIT
    

    Сервер должен принять наше письмо с сообщением типа

    250 2.0.0 Ok: queued as 58D54101DB
    

    Проверьте журналы в /var/log/mail.log, если все прошло нормально. Должна быть строка, говорящая что-то вроде

    Nov 14 07:57:06 cloud dovecot: lmtp(4375, ): ... saved mail to INBOX
    

    Все идет нормально? Хороший. Теперь давайте попробуем то же самое на другом компьютере, например на том, который мы используем для настройки сервера. На этот раз поговорите с сервером, используя шифрование (TLS):

    openssl s_client -connect cloud.jhausse.net:25 -starttls smtp
    EHLO cloud.jhausse.net
    MAIL FROM:
    rcpt to:
    

    на что сервер должен ответить

    554 5.7.1 <>: Relay access denied

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

    554 5.7.1 Service unavailable; Client host [87.68.61.119] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=87.68.61.119
    

    Это означает, что вы пытаетесь связаться с сервером с IP-адреса, который считается адресом спамеров. Я получил это сообщение при попытке подключиться к серверу через моего обычного интернет-провайдера (ISP). Чтобы решить эту проблему, вы можете попробовать подключиться с другого хоста, возможно, с другого сервера, к которому у вас есть доступ через SSH. В качестве альтернативы вы можете перенастроить Postfixs main.cf, чтобы он не использовал Spamhauss RBL, перезагрузить постфикс и убедиться, что приведенный выше тест работает. В обоих случаях важно, чтобы вы нашли решение, которое работает для вас, потому что вы можете протестировать другие вещи за минуту. Если вы решили перенастроить Postfix так, чтобы он не использовал RBL, не забудьте вернуть RBL и перезагрузить postfix после прочтения статьи, чтобы избежать получения большего количества спама, чем необходимо.

    Теперь давайте попытаемся отправить действительное электронное письмо по SMTP на порт 25, который обычные почтовые серверы используют для связи друг с другом:

    openssl s_client -connect cloud.jhausse.net:25 -starttls smtp
    EHLO cloud.jhausse.net
    MAIL FROM:
    rcpt to:
    

    на что сервер должен ответить

    Client host rejected: Greylisted, see http://postgrey.schweikert.ch/help/jhausse.net.html
    

    что показывает, что postgrey работает как надо. Что postgrey делает, чтобы отклонять электронные письма с временной ошибкой, если отправителя никогда раньше не видели. Технические правила электронной почты требуют, чтобы почтовые серверы попытались снова доставить электронное письмо. Через пять минут postgrey примет письмо. Легальные почтовые серверы по всему миру будут неоднократно пытаться повторно доставить нам письмо, но большинство спамеров этого не делают. Итак, подождите 5 минут, попробуйте снова отправить электронное письмо, используя приведенную выше команду, и убедитесь, что postfix теперь принимает электронное письмо.

    После этого проверьте, можем ли мы получить два письма, которые мы только что отправили сами себе, поговорив с dovecot по IMAP:

    openssl s_client -crlf -connect cloud.jhausse.net:993
    1 login  "mypassword"
    2 LIST "" "*"
    3 SELECT INBOX
    4 UID fetch 1:1 (UID RFC822.SIZE FLAGS BODY.PEEK[])
    5 LOGOUT
    

    где вы должны заменить mypassword паролем, который вы установили для этой учетной записи электронной почты. Если это работает, у нас в основном есть функциональный сервер электронной почты, который может получать наши входящие электронные письма и с которого мы получаем эти электронные письма с наших устройств (ПК/ноутбук, планшеты, телефоны и т. д.). Но мы не можем дать ему наши электронные письма для отправки, если мы не отправим их с самого сервера. Что ж, теперь разрешите postfix пересылать наши электронные письма, но только после успешной аутентификации, то есть после того, как он сможет убедиться, что электронное письмо исходит от кого-то, у кого есть действующая учетная запись на сервере. Для этого откройте специальную службу отправки электронной почты, использующую только SSL и SASL-аутентификацию. Задайте следующие параметры в /etc/postfix/master.cf:

    submission inet n       -       -       -       -       smtpd
      -o syslog_name=postfix/submission
      -o smtpd_tls_security_level=encrypt
      -o smtpd_sasl_auth_enable=yes
      -o smtpd_client_restrictions=permit_sasl_authenticated,reject
      -o smtpd_sasl_type=dovecot
      -o smtpd_sasl_path=private/auth
      -o smtpd_sasl_security_options=noanonymous
      -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject_non_fqdn_recipient,reject_unauth_destination
    

    и перезагрузить постфикс

    service postfix reload
    

    Теперь давайте попробуем использовать эту службу с другого компьютера, отличного от сервера, чтобы убедиться, что postfix теперь будет ретранслировать наши электронные письма и никто другой:

    openssl s_client -connect cloud.jhausse.net:587 -starttls smtp
    EHLO cloud.jhausse.net
    

    Обратите внимание на рекламируемые сервером возможности 250-AUTH PLAIN, которые не отображаются, когда мы подключаемся к порту 25.

    MAIL FROM:
    rcpt to:
    554 5.7.1 <>: Relay access denied
    QUIT
    

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

    echo -ne '\\000mypassword'|base64
    

    и давайте попробуем снова отправить письма через сервер:

    openssl s_client -connect cloud.jhausse.net:587 -starttls smtp
    EHLO cloud.jhausse.net
    AUTH PLAIN DGplYW5AMTk4NGNsb3VQLm5ldAA4bmFmNGNvNG5jOA==
    MAIL FROM:
    rcpt to:
    

    какой постфикс теперь должен принимать. Чтобы завершить тест, давайте проверим, работают ли наши виртуальные псевдонимы, отправив электронное письмо на адрес [email :

    telnet cloud.jhausse.net 25
    EHLO cloud.jhausse.net
    MAIL FROM:
    rcpt to:
    data
    Subject: Virtual alias test
    
    Dear postmaster,
    Long time no hear! I hope your MX is working smoothly and securely.
    Yours sincerely, Roudy
    .
    QUIT
    

    Давайте проверим, что почта дошла до нужного почтового ящика:

    openssl s_client -crlf -connect cloud.jhausse.net:993
    1 login  "mypassword"
    2 LIST "" "*"
    3 SELECT INBOX
    * 2 EXISTS
    * 2 RECENT
    4 LOGOUT
    

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

    PS: вы не забыли попробовать снова отправить электронное письмо на учетную запись, размещенную на сервере, через порт 25, чтобы убедиться, что вы больше не заблокированы postgrey?

    <имя=dspam>

    Предотвратите попадание спама в ваш INBOX

    <имя=dspam>

    Для фильтрации спама у нас уже есть черные списки реального времени (RBL) и серые списки (postgrey). А теперь улучшите наши возможности борьбы со спамом, добавив адаптивную фильтрацию спама. Это означает, что мы должны добавить искусственный интеллект к нашему почтовому серверу, чтобы он мог на собственном опыте узнать, что является спамом, а что нет. Для этого мы будем использовать dspam.

    apt-get install dspam dovecot-antispam postfix-pcre dovecot-sieve
    

    dovecot-antispam — это пакет, который позволяет dovecot переобучить спам-фильтр, если мы находим электронное письмо, которое неправильно классифицируется dspam. По сути, все, что нам нужно сделать, это переместить электронные письма в папку «Спам/Спам» или из нее. Затем dovecot-antispam позаботится о вызове dspam для переобучения фильтра. Что касается postfix-pcre и dovecot-sieve, мы будем использовать их соответственно для пропуска входящих писем через спам-фильтр и для автоматического перемещения спама в папку нежелательной почты/спама пользователей.

    В файле /etc/dspam/dspam.conf установите для следующих параметров следующие значения:

    TrustedDeliveryAgent "/usr/sbin/sendmail"
    UntrustedDeliveryAgent "/usr/lib/dovecot/deliver -d %u"
    Tokenizer osb
    IgnoreHeader X-Spam-Status
    IgnoreHeader X-Spam-Scanned
    IgnoreHeader X-Virus-Scanner-Result
    IgnoreHeader X-Virus-Scanned
    IgnoreHeader X-DKIM
    IgnoreHeader DKIM-Signature
    IgnoreHeader DomainKey-Signature
    IgnoreHeader X-Google-Dkim-Signature
    ParseToHeaders on
    ChangeModeOnParse off
    ChangeUserOnParse full
    ServerPID               /var/run/dspam/dspam.pid
    ServerDomainSocketPath  "/var/run/dspam/dspam.sock"
    ClientHost      /var/run/dspam/dspam.sock
    

    Затем в /etc/dspam/default.prefs измените следующие параметры на:

    spamAction=deliver         # { quarantine | tag | deliver } -> default:quarantine
    signatureLocation=headers  # { message | headers } -> default:message
    showFactors=on
    

    Теперь нам нужно подключить dspam к postfix и dovecot, добавив эти две строчки в конец /etc/postfix/master.cf:

    dspam     unix  -       n       n       -       10      pipe
      flags=Ru user=dspam argv=/usr/bin/dspam --deliver=innocent,spam --user $recipient -i -f $sender -- $recipient
    dovecot   unix  -       n       n       -       -       pipe
      flags=DRhu user=mail:mail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${recipient}
    

    Теперь мы скажем postfix фильтровать каждое новое электронное письмо, которое отправляется на сервер через порт 25 (обычный SMTP-трафик) через dspam, за исключением случаев, когда электронное письмо отправляется с самого сервера (permit_mynetworks). Обратите внимание, что электронные письма, которые мы отправляем в postfix с аутентификацией SASL, также не будут фильтроваться через dspam, поскольку мы настроили отдельную службу отправки для тех, что описаны в предыдущем разделе. Отредактируйте /etc/postfix/main.cf, чтобы изменить smtpd_client_restrictions на следующее:

    smtpd_client_restrictions = permit_mynetworks, reject_rbl_client zen.spamhaus.org, check_policy_service inet:127.0.0.1:10023, check_client_access pcre:/etc/postfix/dspam_filter_access
    

    В конце файла также добавьте:

    # For DSPAM, only scan one mail at a time
    dspam_destination_recipient_limit = 1
    

    Теперь нам нужно указать фильтр, который мы определили. По сути, мы скажем postfix отправлять все электронные письма (/./) в dspam через сокет unix. Создайте новый файл /etc/postfix/dspam_filter_access и поместите в него следующую строку:

    /./   FILTER dspam:unix:/run/dspam/dspam.sock
    

    Вот и все, что касается постфиксной части. Теперь давайте настроим dovecot для фильтрации спама. В файле /etc/dovecot/conf.d/20-imap.conf отредактируйте параметр плагинов imap mail_plugins следующим образом:

    mail_plugins = $mail_plugins antispam
    

    и добавить раздел для lmtp:

    protocol lmtp {
    # Space separated list of plugins to load (default is global mail_plugins).
      mail_plugins = $mail_plugins sieve
    }
    

    Теперь мы настраиваем плагин dovecot-antispam. Отредактируйте /etc/dovecot/conf.d/90-plugin.conf, чтобы добавить в раздел плагинов следующее содержимое:

    plugin {
      ...
      # Antispam (DSPAM)
      antispam_backend = dspam
      antispam_allow_append_to_spam = YES
      antispam_spam = Junk;Spam
      antispam_trash = Trash;trash
      antispam_signature = X-DSPAM-Signature
      antispam_signature_missing = error
      antispam_dspam_binary = /usr/bin/dspam
      antispam_dspam_args = --user;%u;--deliver=;--source=error
      antispam_dspam_spam = --class=spam
      antispam_dspam_notspam = --class=innocent
      antispam_dspam_result_header = X-DSPAM-Result
    }
    

    и в /etc/dovecot/conf.d/90-sieve.conf укажите скрипт sieve по умолчанию, который будет применяться ко всем пользователям сервера:

    sieve_default = /etc/dovecot/default.sieve
    

    Что такое sieve и зачем нам скрипт по умолчанию для всех пользователей? Sieve позволяет нам автоматизировать задачи на сервере IMAP. В нашем случае мы не будем помещать все электронные письма, идентифицированные как спам, в папку «Нежелательная почта», а не в папку «Входящие». Мы хотели бы, чтобы это было поведением по умолчанию для всех пользователей на сервере; вот почему мы просто установили этот сценарий как сценарий по умолчанию. Давайте создадим этот скрипт сейчас, создав новый файл /etc/dovecot/default.sieve со следующим содержимым:

    require ["regex", "fileinto", "imap4flags"];
    # Catch mail tagged as Spam, except Spam retrained and delivered to the mailbox
    if allof (header :regex "X-DSPAM-Result" "^(Spam|Virus|Bl[ao]cklisted)$",
              not header :contains "X-DSPAM-Reclassified" "Innocent") {
      # Mark as read
      # setflag "\\Seen";
      # Move into the Junk folder
      fileinto "Junk";
      # Stop processing here
      stop;
    }
    

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

    cd /etc/dovecot
    sievec .
    chown mail.dovecot default.siev*
    chmod 0640 default.sieve
    chmod 0750 default.svbin
    

    Наконец, нам нужно исправить права доступа к двум конфигурационным файлам постфикса, из которых dspam должен читать:

    chmod 0644 /etc/postfix/dynamicmaps.cf /etc/postfix/main.cf
    

    Вот и все! Перезапускаем голубятню и постфикс

    service dovecot restart
    service postfix restart
    

    и протестируйте антиспам, связавшись с сервером с удаленного хоста (например, с компьютера, который мы используем для настройки сервера):

    openssl s_client -connect cloud.jhausse.net:25 -starttls smtp
    EHLO cloud.jhausse.net
    MAIL FROM:
    rcpt to:
    DATA
    Subject: DSPAM test
    
    Hi Roudy, how'd you like to eat some ham tonight? Yours, J
    .
    QUIT
    

    Проверяем пришло ли письмо:

    openssl s_client -crlf -connect cloud.jhausse.net:993
    1 login  "mypassword"
    2 LIST "" "*"
    3 SELECT INBOX
    4 UID fetch 3:3 (UID RFC822.SIZE FLAGS BODY.PEEK[])
    

    Который должен вернуть что-то электронное письмо с набором флагов, установленных СПАМом, которые выглядят следующим образом:

    X-DSPAM-Result: Innocent
    X-DSPAM-Processed: Sun Oct  5 16:25:48 2014
    X-DSPAM-Confidence: 1.0000
    X-DSPAM-Probability: 0.0023
    X-DSPAM-Signature: 5431710c178911166011737
    X-DSPAM-Factors: 27,
    	Received*Postfix+with, 0.40000,
    	Received*with+#+id, 0.40000,
    	like+#+#+#+ham, 0.40000,
    	some+#+tonight, 0.40000,
    	Received*certificate+requested, 0.40000,
    	Received*client+certificate, 0.40000,
    	Received*for+roudy, 0.40000,
    	Received*Sun+#+#+#+16, 0.40000,
    	Received*Sun+#+Oct, 0.40000,
    	Received*roudy+#+#+#+Oct, 0.40000,
    	eat+some, 0.40000,
    	Received*5+#+#+16, 0.40000,
    	Received*cloud.jhausse.net+#+#+#+id, 0.40000,
    	Roudy+#+#+#+to, 0.40000,
    	Received*Oct+#+16, 0.40000,
    	to+#+#+ham, 0.40000,
    	Received*No+#+#+requested, 0.40000,
    	Received*jhausse.net+#+#+Oct, 0.40000,
    	Received*256+256, 0.40000,
    	like+#+#+some, 0.40000,
    	Received*ESMTPS+id, 0.40000,
    	how'd+#+#+to, 0.40000,
    	tonight+Yours, 0.40000,
    	Received*with+cipher, 0.40000
    5 LOGOUT
    

    Хороший! Теперь у вас настроена адаптивная фильтрация спама для пользователей вашего сервера. Конечно, в первые несколько недель каждому пользователю нужно будет обучить фильтр. Чтобы квалифицировать сообщение как спам, просто переместите его в папку под названием «Спам» или «Нежелательная почта» с помощью любого из ваших устройств (ПК, планшет, телефон). В противном случае его будут тренировать как ветчину.

    <имя=SPF>

    Убедитесь, что электронные письма, которые вы отправляете, проходят через спам-фильтры.

    <имя=SPF>

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

    Структура политики отправителя

    Sender Policy Framework (SPF) — это запись, которую вы добавляете в свою зону, которая объявляет, какие почтовые серверы во всем Интернете могут отправлять электронные письма для вашего доменного имени. Настроить его очень просто: используйте мастер SPF на сайте microsoft.com, чтобы создать запись SPF, а затем добавить ее в свою зону в виде записи TXT. Это будет выглядеть так:

    jhausse.net.	300 IN	TXT	v=spf1 mx mx:cloud.jhausse.net -all
    

    Обратный PTR

    Мы обсуждали этот момент ранее в этой статье. Рекомендуется правильно настроить обратный DNS для своего сервера, чтобы при обратном поиске по IP-адресу вашего сервера возвращалось фактическое имя вашего сервера.

    OpenDKIM

    Когда мы активируем OpenDKIM, postfix будет подписывать каждое исходящее письмо с помощью криптографического ключа. Затем мы поместим этот ключ в нашу зону в DNS. Таким образом, каждый почтовый сервер в мире сможет проверить, действительно ли электронное письмо пришло от нас или оно было подделано спамером. Давайте установим opendkim:

    apt-get install opendkim opendkim-tools
    

    И настройте его, отредактировав /etc/opendkim.conf так, чтобы он выглядел так:

    ##
    ## opendkim.conf -- configuration file for OpenDKIM filter
    ##
    Canonicalization        relaxed/relaxed
    ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
    InternalHosts           refile:/etc/opendkim/TrustedHosts
    KeyTable                refile:/etc/opendkim/KeyTable
    LogWhy                  Yes
    MinimumKeyBits          1024
    Mode                    sv
    PidFile                 /var/run/opendkim/opendkim.pid
    SigningTable            refile:/etc/opendkim/SigningTable
    Socket                  inet:
    Syslog                  Yes
    SyslogSuccess           Yes
    TemporaryDirectory      /var/tmp
    UMask                   022
    UserID                  opendkim:opendkim
    

    Нужна пара дополнительных файлов, которые мы будем хранить в /etc/opendkim:

    mkdir -pv /etc/opendkim/
    cd /etc/opendkim/
    

    Давайте создадим новый файл /etc/opendkim/TrustedHosts со следующим содержимым

    127.0.0.1
    

    и новый файл с именем /etc/opendkim/KeyTable со следующим содержимым

    cloudkey jhausse.net:mail:/etc/opendkim/mail.private
    

    Это сообщает OpenDKIM, что мы хотим использовать ключ шифрования с именем cloudkey, содержимое которого можно найти в /etc/opendkim/mail.private. Мы создадим еще один файл с именем /etc/opendkim/SigningTable и добавим следующую строку:

    *@jhausse.net cloudkey
    

    который сообщает OpenDKIM, что каждое электронное письмо домена jhausse.net должно быть подписано с использованием ключа cloudkey. Если у нас есть другие домены, которые мы хотим подписать, мы также можем добавить их сюда.

    Следующим шагом является создание этого ключа и исправление разрешений в файлах конфигурации OpenDKIM.

    opendkim-genkey -r -s mail [-t]
    chown -Rv opendkim:opendkim /etc/opendkim
    chmod 0600 /etc/opendkim/*
    chmod 0700 /etc/opendkim
    

    Во-первых, хорошей идеей будет использовать -t, который будет сигнализировать другим почтовым серверам, что вы просто находитесь в тестовом режиме и что они не должны отбрасывать электронные письма на основе вашей подписи OpenDKIM (пока). Вы можете получить свой ключ OpenDKIM из файла mail.txt:

    cat mail.txt
    

    а затем добавьте его в файл зоны как запись TXT, которая должна выглядеть так:

    mail._domainkey.cloud1984.net.	300	IN TXT	v=DKIM1; k=rsa; p=MIGfMA0GCSqG...
    

    Наконец, нам нужно указать postfix подписывать исходящие электронные письма. В конце /etc/postfix/main.cf добавьте:

    # Now for OpenDKIM: we'll sign all outgoing emails
    smtpd_milters = inet:127.0.0.1:8891
    non_smtpd_milters = $smtpd_milters
    milter_default_action = accept
    

    И перезагрузить соответствующие сервисы

    service postfix reload
    service opendkim restart
    

    Теперь давайте проверим, можно ли найти наш открытый ключ OpenDKIM и совпадает ли он с закрытым ключом:

    opendkim-testkey -d jhausse.net -s mail -k mail.private -vvv
    

    который должен вернуться

    opendkim-testkey: key OK

    Для этого вам может понадобиться немного подождать, пока DNS-сервер перезагрузит зону (на Линоде это происходит каждые 15 минут). Вы можете использовать dig, чтобы проверить, была ли уже перезагружена зона.

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

    mail -s CloudCheck www.brandonchecketts.com
    

    На веб-странице Brandons вы должны увидеть результат=передать в разделе Подпись DKIM и Результат: пройти в разделе Информация SPF. Если наши электронные письма проходят этот тест, просто заново создайте ключ OpenDKIM без ключа -t, загрузите новый ключ в файл зоны и повторите проверку, если он все еще проходит тесты. Если это так, поздравляю! Вы только что успешно настроили OpenDKIM и SPF на своем сервере!

    <имя=собственное облако>

    Разместите календари, контакты, файлы с помощью Owncloud и настройте веб-почту с помощью Roundcube.

    <имя=собственное облако>

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

    Установка Owncloud проста и хорошо описана здесь. В Debian это сводится к добавлению репозитория owncloud в ваши источники apt, загрузке ключа выпуска ownclouds и добавлению его в связку ключей apt, а затем установке самого owncloud с помощью apt-get:

    echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/community/Debian_7.0/ /' >> /etc/apt/sources.list.d/owncloud.list
    wget http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_6.0/Release.key
    apt-key add - < Release.key 
    apt-get update
    apt-get install apache2 owncloud roundcube
    

    При появлении запроса выберите dbconfig, а затем скажите, что хотите, чтобы roundcube использовал mysql. Затем укажите пароль root mysql и установите хороший пароль для пользователя mysql roundcube. Затем отредактируйте конфигурационный файл roundcube /etc/roundcube/main.inc.php, чтобы при входе в roundcube по умолчанию использовался ваш IMAP-сервер:

    $rcmail_config['default_host'] = 'ssl://localhost';
    $rcmail_config['default_port'] = 993;
    

    Теперь мы настроим веб-сервер apache2 с SSL, чтобы мы могли общаться с Owncloud и Roundcube, используя шифрование для наших паролей и данных. Включим ssl-модуль Apache:

    a2enmod ssl
    

    и отредактируйте /etc/apache2/ports.conf, чтобы установить следующие параметры:

    NameVirtualHost *:80
    Listen 80
    ServerName www.jhausse.net
    
    <IfModule mod_ssl.c>
        # If you add NameVirtualHost *:443 here, you will also have to change
        # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
        # to <VirtualHost *:443>
        # Server Name Indication for SSL named virtual hosts is currently not
        # supported by MSIE on Windows XP.
        NameVirtualHost *:443
        Listen 443
    </IfModule>
    
    <IfModule mod_gnutls.c>
        Listen 443
    </IfModule>
    

    Хорошо настройте веб-сайт по умолчанию для зашифрованных подключений к веб-серверу как https://www.jhausse.net в /var/www. Отредактируйте /etc/apache2/sites-available/default-ssl:

    <VirtualHost _default_:443>
            ServerAdmin 
    
            DocumentRoot /var/www
            ServerName www.jhausse.net
            [...]
            <Directory /var/www/owncloud>
              Deny from all
            </Directory>
            [...]
            SSLCertificateFile    /etc/ssl/certs/cloud.crt
            SSLCertificateKeyFile /etc/ssl/private/cloud.key
            [...]
    </VirtualHost>
    

    и давайте также настроим веб-сайт для незашифрованных подключений к http://www.jhausse.net в /var/www. Отредактируйте /etc/apache2/sites-available/default:

    <VirtualHost _default_:443>
            DocumentRoot /var/www
            ServerName www.jhausse.net
            [...]
            <Directory /var/www/owncloud>
              Deny from all
            </Directory>
    </VirtualHost>
    

    Таким образом, мы можем обслуживать страницы для www.jhausse.net, помещая их в /var/www. Директива Deny from all запрещает доступ к Owncloud через www.jhausse.net: вместо этого мы настроим ее для доступа через https://cloud.jhausse.net.

    Теперь мы настроим веб-почту (roundcube), чтобы к ней можно было получить доступ через https://webmail.jhausse.net. Отредактируйте /etc/apache2/sites-available/roundcube, чтобы иметь следующее содержимое:

    <IfModule mod_ssl.c>
    <VirtualHost *:443>
            ServerAdmin 
    
            DocumentRoot /var/lib/roundcube
    	# The host name under which you'd like to access the webmail
            ServerName webmail.jhausse.net
            <Directory />
                    Options FollowSymLinks
                    AllowOverride None
            </Directory>
    
            ErrorLog ${APACHE_LOG_DIR}/error.log
    
            # Possible values include: debug, info, notice, warn, error, crit,
            # alert, emerg.
            LogLevel warn
    
            CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
    
            #   SSL Engine Switch:
            #   Enable/Disable SSL for this virtual host.
            SSLEngine on
    
            # do not allow unsecured connections
            # SSLRequireSSL
            SSLCipherSuite HIGH:MEDIUM
    
            #   A self-signed (snakeoil) certificate can be created by installing
            #   the ssl-cert package. See
            #   /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
            #   If both key and certificate are stored in the same file, only the
            #   SSLCertificateFile directive is needed.
            SSLCertificateFile    /etc/ssl/certs/cloud.crt
            SSLCertificateKeyFile /etc/ssl/private/cloud.key
    
            # Those aliases do not work properly with several hosts on your apache server
            # Uncomment them to use it or adapt them to your configuration
            Alias /program/js/tiny_mce/ /usr/share/tinymce/www/
    
            # Access to tinymce files
            <Directory "/usr/share/tinymce/www/">
                    Options Indexes MultiViews FollowSymLinks
                    AllowOverride None
                    Order allow,deny
                    allow from all
            </Directory>
    
            <Directory /var/lib/roundcube/>
                    Options +FollowSymLinks
                    # This is needed to parse /var/lib/roundcube/.htaccess. See its
                    # content before setting AllowOverride to None.
                    AllowOverride All
                    order allow,deny
                    allow from all
            </Directory>
    
            # Protecting basic directories:
            <Directory /var/lib/roundcube/config>
                    Options -FollowSymLinks
                    AllowOverride None
            </Directory>
    
            <Directory /var/lib/roundcube/temp>
                    Options -FollowSymLinks
                    AllowOverride None
                    Order allow,deny
                    Deny from all
            </Directory>
    
            <Directory /var/lib/roundcube/logs>
                    Options -FollowSymLinks
                    AllowOverride None
                    Order allow,deny
                    Deny from all
            </Directory>
    
            <FilesMatch "\.(cgi|shtml|phtml|php)$">
                    SSLOptions +StdEnvVars
            </FilesMatch>
            <Directory /usr/lib/cgi-bin>
                    SSLOptions +StdEnvVars
            </Directory>
            #   SSL Protocol Adjustments:
            #   The safe and default but still SSL/TLS standard compliant shutdown
            #   approach is that mod_ssl sends the close notify alert but doesn't wait for
            #   the close notify alert from client. When you need a different shutdown
            #   approach you can use one of the following variables:
            #   o ssl-unclean-shutdown:
            #     This forces an unclean shutdown when the connection is closed, i.e. no
            #     SSL close notify alert is send or allowed to received.  This violates
            #     the SSL/TLS standard but is needed for some brain-dead browsers. Use
            #     this when you receive I/O errors because of the standard approach where
            #     mod_ssl sends the close notify alert.
            #   o ssl-accurate-shutdown:
            #     This forces an accurate shutdown when the connection is closed, i.e. a
            #     SSL close notify alert is send and mod_ssl waits for the close notify
            #     alert of the client. This is 100% SSL/TLS standard compliant, but in
            #     practice often causes hanging connections with brain-dead browsers. Use
            #     this only for browsers where you know that their SSL implementation
            #     works correctly.
            #   Notice: Most problems of broken clients are also related to the HTTP
            #   keep-alive facility, so you usually additionally want to disable
            #   keep-alive for those clients, too. Use variable "nokeepalive" for this.
            #   Similarly, one has to force some clients to use HTTP/1.0 to workaround
            #   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
            #   "force-response-1.0" for this.
            BrowserMatch "MSIE [2-6]" \
                    nokeepalive ssl-unclean-shutdown \
                    downgrade-1.0 force-response-1.0
            # MSIE 7 and newer should be able to use keepalive
            BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
    </VirtualHost>
    </IfModule>
    

    и объявите сервер в своем DNS, например:

    webmail.jhausse.net.	300	IN	CNAME	cloud.jhausse.net.
    

    Теперь давайте включим эти три веб-сайта

    a2ensite default default-ssl roundcube
    service apache2 restart
    

    и веб-почта, доступная по адресу https://webmail.jhausse.net, в основном должна работать. Войдите в систему, используя полный адрес электронной почты (например, [email ) и пароль, который вы установили в базе данных почтового сервера в начале этой статьи. При первом подключении браузер предупредит вас, что сертификат не подписан центром сертификации. Все в порядке, просто добавьте исключение.

    И последнее, но не менее важное: мы создадим виртуальный хост для owncloud, поместив следующий контент в /etc/apache2/sites-available/owncloud:

    <IfModule mod_ssl.c>
    <VirtualHost *:443>
            ServerAdmin 
    
            DocumentRoot /var/www/owncloud
            ServerName cloud.jhausse.net
            <Directory />
                    Options FollowSymLinks
                    AllowOverride None
            </Directory>
            <Directory /var/www/owncloud>
                    Options Indexes FollowSymLinks MultiViews
                    AllowOverride All
                    Order allow,deny
                    allow from all
            </Directory>
    
            ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
            <Directory "/usr/lib/cgi-bin">
                    AllowOverride None
                    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                    Order allow,deny
                    Allow from all
            </Directory>
    
            ErrorLog ${APACHE_LOG_DIR}/error.log
    
            # Possible values include: debug, info, notice, warn, error, crit,
            # alert, emerg.
            LogLevel warn
    
            CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
    
            #   SSL Engine Switch:
            #   Enable/Disable SSL for this virtual host.
            SSLEngine on
    
            # do not allow unsecured connections
            # SSLRequireSSL
            SSLCipherSuite HIGH:MEDIUM
            SSLCertificateFile    /etc/ssl/certs/cloud.crt
            SSLCertificateKeyFile /etc/ssl/private/cloud.key
    
            <FilesMatch "\.(cgi|shtml|phtml|php)$">
                    SSLOptions +StdEnvVars
            </FilesMatch>
            <Directory /usr/lib/cgi-bin>
                    SSLOptions +StdEnvVars
            </Directory>
    
            BrowserMatch "MSIE [2-6]" \
                    nokeepalive ssl-unclean-shutdown \
                    downgrade-1.0 force-response-1.0
            # MSIE 7 and newer should be able to use keepalive
            BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
    </VirtualHost>
    </IfModule>
    

    и активируйте owncloud, запустив

    a2ensite owncloud
    service apache2 reload
    

    Затем настройте owncloud, подключившись к https://cloud.jhausse.net/ в веб-браузере.

    Вот и все! Теперь у вас есть собственный Google Диск, Календарь, Контакты, Dropbox и Gmail! Наслаждайтесь вновь восстановленной конфиденциальностью! :-)

    <имя=синхронизация>

    Синхронизируйте свои устройства с облаком

    <имя=синхронизация>

    Для синхронизации электронной почты вы можете просто использовать свой любимый почтовый клиент: стандартную почтовую программу на Android или iOS, k9mail или Thunderbird на вашем ПК. Или вы также можете использовать веб-почту, которую мы настроили.

    Как синхронизировать календарь и контакты с облаком описано в документе owncloud. На Android я использую приложения CalDAV-Sync и CardDAV-Sync, которые действуют как мосты между календарем Android и приложениями для контактов на телефоне и сервером owncloud.

    Для файлов существует Android-приложение под названием Owncloud для доступа к вашим файлам с вашего телефона и автоматической загрузки фотографий и видео, которые вы снимаете, в свое облако. Доступ к вашим файлам на вашем Mac/ПК прост и хорошо описан в документации Owncloud.

    <имя=подсказки>

    Последние советы

    <имя=подсказки>

    В течение первых нескольких недель рекомендуется ежедневно отслеживать /var/log/syslog и /var/log/mail.log и следить за тем, чтобы все работало гладко. Важно сделать это до того, как вы пригласите других (друзей, семью и т. д.) на свой сервер; вы можете навсегда потерять их доверие к самостоятельному хостингу, если они доверят вам свои данные, а сервер внезапно станет недоступен.

    Чтобы добавить другого пользователя электронной почты, просто добавьте строку в таблицу virtual_users базы данных почтового сервера.

    Чтобы добавить домен, просто добавьте строку в таблицу virtual_domains. Затем обновите /etc/opendkim/SigningTable, чтобы подписывать исходящие электронные письма, загрузите ключ OpenDKIM в зону и перезагрузите OpenDKIM.

    Owncloud имеет собственную базу данных пользователей, которой можно управлять, войдя в Owncloud как администратор.

    Наконец, важно заранее подумать о решении на случай, если ваш сервер временно станет недоступным. Например, куда будут отправляться ваши письма, пока ваш сервер не вернется? Одним из решений было бы найти друга, который может выступать в качестве вашего резервного MX, в то время как вы выступаете в качестве его резервного MX (см. настройку relay_domains и relay_recipient_maps в файле Postfixs main.cf). Точно так же, что, если ваш сервер скомпрометирован и злоумышленник удалит все ваши файлы? Для этого важно подумать о регулярной системе резервного копирования. Linode предлагает резервное копирование в качестве опции. На 1984.is я настроил базовую, но достаточную систему автоматического резервного копирования, используя crontabs и scp.