Обработка входящей почты на PHP

[@CuamckuyKot]

Работает с любыми MTA?

[@agorlov]

Я полагаю что да.
все MTA которые умеют работать с /etc/aliases

[@ckald]

Вопрос не совсем по теме, но это то, что я надеялся тут найти и не нашел.

А если почтовый сервер не у нас, а какой-нибудь Яндекс? Есть какие-нибудь конкретные признаки, которые позволят понять, что письмо не дошло? У меня есть сайт с рассылкой на 40000 адресов покупателей. Я смотрел возвраты о недоставке – каждый почтовик отправляет по-своему

[@DLag]

Отправляйте с адреса вида [e-mail]
Если письмо вернулось, то с очень большой вероятностью это отлуп.

[@ckald]

Остроумно :) Даже если не регистрировать на каждого пользователя ящик, нужно заводить на домене свой почтовый сервер. А мы решили снять с себя эту нагрузку и работаем по смтп с яндексом. Хотелось бы вышеуказанный функционал по имап реализовать

[@Psih]

Добавляйте X-Your-Header-Here и считывайте пришедшие на Return-Path письма. Так можно обрабатывать отлупы, да и не только :)

[@DLag]

Знак + существует специально для того чтобы отделить имя ящика от параметров.
Т.е. ящик останется robot, но вы сможете проверять от какого userid пришло по хидеру To: в письме.
Это умеет даже Яндекс, не говоря уже о профессиональных системах.

[@ckald]

Этот топик стал бездонной ямой для ликвидации моей безграмотности

[@charon]

тогда domain.com привяжите к какому-нибудь сервису типа того-же Янедкса и включите получение всех писем на все адреса домена в один ящик. Потом скачивайте по ИМАП все письма из того ящика и проверяйте получателя. Правда, рано или поздно спамом вас накроет немного.

[@agorlov]

основная почта у нас тоже обрабатывается Яндексом, а для
возвратов мы завели поддомен bounce.mydom.ru

и при отправлении письма, мы указываем Sender вида:
bounce+name=[e-mail]

но поле From не трогаем!

у нас в скрипте рассылки есть такой код:

...
    //Если почтовый сервер не может доставить письмо,
    //он его возвращает отправителю.
    //Мы же просим его все возвраты слать на адрес:
    //[e-mail]
    //и в этом адресе, кодируем получаетля, чтобы легче было парсить возврат
    //(т.к. разные почтовые сервисы шлют их со своими текстами)
    //Пример адреса для возврата: bounce+name=[e-mail]
    //Эта техника называется VERP: http://en.wikipedia.org/wiki/Variable_envelope_return_path
    //Поле Form: остается без изменений, поэтому на получателей это ни как не отражается.
    $VERPAddr = str_replace('@', '=', $emailData['email']);
    $mail->Sender = "bounce+$[e-mail]";

[@ckald]

Потрясающе. Можете показать кусок заголовков отправляемого письма? И это фича исключительно Яндекса?

[@agorlov]

Для рассылок пользователям мы используем свои smtp-сервера,
честно говоря не представляю как вам удается 40000 писем через сервера яндекса отправить…

Это правда возможно? ;-)

[@ckald]

Несколько ящиков и несколько дней терпения. У нас рассылка об акциях и обновлениях, так что не спешно и мы можем рассылать дней 5-7. Зато это совершенно бесплатно!

Яндекс разрешает что-то около 2500 писем в день с одного своего ящика. Самое сложное – не раздражать всяких мейл.ру, которые время от времени нас в спам укладывают. Но это довольно просто решается отправкой писем в их поддержку и со временем ситуация возникает все реже.

[@ckald]

А, да. Самым важным оказалось кодирование кириллицы в заголовках писем. За это в спам ложат в первую очередь. Как только закодировали – пошло нанмого лучше

[@mche]

и что действительно работает? этоже требует дополнительной настройки на серверах которым вы рассылаете.
А обычно отлупы идут на Return-path

[@agorlov]

либа (phpmailer) которой мы шлем автоматом добавляет Return-Path при изменении Sender — и если не ошибаюсь изменение Sender влияет на команду SMTP
MAIL FROM:

   $useVerp = ($this->do_verp ? " XVERP" : "");
    fputs($this->smtp_conn,"MAIL FROM:<" . $from . ">" . $useVerp . $this->CRLF);

еще посмотрел в main.cf, у нас там такая штука есть:
smtpd_authorized_verp_clients = $mynetworks

[@bolk]

tools.ietf.org/html/rfc3461

[@AHTOH]

Все намного проще.
В заголовке для каждого письма указывайте уникальное поле «Errors-To:», куда почтовик будет отправлять отлупы. И обрабатывайте только адрес получателя, который со 100% гарантией связан с письмом отправителя (можете в базе хранить коды писем, а можете просто свой формат адреса сделать).

