Чтобы решить проблему отказа серверов 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 <Ctrl-D>
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 <feedbee@valera.ws>)
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 адресов на ваших доменах. Туда же повалятся уведомления о недоставках.

Уже давно стандартом агента электронной почты (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.

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

Эта запись третья, и посвящена она GMail — почте от гугла.

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

На любой потовый ящик, существующего более месяца, и засвеченный хотя бы в 2-3 местах, ежедневно сыпятся тонны спама. И при выборе сервера качество спам-фильтра — один из главных показателей. На Gmail у меня 2 ящика, один поновее, ему где-то год. Второму уже 6 лет, он был заведен еще до появления Gmail, а полгода назад его обслуживание было переведено на Gmail. На второй ящик в день валится в среднем 70 писем спама. Из них попадает во входящие не более 2-3 в неделю, а иногда несколько недель ничего не проскакивает. На первый ящик приходит много меньше писем и спама, но там спам не проскакивает вообще (за весь год 2-3 случая). Так что антиспаму Gmail ставим 5 с плюсом!

До того, как я завел ящик на Gmail, я практически не пользовался веб-интерфейсами для почты. Они были неудобны, просто абсолютно неудобно. Свой первый ящик на гмыле я так и не привязал к TheBat! Ни дома, ни на работе. Потому что сразу начал пользоваться веб-мордой и остался доволен. Ящик доступен дома, на работе и в любом другом месте. Легко найти нужные письма, все быстро открывается и не глючит. В последнее время я даже стал пользоваться веб-интерфейсом и для второго ящик, но только дома. В опере у меня постоянно открыты 2 таба на два ящики на гмыле.
Определенные плюс Gmail в том, что нет нужды задумываться о наличии места на диске. Его там столько, что я не представляю, как его вообще можно исчерпать.

POP3, SMTP и IMAP сервисы доступны в безопасном SSL-режиме. Что еще надо то?

Ну и конечно замечательно то, что они дают возможность использоваться их сервер для почты на личных доменах пользователя. Для этого достаточно перевести MX-записи DNS на почтовые серверы Gmail. И все возможности почты от гугла доступны на вашем домене.