30 Апрель 2017

Параллельное использование Google mail и сервера Exim для домена

Concurrent use of Google mail and Exim server for domain

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

Казалось бы, ваша корпоративная почта на Google mail получает лишь одни преимущества, к примеру, в виде стандартизированного интерфейса, качественной защиты от спама, наличие общего календаря и доступа к документам. И всё это при простом развёртывании и высокой надёжности системы.

Однако, как и во всякой бочке мёда, здесь возможно отыскать и предостаточно дёгтя. Причём дёгтя настолько горького, что под сомнение может быть поставлена сама целесообразность такого подхода. Особенно болезненным понимание проблем, ограничений и даже угроз, которое может нести использование Google mail для поддержки корпоративной почты может стать для тех, кто изначально полностью положился на такое решение.

Но, обо всё по порядку.

1. Что не так с Google mail?

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

1.1. Платность

Стоимость использования одного почтового ящика в предоставляемых сервисах для доменов у Google mail составляет 5 USD в месяц и 50 USD в год. При наличии небольшого штата сотрудников эти суммы в совокупности могут быть несущественными, но по мере роста расходы могу расти. Например, 10 почтовых ящиков обойдутся вам уже минимум в 500 USD в год.

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

1.2. Безопасность

Google mail, как бы то нибыло, является сторонней организацией. Доверять ей полностью, особенно если речь идёт о важной коммерческой информации, вряд ли разумно. А, тем более, это не разумно, если речь идёт о зарегистрированной в России компании.

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

Кроме того, благодаря системе восстановления паролей в Google mail и системе подверждения владельца посредством SMS на номер мобильного телефона как её части, по причине фундаментальных проблем в системах телекоммуникации (см. ОКС-7) при наличии технического подключения к ним существует возможность получения данных аутентификации почтового ящика и, следовательно, несанкционированного доступа к переписке.

1.3. Надёжность

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

1.4. Сканирование содержимого писем

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

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

1.5. Антиспам

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

Влиять на алгоритмы работы спам-фильтров на Google mail пользователь может крайне ограниченно.

1.6. Наличие ограничений

Google mail накладывает ограничения на число отправляемых сообщений и на количество получателей одного сообщения для одного почтового ящика в сутки. Также существуют ограничения и на количество получаемых сообщений. При их превышении осуществляется блокировка ящика на прогрессирующий от раза к разу срок. Кроме того, ограничивается трафик.

Согласитесь, что перспектива лишиться возможности пользоваться электронной почтой является, мягко говоря, малоприятной.

2. Миграция с Google mail

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

Как и всякий процесс, переезд системы электронной почты не должен привести к перерывам в работе. Хорошей идей будет обеспечить возможность параллельного взаимного функционирования почты вашего домена сразу на обоих системах, когда, к примеру, новые ящики будут использоваться уже на своём почтовом сервере, а старые могут без проблем оставаться в рамках привычного Google mail. При этом следует обеспечить возможность быстрого перехода на работу с собственной системой.

Очевидно, что для реализации такого подхода требуется, чтобы весь входящий почтовый траффик домена проходил уже через свой сервер. При этом, в случае нахождения почтового ящика на этом сервере почта доставлялась в него, а в случае отсутствия предпринималась бы попытка доставки уже на Google mail. Заботится же о маршрутизации исходящей почты нужды не возникает ввиду специфики работы протокола SMTP.

Если абстрагироваться от сопутствующих вопросов переноса данных почтового ящика Google mail, а также синхронизации записных книжек и календарей с новой системой (а это, полагаю, может быть темой для отдельной статьи), равно как и организации собственного почтового сервера (информации и массы how-to о чём в достатке имеется в сети), то практическая организация процесса миграции распадается на две подтемы.

2.1. Настройка DNS-сервера

Пусть мы имеем некий my.domain, электронная почта которого успешно работает на Google mail. Предполагаеся, что мы должны обеспечить его работу в параллельном режиме с нашим новым почтовым сервером mail.server.

