Email

Заметил в отлупах от почтовых серверов что моя почта не принимается серверами hotmail.com, live.com, msn.com, outlook.com. Ошибка выглядит примерно следующим образом: 1 2 SMTP error from remote mail server after MAIL FROM:<[email protected]> SIZE=3316: host mx4.hotmail.com [65.54.188.94]: 550 SC-001 (BAY004-MC2F18) Unfortunately, messages from 78.xxx.117.xxx weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. Для домена всё давно настроено, SPF, DKIM, DMARC. В интернете отыскал что можно перейти по ссылке https://support.live.com/eform.aspx?productKey=edfsmsbl3&ct=eformts http://go.microsoft.com/fwlink/?LinkID=614866 и заполнить её. По идее, после этого они должны рассмотреть заявку на исключение нашего IP адреса из своих блэк листов и будет ещё плюсик нашему почтовому серверу. Пока что пришло только автоматическое уведомление о принятом тикете. Ждём ответа.

Часто при использовании sendmail отправителем почтовых сообщений с сервера становится пользователь, от которого запущен вэб сервер, в нашем случае apache. Для исправления этой ситуации можно применить следующий конфиг: Это в конфиге виртуального хоста apache 1 php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f [email protected]" Это в конфиге exim 1 trusted_users = apache

Office 365 https://sender.office.com/ https://www.rackaid.com/blog/spam-blacklist-removal/

Настраиваю сейчас EXIM+много чего ещё, в том числе CLAMAV на Ubuntu 16.04 LTS. Добавил пользователя clamav в группу Debian-exim, 1 usermod -G Debian-exim clamav но в логе всё равно упорно получаю 1 1dfRUU-0001m6-V5 malware acl condition: clamd: ClamAV returned: /var/spool/exim4/scan/1dfRUU-0001m6-V5/1dfRUU-0001m6-V5.eml: lstat() failed: Permission denied. ERROR Решение было найдено не быстро, только на второй день. Оказывается нужно в конфигурационных файлах 1 2 /etc/clamav/freshclam.conf /etc/clamav/clamd.conf изменить параметр на “yes” 1 AllowSupplementaryGroups yes Обновление 2019 На CentOS 7 пришлось выполнить 1 2 chmod -Rf g+w /var/spool/exim chmod -Rf g+s /var/spool/exim А вот freshclam пытался почему-то постоянно получить обновления по IPv6, которого на сервере небыло. Пришлось дропнуть его базу /var/lib/clamav/mirrors.dat и после этого всё заработало.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 begin routers ... autoreplay: driver = accept require_files = /etc/exim/autoreply/$domain/autoreply.${local_part}.msg condition = ${if exists{/etc/exim/autoreply/$domain/autoreply.${local_part}.msg}{yes}{no}} retry_use_local_part transport = userautoreply unseen begin transports ... userautoreply: driver = autoreply file = /etc/exim/autoreply/$domain/autoreply.${local_part}.msg from = "${local_part}@${domain}" subject = "${if def:h_Subject: {Autoreply: \"${rfc2047:$h_Subject:}\"} {Autoreply Message}}" headers = Content-Type: text/plain; charset=utf-8;\nContent-Transfer-Encoding: 8bit to = "${sender_address}"

В этой заметке вы сможете узнать о том что dovecot поддерживает ip-based, domain-based конфигурации для SSL. 1 2 3 4 5 6 7 8 9 local 10.10.10.11 { ssl_cert = </home/domain0/ssl.cert ssl_key = </home/domain0/ssl.key } local 10.10.10.12 { ssl_cert = </home/domain1/ssl.cert ssl_key = </home/domain2/ssl.key } При этом необходимо убрать из конфигурации SSL сертификаты, которые вне этих секций. Так же можно указывать SSL сертификаты для доменов: 1 2 3 4 5 6 7 8 9 local_name mail.domain0.com { ssl_cert = </home/domain0/ssl.cert ssl_key = </home/domain0/ssl.key } local_name mail.domain1.com { ssl_cert = </home/domain1/ssl.cert ssl_key = </home/domain1/ssl.key }