Например:

From: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
или даже на
Errors-To: [e-mail]

всю почту на *[e-mail] заворачиваете на свой парсер и однозначно получаете информацию, что письмо не доставлено. В адрес можно включить любую информацию — дату, тему, получателя, код, фамилию и пр.

[@ckald]

Знаете, мне уже столько вариантов, как это сделать предложили, что я начинаю терятся. Этот заголовок входит в стандарт? Его поддерживают все почтовики?

[@AHTOH]

Он вынесен из RFC-1341, но его по обратной совместимости поддерживают все почтовики. В новом RFC остался только «Reply-To:», который удобно использовать, чтобы не портить «From:», но если его не указывать, то адрес возьмут именно из «From:».

[@agorlov]

вроде этот заголовок Errors-To считается deprecated

[@mche]

так как вы собираете bounce?

[@agorlov]

чуть выше написал:
http://habrahabr.ru/blogs/php/126448/#comment_4170857

добавлю что парсить боунсы по тексту сообщения — сложно,
в том числе определить адресата, поэтому мы так не делаем :)

Просто кодируем адресата в «envelope sender»:
bounce+name=[e-mail]

и потом остается пропарсить:
$recipient = getenv('RECIPIENT'); //bounce+name=[e-mail]
чтобы понять, что доставка на адрес [e-mail] не прошла.

[@agorlov]

Не ожидал, что тема обработки bounce будет так интересна.
чуть позже соберу все мысли на этот счет и допишу

[@ckald]

Любая работа с почтой интересна. Столько фич можно на ней завязать. Останавливает отсутствие высокоуровневых прослоек для работы с ней и общая разнородность (те же баунсы)

[@charon]

а меня останавливает полная компрометация идеи электронной почты явлением спама и нежеланием сообщества внедрять всякие грабли для спаммеров типа SenderId, SPF и прочие.

[@ckald]

Если вы мне назовете аналог, который не подвержен спаму – я вас расцелую.

[@charon]

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

[@ckald]

Эээ… Не буду вас целовать, сами виноваты :) В соцсетях сейчас спама еще больше, чем на почте. Но что нам остается – пользуемся и почтой и соцсетями.

habrahabr.ru/blogs/php/126448/#comment_4170930

[@charon]

не надо целовать :)
А как вам удаётся находить спаммеров в соцсетях? Я из своего личного опыта могу припомнить только одного за последнее время, который просил за него проголосовать где-то там. Пользуюсь фэйсбуком, немножко Вконтакте, Гугл+, Одноклассники, ЛинкедИн.

[@ckald]

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

Понимаете, я их совсем не ищу :)

[@Aldekein]

Как раз делал это сам месяц назад, с легким матерком ;)

[@Q_Zma]

Интересно, а что будет если на этот ваш email придёт n-ое количество писем с вложениями максимально допустимого размера?

[@muzzle]

> robot: "|php -q /путь/к/скрипту.php"

Если какой косячок вдруг неожиданно — потеряются письма.
Если письма повалят с невиданным рейтом — ресурсы не безграничны.

Не разумнее ли валить все в ящик, и выгребать почту из него?
В этом случае гораздо меньше риск потерm и использование ресурсов контролируемо.

[@muzzle]

Несколько лет назад разрабатывал систему, передача данных была через почту.
Писем было относительно немного, около 20К в сутки.
Все валились в ящик, откуда по крону ПХПшный скрипт их выгребал.
Работало вполне устойчиво, в случае непредвиденностей — письма оставались в ящике и обрабатывались как только проблемы устранялись.

[@charon]

20к — это много писем. На некоторых дешёвых хостингах это превышает суточный лимит для одной учётной записи. Так что ваша работа заслуживает похвалы.

[@muzzle]

Ну… Почтовый сервер то наш :)
А общий объем почты в то время был в среднем 400К писем в сутки, самый максимум (случилось однажды) 610К писем.

Потом после оптимизаций в головах и бизнес-логике — через эту систему трафик подсократился раз в 5.

[@muzzle]

Посмотрел статистику, в тот день было 610К писем суммарным объемом 1,8Гб.
Это так, для иллюстрации (ну и похвастаться ;)

[@agorlov]

Зависит от конкретных условий
если в ящик валить и от туда парсить — то невиданный рейт и максимальный размер тоже может негативно отразиться на работоспособности сервера.

Думаю Ваше решение тоже рабочее, но насколько оно устойчивее к косячкам или атакам однозначно сказать не могу.

[@muzzle]

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

Мое решение отпахало примерно 4 года.

[@muzzle]

Я не говорю что Ваше решение плохое.
Оно просто слишком оптимистичное :)

[@liaren]

Альтернативный способ для тех кому надо забирать почту из внешнего сервера или у кого нет доступа к конфигурации сервера: использовать PHP библиотеку php-imap.

[@Graid]

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