Для этого, во-первых, следует удалить все относящиеся к Google MX записи из DNS-зоны этого домена, заменив их на адрес своего сервера. Таким образом вместо рекомендуемых Google

my.domain   MX  1   ASPMX.L.GOOGLE.COM
my.domain   MX  5   ALT1.ASPMX.L.GOOGLE.COM
my.domain   MX  5   ALT2.ASPMX.L.GOOGLE.COM
my.domain   MX  10  ALT3.ASPMX.L.GOOGLE.COM
my.domain   MX  10  ALT4.ASPMX.L.GOOGLE.COM

мы будем иметь запись наподобие

my.domain   MX  10  mail.server

Далее, следует обеспечить возможность отправки исходящей почты как от серверов Google mail, так и от нашего сервера, описав политику контроля над ней через запись SPF. Она может приобрести следующий вид.

my.domain IN TXT "v=spf1 +mx include:_spf.google.com -all"

где командой +mx разрешается отправка доменной почты от только что описанного выше в записи MX нашего сервера mail.server, а также через включение путём директивы include мета-домена _spf.google.com, содержащего после цепочки раскрытия все текущие используемые Google серверы исходящей электронной почты. Команда -all запрещает отправку корреспонденции через иные, кроме описанных ранее, узлы в сети Интернет.

И, наконец, идя в ногу со временем и поддерживая использование политик DMARC для нашего домена my.domain, мы должны прописать, помимо самой политики DMARC, также и оба публичных ключа DKIM, которые используются как Google mail, так и нашим новым сервером, для удостоверения подлинности исходящей почты нашего домена. Если для Google используется ключ с именем gookey, а для нашего сервера ourkey, то DNS-записи прибретут вид наподобие

gookey._domainkey.my.domain. IN TXT "v=DKIM1; k=rsa; p="MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB..."
ourkey._domainkey.my.domain. IN TXT "v=DKIM1; k=rsa; p="MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB..."

Тогда применив политику DMARC типа quarantine мы сможем защитить исходящую почту нашего домена от подделки, квалифицировав её на сервера-получателях как спам. Пример такой записи

_dmarc.my.domain. IN TXT "v=DMARC1; p=quarantine; ..."

В том случае, если на одной из двух почтовых систем подписывание почты с использованием технологии DKIM не производится, разумно будет указать политику none.

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

2.2. Настройка SMTP-сервера

Рассмотрим основные моменты в настройке на примере популярного SMTP-сервера Exim. Используется его последняя на момент написания статьи версия со следующими модулями.

root@beta:~ # exim -bV
Exim version 4.89 #0 (FreeBSD 11.0) built 09-Mar-2017 12:55:28
Copyright (c) University of Cambridge, 1995 - 2017
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2017
Probably Berkeley DB version 1.8x (native mode)
Support for: crypteq iconv() IPv6 use_setclassresources PAM Perl Expand_dlfunc TCPwrappers OpenSSL Content_Scanning DKIM DNSSEC Event I18N OCSP PRDR TCP_Fast_Open Experimental_QUEUEFILE Experimental_SPF Experimental_DANE Experimental_DCC Experimental_DMARC
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch mysql nis nis0 passwd
Authenticators: dovecot plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe queuefile smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file is /usr/local/etc/exim/configure

Ввиду того, что каждая конкретная конфигурация Exim может существенно различаться, то остановлюсь на всех основных моментах, на которые следует обратить внимание при её адаптации под нужды параллельного использования данного почтового сервера совместно с Google mail.

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

root@beta:~ # cat /usr/local/etc/exim/configure
# $Cambridge: exim/exim-src/src/configure.default,v 1.14 2009/10/16 07:46:13 tom Exp $
# --- by Max Kostikov (c) 2010...2017 v.20170418
...
# -- Google hosted domains
domainlist ghs_domains          = my.domain
...

Exim при конфигурировании использует механизм правил, т.н. ACL, которые разбиты на несколько групп сообразно стадиям SMTP сессии и функциональному назначению. Пройдёмся правками по этим разделам.

