Email

Как всем известно, протокол отправки электронной почты 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] , поиск выполняется в следующем порядке: ...

Я в процессе настройки своего почтового сервера. Эта заметка касается авторизации, которая допускает не шифрованный пароль и шифрованный. Используется Exim4 + Dovecot2 + PostfixAdmin 1. Файл /etc/exim4/exim4.conf - ставишь такую секцию которую я привел: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 begin authenticators auth_plain: driver = dovecot public_name = PLAIN server_socket = /var/run/dovecot/auth-client server_set_id = $auth1 auth_login: driver = dovecot public_name = LOGIN server_socket = /var/run/dovecot/auth-client server_set_id = $auth2 auth_cram_md5: driver = dovecot public_name = CRAM-MD5 server_socket = /var/run/dovecot/auth-client server_set_id = $auth3 2. В файле /var/www/html/postfixadmin/config.inc.php меняешь настройки алгоритмов на: 1 2 $CONF['encrypt'] = 'dovecot:CRAM-MD5'; $CONF['dovecotpw'] = "/usr/bin/doveadm pw"; 3. Файл /var/www/html/roundcube/config/main.inc.php - меняешь алгоритм на cram-md5: 1 $rcmail_config['imap_auth_type'] = cram-md5; 4. Файл /etc/dovecot/dovecot.conf - меняешь алгоритмы авторизации на plain,login и cram-md5: 1 auth_mechanisms = plain login cram-md5 5. Файл /etc/dovecot/dovecot-mysql.conf - ставишь: 1 default_pass_scheme = CRAM-MD5 Так же можно авторизоваться Exim’ом непосредственно в Mysql базе данных (но у меня этот способ не особо заработал): ...

Продолжаю настройку своего почтового сервера. В этой заметке речь будет о проверке DKIM у входящих сообщений с помощью Exim. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 # Добавляем в список ACL для обработки: acl_smtp_dkim = acl_check_dkim # ... # Можно разместить в начале, где задаются переменные для DKIM-отправки # Это значит, чьи подписи мы будем точно проверять DKIM_KNOWN_SIGNERS = paypal.com : gmail.com dkim_verify_signers = $dkim_signers : KNOWN_DKIM_SIGNERS # ... # Создаем сам ACL в секции "begin acl" # ... # DKIM check acl_check_dkim: accept hosts = +relay_from_hosts accept authenticated = * # Message without sign accept dkim_status = none condition = ${if eq {$acl_c_dkim_hdr}{1} {no}{yes}} set acl_c_dkim_hdr = 1 add_header = :at_start:X-DKIM: Exim 4.71 on $primary_hostname (no dkim signature) # Message with sign, begin warn condition = ${if eq {$acl_c_dkim_hdr}{1} {no}{yes}} set acl_c_dkim_hdr = 1 add_header = :at_start:X-DKIM: Exim 4.71 on $primary_hostname # Message with sign, bad signature deny dkim_status = fail message = Rejected: $dkim_verify_reason logwrite = X-Auth: DKIM test failed: (address=$sender_address domain=$dkim_cur_signer), signature is bad. # Message with sign, invalid signature accept dkim_status = invalid add_header = :at_start:Authentication-Results: $primary_hostname $dkim_cur_signer ($dkim_verify_status); $dkim_verify_reason logwrite = X-Auth: DKIM test passed (address=$sender_address domain=$dkim_cur_signer), but signature is invalid. # Message with sign, good signature accept dkim_status = pass add_header = :at_start:Authentication-Results: $primary_hostname; dkim=$dkim_verify_status header.i=@$dkim_cur_signer logwrite = X-Auth: DKIM test passed (address=$sender_address domain=$dkim_cur_signer), good signature. accept

Такая себе мини заметка, оказывается в exim уже интегрирован механизм смены email адреса отправителя. В debian пакетах так точно. Достаточно в файл /etc/email-addresses добавить то, что нам нужно. Стандартное содержимое файла # cat /etc/email-addresses 1 2 3 4 5 6 7 8 9 # This is /etc/email-addresses. It is part of the exim package # # This file contains email addresses to use for outgoing mail. Any local # part not in here will be qualified by the system domain as normal. # # It should contain lines of the form: # #user: [email protected] #otheruser: [email protected]

