Похоже на превышение одновременных подключений к базе. база данных на вашем сервере? если да, то увеличте кол-во одновременных подключений и снизте timeout на подключение к базе
Этот топик решает проблему немедлянной доставки писем связанных с регистрацией аккаунта и напоминания пароля. Снимая тормоза с размещения топиков, комментов и т.д. т.к. включается режим отложенной доставки, но важные письма уходят сразу. В эти моменты пользователь не будет ждать, что там у вас по крону запустится какой-то скрипт.
возможные причины:
1). Вы либо не внесли все описанные здесь изменения
2). У вас проблемы непосредственно с доставкой почты
3). У вас пилинная версия движка, где не соответствуют название шаблонов notify.registration_activate.tpl, notify.registration.tpl, notify.reactivation.tpl, notify.reminder_code.tpl, notify.reminder_password.tpl
на самом деле факторов влияющих на попадание писем в спам достаточно много. Я на днях подготовлю информацию по фильтрации писем/попаданию в спам. в совокупности првил любая мелочь может стать решающей для попадания письма в спам.
Если речь идёт о редактировании файлов на сервере через веб интерфейс, и до переноса на VDS всё работало. Скорее всего, что по FTP вы файлы закачали из под одного пользователя (допустим normik), а ваш веб сервер работает из под другого (допустим www-data). соответственно, вам необходимо либо у изменяемых файлов изменить владельцев файлов на тех-же из под которого работает веб сервер (т.е. www-data) или выставить на них права доступа 777 (что означает, что файлы имеет право изменять любой пользователь)
рекомендую посмотреть в сторону tmpfs (раздел в памяти). на дынный раздел можно закинуть всякую gzipнутую статику, чтоб она считывалась не с диска, а напрямую из оперативной памяти. это так-же вам ускорит отдачу статики и снизит нагрузку на ваш VPS. Зачастую узким местом для VPS/VDS становится именно обращение к диску.
не повредит. фикс актуален в первую очередь тем, у кого заголовок выставляется не верно. у каждого хостера разные настройки. Вас я так понимаю в данном случае не касается.
значит у вас всё отлично. причины попадания в спам могут быть разные. это может быть совокупность нескольких правил фильтра. все спам фильтры построены по принципу скоринга. каждое правило по которому проходит письмо получает положительно или отрицательное значение. после чего если результат скоринга выше выставленного, письмо попадает в спам. такие фильтры как spamassassin допустим пишут в заголовке письма скоринг и на основании чего они его расчитали. этим самым можно письма оптимизировать для проходимости через фильтры
то, что прописано в конфиге, влияет на поле заголовка From:
Это именно то, что видит получатель письма непросредственно от кого оно отправлено.
Return-path как правило содержит непосредственно адрес, кто осуществил отправку.
в данном примере подразумевается, что работает некий апач сервер с правами nobody и письмо отправлялось через sendmail локально с сервера. из чего в данном примере получился адрес отправителя nobody@localhost (вместо localhost может бытьт любое другое название, котороым был назван сервер и не факт, что оно будет корректным).
в случае если у вас на сайте есть регистрации на несуществующие адреса или адреса, которые блокируют доставление ваших писем, то при наличии некорректного заголовка return-path вы даже и не узнаете, что там у вас просиходит. т.к. отбивки писем вы не получите. если же сервер отправитель правельно выставит ваш адрес в заголовок return-path, то при ошибке доставки письма, он отбивку доставит к вам на мейл и вы уже будете знать, что у ваших пользователей есть проблемы с получением писем с вашего сайта. Как правило такие письма отбивки содержат и причину по которой письмо небыло доставлено.
а по поводу факторов влияющих на доставку писем расписать в комментариях особо не получится т.к. этих факторов как минимум на целую статью.
на спам влияет достаточно много факторов. одним из них само собой являются правельные заголовки писем с корректной кодировкой. но по мимо всего существуют такие технологии как SPF, DKIM. которыми можно улучшить доставляемость писем. Допустим раньше наши письма на гугле всегда попадали в спам. после настройки SPF всё стало нормально. если есть желание, могу подробно описать факторы, которые влияют на прохождение писем через основные системы защиты многих почтовых решений.
1). Вы либо не внесли все описанные здесь изменения
2). У вас проблемы непосредственно с доставкой почты
3). У вас пилинная версия движка, где не соответствуют название шаблонов notify.registration_activate.tpl, notify.registration.tpl, notify.reactivation.tpl, notify.reminder_code.tpl, notify.reminder_password.tpl
Это именно то, что видит получатель письма непросредственно от кого оно отправлено.
Return-path как правило содержит непосредственно адрес, кто осуществил отправку.
в данном примере подразумевается, что работает некий апач сервер с правами nobody и письмо отправлялось через sendmail локально с сервера. из чего в данном примере получился адрес отправителя nobody@localhost (вместо localhost может бытьт любое другое название, котороым был назван сервер и не факт, что оно будет корректным).
в случае если у вас на сайте есть регистрации на несуществующие адреса или адреса, которые блокируют доставление ваших писем, то при наличии некорректного заголовка return-path вы даже и не узнаете, что там у вас просиходит. т.к. отбивки писем вы не получите. если же сервер отправитель правельно выставит ваш адрес в заголовок return-path, то при ошибке доставки письма, он отбивку доставит к вам на мейл и вы уже будете знать, что у ваших пользователей есть проблемы с получением писем с вашего сайта. Как правило такие письма отбивки содержат и причину по которой письмо небыло доставлено.
а по поводу факторов влияющих на доставку писем расписать в комментариях особо не получится т.к. этих факторов как минимум на целую статью.