Яндекс — Блог Валерия Леонтьева

Делегирование обслуживания почтового домена: часть 2. Отправка почты через localhost (настройка Exim4 в Debian)

Валера Леонтьев — Sun, 28 Nov 2010 19:18:55 +0000

Настройка Exim и PHP mail() на примере Linux Debian

Чтобы решить проблему отказа серверов Gmail от обслуживания при отправке большого числа писем на несуществующие адреса, используем для отправки почты из скриптов сайта локальный почтовый SMTP-сервер (MTA). Локальный сервер будет выступать в качестве mail relay. В дополнение мы откажемся от подключения из скрипта к удаленному серверу, что может быть медленно. Локальные подключения всегда должны быть быстрее и стабильнее.

Локальный сервер мы будем использовать только для отправки писем. Причем, не важно, как будет происходить отправка: непосредственно через SMTP, или с помощью MUA. Получение почты по-прежнему будет происходить с серверов Gmail.

В дистрибутиве Debian 5 по умолчанию устанавливается MTA Exim4. Он отлично подойдет для наших задач. Причем его настройка производится с помощью мастера и невероятно проста. Настроить сервер требуется на прием соединений исключительно с локального соединения. При этом не нужно поручать ему обслуживание доменов, кроме дефолтного локального (localhost).

Итак, если Exim у вас не установлен, то установим его:

# aptitude install exim4

Далее запускаем его конфигурацию:

# dpkg-reconfigure exim4-config

1. На первом шаге необходимо выбрать конфигурацию сервера. В Exim есть несколько стандартных конфигураций, предназначенных для разных случаев. Подробнее о них в мануале. Нам нужна конфигурация “internet site; mail is sent and received directly using SMTP”.

2. Далее укажите имя сервера. Оно будет передаваться в SMTP-протоколе в команде HELLO, т.е. будет видно получателям вашей почты. Лучше всего, чтобы это имя совпадало с доменом, с которого шлется почта. Например, valera.ws.

Если у вас на сервере несколько сайтов с разными доменами (см. ниже), то лучше это имя сделать нейтральным, чтобы «не палиться». Например, можно выбрать local-mail-agent.

3. Далее требуется указать, какие интерфейсы должен слушать Exim. В нашем случае удаленные подключения мало того, что не нужны, так еще и опасны: кто угодно сможет рассылать почту через ваш сервер. Указываем только 127.0.0.1.

4. Далее спрашивается, какие домены должен обслуживать сервер. Т.е. для каких доменов не нужно пересылать письма на удаленные SMTP-сервера, пользователь заберет их с этого сервера. Нам не нужно обслуживание наших доменов. Можно указать только localhost, т.к. его больше обслужить некому.

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

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

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

При этой конфигурации есть один негативный момент. Если ваш сайт поломают, то злоумышленники смогут слать почту с любых доменов через ваш сервер. Если на сервере 1—2 сайта, то лучше на этом шаге оставить поле пустым, а на предыдущем шаге внести список этих доменов (для возврата на шаг назад нажмите кнопку “Cancel”). При появлении новых доменов не забывайте их заносить в конфиг. Если вы считаете свои сайты надежными, то проще всего указывать здесь 127.0.0.1.

7. Дале уточняется, является ли для нас проблемой постоянные DNS-запросы при отправке каждого письма. В 99,9% это не проблема, так что выбираем ответ на вопрос “Keep number of DNS-queries minimal (Dial-on-Demand)?” “No”.

8. Где хранить локальную почту (помните, мы указали серверу обслуживать домен localhost?) нам по сути не важно, так как этим как правило никто не пользуется. Можно выбрать вариант по умолчанию: складывать все в /var/mail.

9. Предпоследний шаг — выбор конфигурации. Хранить все в одном файле, или раскидать по множеству мелких файлов. В большой файл проще вносить большие изменения, а с мелкими проще работать в случае мелких правок. Выберите вариант на свой вкус. Я выбрал “unsplit configuration” (ответ “No”).

10. На последнем шаге укажем на какой аккаунт реального пользователя системы пересылать сообщения, отправленные на служебные аккаунты postmaster, root и т.д. Здесь имеет смысл указать ваше имя пользователя в системе.

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

Правильная настройка SPF

Если кратко, то SPF — это способ борьбы со спамом.