На одном из серверов крутятся несколько сайтов, но почта с этих сайтов должна рассылаться с другого сервера. Пришлось искать решение вопроса. И оно нашлось… По сути работает условие, если домен отправителя равен указанному нами домену, то почта отправляется на smarthost, который в свою очередь принимает почту от первого сервера без авторизации. Настраивалось это на Ubuntu, Debian с этим чудным конфигом… На CentOS, RedHat будет немного проще. Открываем на редактирование файл /etc/exim4/exim4.conf.template Добавляем блок smart_route 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 begin routers smart_route: condition = ${extract{smart_host}{${lookup{$sender_address_domain}lsearch{/etc/exim4/staticroutes}{$value}fail}}} driver = manualroute transport = remote_smtp route_list = "* ${extract{smart_host}{${lookup{$sender_address_domain}lsearch{/etc/exim4/staticroutes}{$value}fail}}}" #smarthost: # driver = manualroute # domains = ! +local_domains # transport = remote_smtp # route_list = * smartrelay.domain.com # no_more # no_verify dnslookup: driver = dnslookup domains = !+local_domains transport = remote_smtp no_more Остальное приведено для примера, т.е. по сути добавляем блок сразу после begin routers. Вторым шагом создаём файл /etc/exim4/staticroutes с содержимым ...

Создаём директорию 1 mkdir /etc/exim/dkim Генерируем ключ 1 openssl genrsa -out /etc/exim/dkim/example.com.key 1024 из него генерируем публичную часть ключа 1 openssl rsa -in /etc/exim/dkim/example.com.key -out /etc/exim/dkim/example.com.key.pub -pubout Прописываем в DNS публичную часть ключа 1 mail._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..." Проверяем что запись корректно добавилась на DNS dig mail._domainkey.example.com TXT Настраиваем Exim 1 2 3 4 5 6 7 8 9 10 11 12 13 14 begin transports # тут добавляем наш DKIM DKIM_DOMAIN = ${lc:${domain:$h_from:}} DKIM_FILE = /etc/exim/dkim/${lc:${domain:$h_from:}}.key DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}} remote_smtp: driver = smtp dkim_domain = DKIM_DOMAIN dkim_private_key = DKIM_PRIVATE_KEY dkim_selector = mail dkim_canon = relaxed dkim_strict = yes Не забываем перезагрузить Exim (service exim reload) Параллельно обычно приходится настраивать SPF и DMARC. Это не сложно. Добавляем на DNS подобные записи: 1 2 example.com. IN TXT "v=DMARC1\;p=reject" example.com. IN TXT "v=spf1 mx a ip4:222.222.222.222 ~all" 222.222.222.222 это IP для примера, обычно приходится прописывать, когда почта отправляется с интерфейсного IP, который не совпадает с записями A, MX… статья не закончена

DKIM является системой для проверки отправителя и целостности сообщений. ISPConfig 3 использует amavisd-new, в качестве фильтра контента для проверки на спам и вирусы, а также amavisd-new может подписывать сообщения с помощью DKIM. Следующие действия объясняют, как настроить amavisd-new для подписи сообщений для домена “example.com” с помощью DKIM. Данные действия должны работать с любой версией amavisd-new, даже если Вы не используете ISPConfig. Создайте ключ домена: 1 2 mkdir /var/db/dkim/ amavisd genrsa /var/db/dkim/example-foo.key.pem Настройте amavisd для использование этого ключа для домена example.com. Отредактируйте файл конфигурации: vim /etc/amavisd/amavisd.conf и добавьте следующие строки: 1 2 3 4 5 6 7 $enable_dkim_verification = 1; $enable_dkim_signing = 1; dkim_key('example.com', 'foo', '/var/db/dkim/example-foo.key.pem'); @dkim_signature_options_bysender_maps = ( { '.' => { ttl => 21*24*3600, c => 'relaxed/simple' } } ); @mynetworks = qw(0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16); # list your internal networks Выполните команду amavisd showkeys чтобы получить открытый ключ, который должен быть добавлен как текст на DNS-сервер сервера example.com. Проверьте настройку с помощью команды: amavisd testkeys и если все работает правильно, перезапустите amavisd: /etc/init.d/amavis restart Вот более подробное описание из руководства по amavisd-new о том, как установить DKIM в amavisd-new: http://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim Оригинал статьи на www.faqforge.com Перевод хостинг КОМТЕТ komtet.ru

Практическое руководство по отправке Email сообщений из консоли Linux. Вы узнаете как: Отладить отправку сообщений с локального MTA сервера; Проверить отправку Email из PHP; Как прикрепить файл к Email сообщению из консоли; Отправить сообщение из консоли: 1 echo "BODY" | mail -s "SUBJECT" [email protected] Составить сообщение в консоли: 1 2 3 4 mail [email protected] Cc: <оставляем пустым> Subject: вводим заголовок и для отправки жмем Ctrl+D или Enter и заполним тело сообщения.. Null message body; hope that's ok Проверка PHP ф-ции mail(): 1 php -r "mail('[email protected]', 'Subject', 'Body');" Аттач файла к Email сообщению: 1 mutt -a "/home/stas/attach.pdf" -s "Subject" -- [email protected] Источник

postsuper -d ALL deferred Кстати, вот ещё небольшое уточнение по поводу отличия папок defer от deferred: /var/spool/postfix/defer – тут хидеры /var/spool/postfix/deferred – а тут тушки писем Источник