В этой статье добавлю варианты как можно разделить по IP адресам почтовые домены. Очень мало воды и много конфигов. Выбор SSL сертификата на основании домена 1 2 tls_certificate = ${if exists{/etc/ssl/${tls_sni}.crt}{/etc/ssl/${tls_sni}.crt}{/etc/ssl/default_domain.crt}} tls_privatekey = ${if exists{/etc/ssl/${tls_sni}.key}{/etc/ssl/${tls_sni}.key}{/etc/ssl/default_domain.key}}​ где сертификаты должны лежать по пути /etc/ssl/domain.com.crt, а ключи — /etc/ssl/domain.com.key. В случае, если для какого-то домена не будет сертификата, то будет использоваться сертификат по умолчанию — /etc/ssl/default_domain.crt (и соответствующий ключ /etc/ssl/default_domain.key) Обращаю внимание что этот вариант может корректно не работать со STARTTLS. Выбор SSL сертификата на основании сравнения IP адреса и домена 1 2 tls_certificate = ${lookup{$received_ip_address}lsearch{/etc/exim/ips_in.conf}{/opt/mail/ssl/$value.pem}{/opt/mail/ssl/domain.com.cer}} tls_privatekey = ${lookup{$received_ip_address}lsearch{/etc/exim/ips_in.conf}{/opt/mail/ssl/$value.key}{/opt/mail/ssl/domain.com.key}} Используется файл вида: 1 2 3 # cat /etc/exim/ips_in.conf 8.140.110.229: mail2.domain.com 8.140.110.228: mail2.domain2.com Что бы сервер представлялся нужным доменом, правим transports remote_smtp (указывем helo_data): 1 2 3 4 5 remote_smtp: driver = smtp ... helo_data = $sender_address_domain ... Ещё варианты будут описаны ниже. Для выбора IP во время отправки почты и для представления сервера можно использовать конфигурацию 1 2 3 4 remote_smtp: driver = smtp + interface = ${if exists {/etc/exim/ips_out.conf}{${lookup{$sender_address_domain}lsearch{/etc/exim/ips_out.conf}{$value}{}}}{}} + helo_data = ${lookup dnsdb{ptr=$sending_ip_address}{$value}{$primary_hostname}} Здесь мы выбираем какой интерфейс использовать при отправке почты на основании данных в файле, который описан ниже. А так же представляемся именем домена из PTR этого IP адреса. ...

В этом кратком руководстве описаны шаги, которые вы можете использовать, чтобы настроить SMTP AUTH для работы с пакетом exim4 Debian Sarge. (Для пользователей, подключающихся к вашему серверу, а не для пересылки через интернет-провайдера) Первоначально нужно сгенерировать Exim SSL сертификат: 1 /usr/share/doc/exim4-base/examples/exim-gencert Теперь отредактируем /etc/exim4/exim4.conf.template используя любимый текстовый редактор. Раскомментируйте следующие строки: Не копируйте со страницы, потому что форматирование может быть нарушено 1 2 3 4 5 6 7 8 9 plain_server: driver = plaintext public_name = PLAIN server_condition = "${if crypteq{$auth3}{${extract{1}{:}{${lookup{$auth2}lsearch{CONFDIR/passwd}{$value}{*:*}}}}}{1}{0}}" server_set_id = $auth2 server_prompts = : .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}} .endif Как только вы это сделаете, создайте файл (или отредактируйте, если он уже существует) /etc/exim4/exim4.conf.localmacros Добавьте строку: MAIN_TLS_ENABLE = true Для добавления пользователей и паролей, создайте файл /etc/exim4/passwd Скопируйте вывод комманды: htpasswd -nd usernameforsmtp И вставьте в файл /etc/exim4/passwd Повторите для любых других логинов, которые вам нужно добавить. Готово. Обновляем конфигурацию и перезапускаем Exim4: 1 2 update-exim4.conf /etc/init.d/exim4 restart