Мы собираемся отправлять почту с сервера, PTR IP которого не равен одной из MX-записей сервера, а так же в большинстве случаев PTR IP не равен самому нашему домену (не всегда хостеры соглашаются менять PTR). В этом случае вероятность попадания писем в спам повышается. Но есть хороший способ ее понизить: указать правильно запись SPF нашего домена.

SPF-запись — это обыкновенная запись доменной зоны, имеющая тип TXT. Узнать текущее ее значение для домена можно с помощью команды host в Linux:

$ host -t TXT valera.ws
valera.ws TXT record currently not present

В данном примере SPF-запись не задана. Зададим ее. С моего домена почта может отправляться с серверов Gmail и с моего сервера. Для начала узнаем, какой PTR моего сайта (valera.ws):

$ nslookup valera.ws
Server: 194.224.52.4
Address: 194.224.52.4#53

Non-authoritative answer:
Name: valera.ws
Address: 93.174.6.118

IP-адрес моего сервера 93.174.6.118. Узнаем PTR:

$ nslookup 93.174.6.118
Server: 194.224.52.4
Address: 194.224.52.4#53

Non-authoritative answer:
118.6.174.93.in-addr.arpa name = server.valera.ws.

Видно, что PTR IP, к которому привязан мой домен (IP моего сервера) — server.valera.ws.

v=spf1 a mx ptr include:_spf.google.com ~all

По порядку:

v=spf1 — версия SPF (первая);
a — разрешение отправлять почту с IP, указанного в A-записи домена (собственно с сервера, на который ваш домен ссылается);
mx — разрешение отправлять почту с IP, указанных в MX-записях домена (в нашем случае сервера Gmail);
ptr — разрешение отправлять почту с IP, PTR-запись которых содержит ваш домен (т.е. сам домен и поддомены);
include:_spf.google.com — подключение разрешений для серверов отправки почту Gmail (совсем не обязательно почта будет слаться с серверов, указанных в MX-записи);
~all — нейтральная реакция на всю остальную почту; здесь можно указать -all, что будет значить, что почта, не попадающая под эти правила, — спам.

Если вы хотите отправлять почту с сервера, не попадающего под все эти правила, его можно указать по IP или домену PTR, например:

v=spf1 a mx ptr ptr:example.com include:_spf.google.com ~all

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

valera.ws. TXT v=spf1 a mx ptr include:_spf.google.com ~all

После обновления зоны host выдаст следующее:

$ host -t TXT valera.ws
valera.ws TXT «v=spf1 a mx ptr include:_spf.google.com ~all»

PHP mail()

После всей этой настройки функция mail() в PHP начнет слать почту через ваш локальный сервер на законных основаниях для антиспам-ботов. Но косяк будет в том, что в поле отправителя будет фигурировать адрес системного пользователя www-data@localdomain. Нас это не устраивает. Чтобы почта правильно слалась из mail(), необходимо использовать ее дополнительный параметр.

bool mail ( string $to , string $subject , string $message [, string $additional_headers [, string $additional_parameters ]] )

Именно $additional_parameters нас и интерисует. В него надо передавать реального отправителя:

mail($to, $subject, $message, $additional_headers, $additional_parameters.» -frealsender@valera.ws»);

Указывается отправитель слитно с параметром -f.

Теперь отправленные через mail() письма будут абсолютно адекватны (при условии, что вы указываете все нужные SMTP-заголовки, вроде “FROM:”, “TO:” и т.д.).

А если несколько сайтов с разными IP (настройка Exim для отправки писем с разных IP)?

Мы хотим использовать локальный SMTP-сервер для отправки почты со всех сайтов на сервере. Никаких проблем нет, если настроен Exim правильно (см. выше). Но проблема появляется, если разные сайты работают на разных IP. Мы не хотим в почте «палить» то, что все наши сайты живут на одном сервере. Но Exim по умолчанию шлет всю почту с основного (первого) IP сетевого интерфейса, а этот IP всем получателям в SMTP-заголовках “Received:” письма. Кроме того, там указывается и имя сервера, которые мы в случае с разными сайтами на сервере выбрали нейтральными.

Чтобы не «палить» IP сервера, нужно отсылать письмо на удаленный сервер с IP, равного A-записи домена сайта. Делается это несложно путем изменения конфига Exim. Внесем изменения в настройки транспорта SMTP Exim. Если вы выбрали монолитный конфиг, то нужно отредактировать файл:

# nano /etc/exim4/exim4.conf.template

Находим в файле строку “remote_smtp:” (поиск в nano — F6). Добавляем в конец этого блока:

interface = «${lookup{$sender_address_domain}lsearch{/usr/share/exim4/domain2ip}{$value}}»
helo_data = «$sender_address_domain»

Это значит, что при отправке письма нужно определить домен отправителя почты (для sender@valera.ws это valera.ws) и отправить почту с IP, к которому этот домен привязан. Само собой разумеется, что домен должен быть привязан к серверу, где установлен Exim.

Так же нужно создать файл в любом месте файл привязки доменов к IP (у домена может быть несколько IP, так что просто lookup-ить его не прокатит). Я выбрал для файла место: /usr/share/exim4/domain2ip

# nano /usr/share/exim4/domain2ip

Туда вводим наши домены по шаблону:

valera.ws: 123.123.123.123
vasya.ws: 123.123.123.124

Не забудьте дописать домен в файл в случае появления нового сайта.
Кстати, строку helo_data = «$sender_address_domain» можно добавить в файл даже если у вас один IP на все сайты. Тогда в команде HELLO SMTP-протокола (а, следовательно, и в заголовках писем) будет фигурировать ваш домен.

Идея с указанием интерфейса взята отсюда: http://www.directadmin.com/forum/showthread.php?t=36468

Проверка

Остается проверить, чтобы все ваши настройки работали верно. Для этого просто отправим письмо с локального сервера через консоль.

$ mail -a «From:feedbee@valera.ws» -s Test feedbee@gmail.com — -ffeedbee@valera.ws
Test
Cc:

Проверяем отосланное письмо в ящике получателя:

А вот текст SMTP-протокола:

Delivered-To: feedbee@gmail.com
Received: by 10.236.109.139 with SMTP id s11cs13826yhg;
Wed, 24 Nov 2010 02:18:14 -0800 (PST)
Received: by 10.227.145.134 with SMTP id d6mr9025492wbv.195.1290593893066;
Wed, 24 Nov 2010 02:18:13 -0800 (PST)
Return-Path: feedbee@valera.ws
Received: from valera.ws (server.valera.ws [93.174.6.118])
by mx.google.com with ESMTP id b7si11085685wer.164.2010.11.24.02.18.12;
Wed, 24 Nov 2010 02:18:12 -0800 (PST)
Received-SPF: pass (google.com: domain of feedbee@valera.ws designates 93.174.6.118 as permitted sender) client-ip=93.174.6.118;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of feedbee@valera.ws designates 93.174.6.118 as permitted sender) smtp.mail=feedbee@valera.ws
Received: from root by server.valera.ws with local (Exim 4.69)
(envelope-from )
id 1PLCQW-0006KD-Pc
for feedbee@gmail.com; Wed, 24 Nov 2010 10:18:12 +0000
To: feedbee@gmail.com
Subject: Test
From:feedbee@valera.ws
Message-Id: E1PLCQW-0006KD-Pc@server.valera.ws
Date: Wed, 24 Nov 2010 10:18:12 +0000

Test

P.S. Чтобы отправленная почта не попадала в спам, отправляйте письма только от имени реально существующих на серверах Gmail адресов на ваших доменах. Туда же повалятся уведомления о недоставках.

Делегирование обслуживания почтового домена: часть 1. Почта для домена

Валера Леонтьев — Sun, 28 Nov 2010 17:46:27 +0000

Почта для домена

Уже давно стандартом агента электронной почты (MTA) стали веб-приложения типа Gmail. Такие сервисы предоставляют удобный, стабильный быстрый доступ к почте из любого места, хороший поиск писем в ящике, много места для их хранения, отличную защиту от спама. Постепенно все больше и больше людей отказывались от The Bat! и Outlook в пользу Gmail, Yahoo! Mail, Hotmail, Яндекс.Почты.

Но многим хотелось иметь почту на своем домене. Еще несколько лет назад, пользуясь почтой на своем домене, приходилось прибегать к хитростям пересылки и сбора почты, которые были доступны как минимум в Gmail и почте Яндекса. Это вызывало некоторые неудобства.

Первыми догадались бесплатно предлагать полное обслуживание почты на домене Google. В рамках проекта Google for domains (первое название) они предлагали указать MX-записи вашего домена на сервера Google и полностью возложить на себя обслуживание вашей почты, тем самым объединяя качественный сервис и красивое имя ящика.