Во-первых, в acl_smtp_rcpt в случае использования механизма защиты от backscatter spam используя BATV следует обратить внимание на исключение из проверки bounces нашего домена, поскольку Google mail его не использует, а даже если бы и использовал, мы не на своём сервере не смогли бы его проверить.

root@beta:~ # cat /usr/local/etc/exim/configure
# $Cambridge: exim/exim-src/src/configure.default,v 1.14 2009/10/16 07:46:13 tom Exp $
# --- by Max Kostikov (c) 2010...2017 v.20170418
...
acl_smtp_rcpt           = acl_check_rcpt
acl_smtp_dkim           = acl_check_dkim
acl_smtp_mime           = acl_check_mime
acl_smtp_data           = acl_check_data
...
begin acl
...
acl_check_rcpt:
...
  # --- reject bounces without signature
  deny   senders        = :
         domains        = !+ghs_domains : +local_domains
         verify         = recipient
         message        = Unsigned return path in bounce
...

Обратите внимание, что наш my.domain входит, разумеется, и в список локальных доменов local_domains, однако по этому правилу он будет исключён из проверки BATV.

Далее, необходимо предусмотреть проверку существования почтовых ящиков на Google mail равно как и на нашем сервере. Это делается следующими правилами в том же acl_smtp_rcpt через механизм внешней проверки callout.

...
  # -- check recipient for Google hosted domains
  deny   domains        = +ghs_domains
        !verify         = recipient/callout=10s
         message        = User not found

  # -- check local users
  deny   domains        = !+ghs_domains : +local_domains
        !verify         = recipient
         message        = User unknown

  # -- check relays
  deny   domains        = +relay_to_domains
        !verify         = recipient
         message        = No route to host
...

В остальном, процессинг входящей почты через набор правил ACL для разнесённого между нашим сервером и Google mail домена, как правило, не отличается.

Существенные отличия имеются на уровне работы роутеров и транспортов Exim.

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

root@beta:~ # cat /usr/local/etc/exim/configure
# $Cambridge: exim/exim-src/src/configure.default,v 1.14 2009/10/16 07:46:13 tom Exp $
# --- by Max Kostikov (c) 2010...2017 v.20170418
...
begin routers
...
# -- local delivery
local_user:
  driver        = accept
  condition     = ...
  transport     = local_delivery

# -- delivery for Google hosted domains
gmail_router:
  driver         = manualroute
  domains        = +ghs_domains
  transport      = smart_smtp
  route_list     = * gmail.com/mx
...
begin transports
...

Наш роутер доставки на Google mail с именем gmail_router использует механизм manualroute для доставки через указанные для основного домена Google mail gmail.com набор записей MX со списком серверов через транспорт smart_smtp. Но более корректным вариантом будет указать рекомендованные Google имена серверов, которые ранее значились в качестве MX в DNS-зоне нашего домена, перечислив их через точку с запятой.

Упомянутый транспорт smart_smtp отличается от стандартного транспорта удалённой доставки используемого нашей системой в части исключения подписывания исходящей почты при помощи DKIM. В данном случае, по понятным причинам (входящая почта), это будет излишне.

...
begin transports
...
smart_smtp:
  driver                = smtp
  return_path           = ${if match{${lookup dnsdb{txt=<;_dmarc.$sender_address_domain;_dmarc.${extract{-2}{.}{$sender_address_domain}}.${extract{-1}{.}{$sender_address_domain}}}{$value}{}}}{\N(?i);\s*p=reject\N}{noreply@tiksi.ru}{$sender_address}}
  interface             = <; 1.2.3.4 ; 1:2:3:4::1
...

Особое внимание обращаю на конструкцию в операторе return_path данного транспорта. С её помощью производится перезапись конверта (envelope-to) который по умолчанию транслируется к Google mail от сервера, отправляющего в адрес нашего домена электронное сообщение на специальный адрес noreply@my.domain в случает если для домена-отправителя используется политика DMARC типа reject. В случае, если бы такая перезапись не делалась, Google mail вынужден был бы отвергнуть такое письмо ввиду того, что наш сервер не имеет полномочий выступать отправителем для домена, направляющего в наш адрес корреспонденцию.

