Comments 15
Советовать людям ставить в 2015 году Sendmail, как минимум, несколько странно.
И чем плох sendmail?
Sendmail has an extraordinarily obscure configuration file, a poor history of security breaches and a design centred around Unix in the early 1980s. Sendmail is known for being inefficient compared to alternatives so it might be hard to see why sendmail is still used at all, but history has its own inertia. There is no good reason for a site without Sendmail experience to install it, given the effectiveness of the alternatives. There are often good reasons why a site with Sendmail working should keep it.© lwn.net/Articles/196724
Большинство дистрибутивов уже перестало пихать его как дефолтный МТА — перешли на Exim или Postfix.
Так что не нужно его советовать.
Although there are no recent surveys, Sendmail usage appears to be dropping over time. Dan Bernstein's 2001 SMTP survey (without published source code, and therefore not replicable) put Sendmail at about 42% market share. In 2006 it seems reasonable to assume [4] that Sendmail is on substantially fewer than 40% of the world's SMTP servers.
Я не призываю не использовать Exim или Postfix, а лишь предлагаю использовать то, что уже установлено, если оно вполне способно соответствовать необходимым нуждам и требованиям вследствие небольшой настройки.
Я не призываю не использовать Exim или Postfix, а лишь предлагаю использовать то, что уже установлено, если оно вполне способно соответствовать необходимым нуждам и требованиям вследствие небольшой настройки.
In 2006
Это цифры 10-летней давности всё же. Нынче его доля крайне низка, по объективным причинам.
По старой памяти CentOS и прочие RHEL предлагают его на выбор при установке (вместе с Pfx/Exim), но смысла его выбирать нет.
а лишь предлагаю использовать то, что уже установлено
apt-get purge sendmail
apt-get install postfix|exim
Вот и установлено что-то другое :)
Не стоит использовать плохое ПО только потому что оно уже стоит. Вам ведь его потом ещё и поддерживать.
Прикрутили бы лучше sendgrid какой-то. На небольшой кол-ве писем он еще и бесплатен. Получали бы ответы сразу вебхуком в приложение. Мне кажется локальные mail серверы уже умерли давно.
вам exim + dovecot не просто так посоветовали, в этой связке (да и по отдельность) можно хранить данные про учётки (а также сопутствующую информацию) в БД. На выходе получаем возможность заводить учётку при регистрации пользователя на сайте без необходимости менять конфигурацию почтовика, а так же разложенную по учёткам почту (для каждой учётки — свой файл).
Вот тут то и кроются проблемы, если поток почты будет достаточно большой, то ваш файл «для всех» будет быстро распухать, а дальше — либо будет требоваться большое количество RAM для быстрого разбора файла, либо получаем тормоза при чтении почты.
В дальнейшем нам лишь останется разобрать, кому и чья почта принадлежит и отдать уже фактическому владельцу на нашем сайте.
Вот тут то и кроются проблемы, если поток почты будет достаточно большой, то ваш файл «для всех» будет быстро распухать, а дальше — либо будет требоваться большое количество RAM для быстрого разбора файла, либо получаем тормоза при чтении почты.
а так же разложенную по учёткам почту (для каждой учётки — свой файл)
Формату Maildir в этом году 20 лет. Может всё-таки уже пора начать им пользоваться, а?
Статья о том, как принять данные и отдать ее php скрипту. А получив ее сделать с ней все необходимое, в том числе и раскидать соответствующим образом не проблема. Смысл сводился именно к тому, чтобы хранить ее в соответствующем виде, согласно структуре уже работающего сайта, в моем случае каталога, как раз без необходимости переустановки и замены уже работающего почтовика.
Согласен, большой файл разобрать сложно, да и неудобно обращаться к нему отдельно от самого sendmail. Поэтому наиболее удобный вариант направить сразу на php скрипт, который будет его обрабатывать на лету.
Сделать это можно в файле
/etc/aliases
Так что общей помойки не будет
Согласен, большой файл разобрать сложно, да и неудобно обращаться к нему отдельно от самого sendmail. Поэтому наиболее удобный вариант направить сразу на php скрипт, который будет его обрабатывать на лету.
Сделать это можно в файле
/etc/aliases
user: "|php5-cgi -c /path/to/php.ini /site.ru/public_html/mail.php"
Так что общей помойки не будет
Не увидел никакой авторизации (а у тем более защиты от перебора учёток). Насколько я понимаю, узнав любой адрес из вашего домена site.ru, можно смело проводить рассылки через ваш сервер.
И ещё:
> /home/site.ru/public_html/mail
означает, что используется древний формат mailbox, где все письма кучей в одном файле.
Будете восстанавливать «случайно удалённые письма» — намучаетесь. Впрочем — про бэкап почты в статье ни слова, значит это не проблема.
И ещё:
> /home/site.ru/public_html/mail
означает, что используется древний формат mailbox, где все письма кучей в одном файле.
Будете восстанавливать «случайно удалённые письма» — намучаетесь. Впрочем — про бэкап почты в статье ни слова, значит это не проблема.
Авторизация и учетка будет создаваться уже на конкретном сайте, в моем случае на каталоге. Поэтому этот момент уже полностью отдается под контроль самого php скрипта, и его разработчика. Соответственно и контроль рассылки.
По поводу кучи в одном файле полностью согласен, и решение предложил чуть выше.
По поводу кучи в одном файле полностью согласен, и решение предложил чуть выше.
wget -O — http://officeshield.drweb.com/drweb/drweb.key | apt-key addпрекрасный способ добавить левый ключ (который может подменить кто угодно по дороге) в доверенные
Sign up to leave a comment.
Почтовый сервер на собственном сайте через sendmail