Постепенно проект Google for domains влился в Google Apps, были введены некоторые ограничения и платный сервис. После этого на ту же тропу вступил Яндекс, открыв сервис ПДД — «Почта для домена». Политика Яндекса была значительно демократичнее Google. Пользователь получил возможность выбрать наиболее подходящий для себя сервис.

В настоящее время оба сервиса развиты достаточно хорошо и конкурентов у них на горизонте не видно.

Зачем это нужно?

Как уже было отмечено выше, Google и Яндекс предлагают стабильную, удобную, гибкую систему обработки почты и доступа к ней с помощью веб-интерфейса, а так же лучшую в мире защиту от спама. Никто другой пока не может предложить даже платно услуги такого уровня. Говорить о почтовых сервисах хостеров, или, тем более, интернет-провайдеров, уже давно не имеет смысла. А содержание своей почтовой системы на своем сервере со временем гарантированно приведет к тоннам спама в ваших ящиках. Ну и скорее всего, за год выдастся хотя бы пару дней, когда ваша почта будет «лежать».

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

Google или Яндекс?

Выбирать, кому отдать почту для обслуживания, русскоговорящие пользователи могут среди двух конкурентов: Google и Яндекс. Оба предоставляют достойный сервис и похожи друг на друга. Но есть пару важных отличий.

В пользу Google:

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

В пользу Яндекс.Почты:

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

Каждый для себя сам может решить, что для него важнее. Я пробовал подключать и один сервис, и другой. От обоих остался удовлетворенным. Но для своей организации я выбрал Gmail, так как ограничение 50-ти ящиков не существенно, работать с Google я стал раньше, чем появилась «Почта для доменов» Яндекса, интерфейс Gmail мне и моим коллегам субъективно нравится больше, чем Яндекс.Почты.

Проблемы делегирования почты

При делегировании обслуживания почты на сервера Google или Яндекса, возникают некоторые вопросы с отправкой почты из скриптов. Если рассылать письма с помощью агента (MTA), «встроенного» в операционную систему, например функцией mail(), то можно сталкнуться с тем. что много писем будут попадать пользователям в спам. Это связано с настройкой агента и локального SMTP-сервера, через которого агент шлет письма.

Если рассылать почту по SMTP через сервера Google или Яндекса, то почта попадет в спам только при реально спамерском содержимом писем. Но, Google поддерживает подключения только с SSL-шифрованием. Следовательно ваш клиент должен уметь SSL. Кроме того, с целью защиты от спама Google блокирует отправку писем, если в течение некоторого малого времени не удается отправить большое число писем (приходят возвраты). Как дела с этим у Яндекса, я не проверял, но думаю, что у них тоже есть защита.

Плюс при рассылке по SMTP приходиться делать подключения к удаленному серверу по сети, что всегда более затратно, чем работа с localhost.

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

Я.Субботник в Минске

Валера Леонтьев — Thu, 15 Apr 2010 16:12:45 +0000

Сегодня (15 апреля 2010 года) прошел первый в Беларуси Яндекс.Субботник. Было просто супер и проведено на высочайшем уровне. Интересные и полезные доклады, интересные докладчики (руководители направлений Яндекса), активная аудитория, отличные условия (Кроун Плазе зачет).

Updated 21:10 15.04.2010 по Минску.

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

Докладчики очень приятные и профессиональные. Их было интересно слушать, с ними было интересно общаться. Все были максимально открыты.

Первым выступал Андрей Себрант — директор по маркетингу Яндекса. Общий доклад, ответы на общие вопросы. Убедительный рассказ о том, что время изобретения своих велосипедов с нуля прошло. Сейчас время сбора из комплектующих. Как раз поставой комплектующих и занимается Яндекс: ядро всех докладов — интеграция API сервисов Яндекса и партнерская поставка контента Яндексу в обмен на трафик.

Затем Александр Садовский рассказал о поиске и особенностях белорусской версии. Яндекс стремится к региональности. Результаты поиска в разных регионах существенно разнятся. Кроме того, теперь в поиске учитывается морфология белорусского языка (правда пока в зачаточной стадии). В идеале целью Яндекса является полная персонификация выдачи под клиента. Поисковые подсказки тоже региональные.

Александр заметил, что надо обращать внимание на такие вещи, как карта сайта и robots.txt для повышения позиции в выдаче. Кроме того, существует множество настроек и корректировок в интерфейсе Яндекс.Вебмастер, которые необходимо использовать.

Михаил Сенин кратко поведал о серверисе Яндекс.Сайт. Самый скромный доклад и практически ничего нового.

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