При этом, ввиду того, что наш сервер при пересылке письма на почтовые ящики нашего домена, размещённые на Google mail, не изменяет заголовки и тело письма, которые, скорее всего, подписаны DKIM, и, как уже было упомянуто ранее, и сам его не подписывает, то нет нужды также и переписывать домен в поле From: принимаемого письма.

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

root@beta:~ # tail /var/log/maillog
...
Apr 29 22:10:46 mail.server exim[8043]: 1d4YhZ-00025j-U0 DKIM: d=e2.kuponator.ru s=sender c=relaxed/relaxed a=rsa-sha256 b=1024 [verification succeeded]
Apr 29 22:10:46 mail.server exim[8043]: 1d4YhZ-00025j-U0 DMARC results: spf_domain=e2.kuponator.ru dmarc_domain=kuponator.ru spf_align=yes dkim_align=yes enforcement='Accept'
Apr 29 22:10:47 mail.server exim[8043]: 1d4YhZ-00025j-U0 no IP address found for host mail.e2.kuponator.ru
Apr 29 22:10:47 mail.server exim[8043]: 1d4YhZ-00025j-U0 <= noreply2@e2.kuponator.ru H=srv27-2.kuponator.ru [95.169.187.195] I=[78.40.219.163]:25 P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=130757 id=ac09af7e487d67b5cd652257f5aaa6db@swift.generated from <noreply2@e2.kuponator.ru> for foo@my.domain
Apr 29 22:10:47 mail.server spamd[6939]: spamd: connection from localhost [::1]:59146 to port 783, fd 5
Apr 29 22:10:47 mail.server spamd[6939]: spamd: processing message <ac09af7e487d67b5cd652257f5aaa6db@swift.generated> for foo@my.domain:26
Apr 29 22:10:55 mail.server spamd[6939]: spamd: clean message (3.2/5.0) for foo@my.domain:26 in 7.9 seconds, 130757 bytes.
Apr 29 22:10:55 mail.server spamd[6939]: spamd: result: . 3 - BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E8_51_100,RAZOR2_CHECK,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS,TXREP,URIBL_SBL,URIBL_SBL_A scantime=7.9,size=130757,user=foo@my.domain,uid=26,required_score=5.0,rhost=localhost,raddr=::1,rport=59146,mid=<ac09af7e487d67b5cd652257f5aaa6db@swift.generated>,bayes=0.000000,autolearn=no autolearn_force=no
Apr 29 22:10:55 mail.server exim[8053]: 1d4Yhb-00025t-Ey <= noreply2@e2.kuponator.ru U=mailnull P=sa-checked S=132803 id=ac09af7e487d67b5cd652257f5aaa6db@swift.generated from <noreply2@e2.kuponator.ru> for foo@my.domain
Apr 29 22:10:55 mail.server spamd[6936]: prefork: child states: II
Apr 29 22:10:56 mail.server exim[8059]: 1d4Yhb-00025t-Ey => foo@my.domain R=gmail_router T=smart_smtp H=gmail-smtp-in.l.google.com [2a00:1450:4010:c01::1b] I=[1:2:3:4::1] X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=yes DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com" K C="250 2.0.0 OK d18si5509723lfb.374 - gsmtp"
Apr 29 22:10:56 mail.server exim[8059]: 1d4Yhb-00025t-Ey Completed
Apr 29 22:10:56 mail.server exim[8049]: 1d4YhZ-00025j-U0 => foo <foo@my.domain> R=spamassassin_router T=spamassassin_local
Apr 29 22:10:56 mail.server exim[8049]: 1d4YhZ-00025j-U0 Completed

3. PROFIT!

Статья была полезной? Тогда прошу не стесняться и поддерживать деньгами через PayPal или Яндекс.Деньги.


DNS  exim  DMARC  google