Как всем известно, протокол отправки электронной почты SMTP, подразумевает, что в качестве отправителя можно указать любой почтовый ящик. Таким образом можно послать письмо, подставив в поле “From” вымышленное значение. Процесс такого почтового обмана называется Спуфинг (e-mail spoofing). Чтобы бороться с этим явлением, был разработан и введен в действие стандарт SPF – Sender Policy Framework (структура политики отправителя). SPF позволяет владельцу домена указать в TXT-записи домена специальным образом сформированную строку, указывающую список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене. Рассмотрим простой пример SPF-записи. 1 example.org. IN TXT "v=spf1 +a +mx -all" Теперь более детально о допустимых опциях. Рассмотрим варианты поведения получателя, в зависимости от используемых опций: v=spf1 - используемая версия SPF. + - принимать корреспонденцию (Pass). Этот параметр установлен по умолчанию. Тоесть, если никаких параметров не установлено, то это “Pass”; - - Отклонить (Fail); ~ - “мягкое” отклонение (SoftFail). Письмо будет принято, но будет помечено как СПАМ; ? - нейтральное отношение; mx - включает в себя все адреса серверов, указанные в MX-записях домена; ip4 - опция позволяет указать конкретный IP-адрес или сеть адресов; a - указываем поведение в случае получения письма от конкретного домена; include - включает в себя хосты, разрешенные SPF-записью указанного домена; all - все остальные сервера, не перечисленные в SPF-записи. Итак, попробуем разобраться, что же значит SPF-запись, указанная выше. +a - разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org; +mx - разрешает прием писем, если отправляющий хост указан в одной из MX-записей для example.org; -all - все сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать. Для лучшего понимания того, как работает SPF, рассмотрим еще один, более сложный пример. ...

Thunderbird начиная с версии 3.1 (and 3.0 to some degree) включают в себя функционал автоконфигурации почтового аккаунта. Цель автоконфигурации в создании для пользователей более простого способа настроить соединение клиента с почтовым сервером. В большинстве случаев, пользователь лишь должен загрузить и установить приложение, ввести свое настоящее имя, почтовый адрес и пароль в настройках аккаунта и почтовый клиент полностью готов к работе для получения и отправки писем, настолько безопасной, насколько это возможно . Способы получения настроек Thunderbird получает настройки сервера различными способами, каждый из них предназначен для своего случая: ISPDB ISPDB - это центральная база данных, которая в настоящий момент принадлежит коммерческой организации Mozilla Messaging, но может быть использована любым клиентом. Она содержит настройки для крупнейших почтовых провайдеров. Мы надеемся что эта база в ближайшем времени будет содержать достаточно информации для автоконфигурирования не менее половины почтовых аккаунтов пользователей. Эта база была добавлена из-за нашей уверенности в том, что не все почтовые провайдеры (в том числе Microsoft) сразу же добавят файлы конфигурации для Thunderbird на своих сервера. Конфигурация сервера почтового провайдера Почтовые провайдеры могут предоставить информацию о своих настройках для пользователей, настроив автоконфигурацию на своем сервере. <домен>, который просто возвращает статический XML с настройками, как описано ниже. При более сложных настройках, когда, например, логин не отображается в почтовом адресе XML-файл может быть также сгенерирован провайдером. В таких случаях это единственный способ получить автоматическую настройку. Файл конфигурации на жестком диске Администраторы могут поместить файл конфигурации в установочную папку Thunderbird. Этот способ предназначен для компаний, которые устанавливают Thunderbird на компютеры своих сотрудников и хотят получить легкую настройку учетной записи без необходимости настраивать конфигурацию почтового сервера. Этот метод не стоит применять в других случаях, потому что обновлять файл конфигурации весьма трудно. Таким образом, публичным провайдерам рекомендуется использовать конфигурации сервера. Подборка наугад В том случае, когда другими способами определить настройки не получилось, Thunderbird пытается угадать конфигурацию, пробуя распространенные имена почтовых серверов типа imap.<domain>, smtp.<domain>, mail.<domain> и так далее, и, когда сервер отвечет, проверяет поддержку SSL, STARTTLS и шифрование паролей (CRAM-MD5). Ручная настройка Если угадать не получается, пользователь должен ввести настройки вручную. Пользователь может также изменить настройки, даже если они были получены способами описанными выше. Все механизмы поиска используют домен почтового адреса в качестве основы для поиска. Например, для почтового адреса [email protected] , поиск выполняется в следующем порядке: ...