В перспективе развития сервиса карт для Беларуси создание подробных карт областных центров.

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

Роман Иванов, руководитель отдела коммуникационных сервисов, рассказал про пользовательские виджеты в Яндекс.Баре. Бар сейчас существует для IE и Firefox. Виджеты могут быть динамическими (например, отображать количество писем в ящике). Создание виджетов — процесс не сложный. Уж точно не сравнится с процессом создания целого тулбара.

Антон Забанных, довольно эпотажная личность, поведал о возможностях Яндекс.Почты для доменов. Кстати, он руководитель группы сервисов персонального общения (почты). Самое интересное то, что сейчас для сайта действует ограничение в 1000 почтовых ящиков, но оно может быть без проблем и бесплатно повышено для конкретного сайта после контакта с саппортом сервиса. А через API сервиса можно создавать и удалять ящики без участия оператора. Довольно заманчивая возможность для серсвисов, которые хотят предоставить пользователям почту в своем домене.

Антон обозначил, что сервис не предназначен для использования в качестве релея (рассылка писем роботом через SMTP). В этом случае домен могут заблокировать до выяснения обстоятельств. Правда решить проблему можно с помощью прямых рассылок с помощью SPF.

Тигран Худавердян, руководитель отдела портальных сервисов, рассказал о пользе пользовательских виджетов для главной страницы Яндекса. Вера Лейзерович продемонстрировала процесс создания простейших виджетов. Кстати, на создание самого простого виджета ушло примерно 50 секунд.

Смысл создания виджетов в том, что у многих пользователей (в том числе из Беларуси) Яндекс установлен в качестве домашней страницы. Размещают виджеты около 15% этой аудитории. В итоге создатель виджета получает некислый трафик с главной Яндекса на свой сайт, Яндекс — качественный контент, а пользователь — то, что искал. Все счастливы.

Самые простые виджеты на базе RSS создавать очень легко и быстро. Кстати, большинство крупных российских интернет-СМИ именно так и сделали.

Татьяна Исаева (руководитель группы контент-менеджеров Яндекс.Новостей) озвучила, пожалуй, самый тяжелый для прослушивания доклад про Яндекс.Новости. Длинный и монотонный.

В заключении Антон Волнухин рассказал про сервис Яндекс.Блоги и API, которое он предоставляет. Он собственно и является руководителем этого сервиса.

Все с удовольствие отвечали на вопросы в кулуарах. Особенно интересно было пообщаться с Larry Novsky (имя в миру не запомнил). Не знаю, кто он в Яндексе, но он отвечал на все вопросы, и больше всех знал про «телодвижения» Яндекса в Беларуси.

На мероприятии снимали видео и обещали его выложить. Также обещали выложить все презентации в открытый доступ. Ждем пополнения в разделе Яндекс.Субботников.

Обещали повторять Субботник примерно раз в год.

Яндекс молодцы! Спасибо!

Отзывы с Я.Субботника

—

Твитер. Фотографии. Еще фото.

Яндекс в Беларуси (конспект Я.Субботника) | Яндекс.Субботник в Минске. День 1

Информер погоды от Яндекса с определение города по IP (готовый код)

Валера Леонтьев — Sat, 05 Apr 2008 18:39:57 +0000

Недавно я заинтересовался темой отображения информера от Яндекс.Погоды посетителю сайта в соответствии с его местоположением. Сам информер Яндекса показывает погоду только в том городе, который выбрал веб-мастер сайта. На практике смысла в таком информере мало (описано в предыдущей статье). Следовательно надо саому определять город, в котором находится посетитель, и выводить ему нужный информер. В процессе изучения темы, я пришел к выводу, что кроме GeoLite City от MaxMind и CNGeoIP нормальных world-wide баз IP->Город нет. Однако, для взаимодействия с сервисом Яндекса база GeoLite City не подходит.

Таким образом, пришлось остановиться на базе CNGeoIP. Была куплена версия базы и на ней был построен алгоритм получения кода города для информера по IP посетителя. Написанный скрипт работает тут: http://ru.commontools.net/geoip/ya.w.js. Определяется город по IP пользователя, проводится сравнение с базой Яндекса и выводится id города и страны для информера в виде: var yaCountry=20;var yaCity=26850; Скрипт естественно работает на стороне сервера и выводит только id для JS. А на странице с информером скрипт включается в HTML-код страницы через