Почта: свой хостинг vs google apps

Алсо, для доставки локальной почты будет поднята виртуалка с exim. На каждой виртуалке также будет exim, настроенный на использование smarthost.

используем гуглопочту для туевой хучи клиентов (овер 5кк). все довольны.

так и запишем: админы пачками сдают юзверей гугелу :]

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

работает стабильно, косяков не замечал. рекомендую гуглопочту, хотя минус - это то что ты будешь зависить от работоспособности ИХ боксов.

Все довольны? Может это потому, что они не знают о недошедших письмах?

Ситуация: если отправлять письмо на адрес одной организации, МХ которой — гугель, то, судя по логам, сервер гугля принимает письмо, рапортует об этом, но получатели утверждают, что письмо они не получили. Если же наши отправители создают письмо как ответ, то всё доходит до конечных получателей. Разумеется, адреса получателей идентичные, приём писем самими серверами корректный и тд и тп, т.е. всё, что я могу увидеть в логах, ни о чём плохом не сообщает.

Разумеется, жалующиеся на это, идут лесом — не моё дело организация почтовой системы чужих быдлоконторок, особенно, таким вот образом. Однако, профессиональный интерес остаётся: что это такое? Внутренний антиспам гугля? Или глюк?

очевидно, глюк. только что проверил на нашей гуглопочте, работает нормально.

Ещё у гугля был такой глюк (странное поведение). Если за почтовый домен отвечают два mx-сервера и основной (MX 10) принимает соединения, но не может принять письмо (ошибка 4xx), то гугл упорно не хотел отправлять письмо на другой (MX 20), двое суток долбился на первый.

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

> Если за почтовый домен отвечают два mx-сервера и основной (MX 10) принимает соединения, но не может принять письмо (ошибка 4xx), то гугл упорно не хотел отправлять письмо на другой (MX 20), двое суток долбился на первый.

это нормальное поведение согласно рфц, афаик.

Ткните в RFC, если не сложно. Пока в RFC 5321 нашёл такое

>When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the SMTP client SHOULD try at least two addresses.

Просто, даже если это RFC, то все остальные почтовые сервера работали по другому. Может, сейчас и гуглевские это исправили, а тогда (2 года назад) к нам нам плохо приходила почта с гугля (причём только с гугля) и пару недель понимали, почему так.

Вот там и была временная ошибка, типа сервер пергружен попробуйте позже, (MS Exchange там был поставлен и не справлялся с нагрузкой), и все почтовики, которым не повезло шли по другой MX-записи и отправляли почту (а спам-боты шли даже с другого ip-адреса из сети другого класса).

все верно. только кот здесь не указано, какою ситуацию считать ошибкой, достаточной для попытки переслать через другой сервер. вот гугловские и не посчитали, что "temporary busy" это достаточная причина.

>Гугловская фильтрация спама — лучшее, что я видел.

Банальный грейлистинг кроет gmail как бык овцу...

Мой основной e-mail, balancer@balancer.ru засвечен, наверное, во всех спамлистах мира. Своё gmail'овское мыло не показываю никому. Однако, на последнем спама пробивается больше, чем на первом :) Кроме того, были уже не раз ложные срабатывания, когда в спам кидались нужные письма (постоянно сыпались, пока не обучил, письма рассылки с python-ogre, дважды сыпались в спам письма от шефа с очередными техзаданиями...)

идеальных почтовых систем не бывает. Но гугл берет не только почтой, но еще и полноценным мехом всякими фичами, типа документы, календари и т.д. =)

Пока с этих фич пользы не видел. Гугль же для меня «берёт» пока только одной фишкой - самым удобным среди конкурентов web-интерфейсом :)

а как же антиспам?

>а как же антиспам?

А мы что до этого выше обсуждали?

топик с конца читаю :)

Грейлистинг всегда считал довольно неприятным костылём, кстати.

Чем же? Тем, что почта с нового неизвестного ресурса придёт не сразу, а через 10 минут? Ну так это очень низкая плата за мгновенное отсеивание 90% всего спама :)

Да ну, не придумывайте. Если ошибка 5xx - почтовик никуда больше вобще не должен идти. После этой ошибки он должен сгенерировать отлуп клиенту с ошибкой и удалить письмо из очереди.

Описанное мною - это корректное поведение согласно RFC. И даже то, что по дефолту любимый мною постфикс нарушает это ( но только в случае, если сразу без приветствия получает 5xx):

smtp_skip_5xx_greetin
....
"The default setting is incorrect, but it is what a lot of people expect to happen.".

не повод предполагать, что такбудут делать все на любых этапах и строить на этом какую-то почтовую политику.