Я же еще раз говорю, получается яицо в яице: мы пишем скрипт, который следит за скриптом, который следит за скриптом.
У автора лично было несколько случаев, когда на старте системы /etc/init.d/service start отрабатывало с ошибкой. И никак не перезапускалось. И жизнь — боль :)
Для начала, узнает, почему упало. Т.е. если его остановил админ, то перезапускать не надо.
Если админ ничего не делал, а приложение ушло, то перезапустит. Приложение ведет лог, причем systemd помогает делать это в едином месте. Пусть админ потом разбирается, почему упало и что случилось.
Поверьте, эта логика важна для критичных сервисов. Допустим стоит у вас postfix, в котором нашлась ошибка критическая, которая позволяет повалить его злоумышленнику. Его повалили ночью. Сработал мониторинг, вы пошли его перезапускать. С systemd он будет перезапущен без Вас.
Вы привели отличный пример уробороса. Автор пытается рестартовать службу при помощи /etc/init.d/service, что по сути работать не должно.
Однако в системе кто-то об этом побеспокоился и сделал велосипед /etc/init.d/service -> systemd, но что-то пошло не так, поскольку надо смотреть, как написан .service-файл.
Прочитайте внимательно. Бывает, что скрипты на SysV стартуют, однако приложение по какой-то причине вываливается на старте. Что делать? Я понимаю, запустить руками. Но без режима контроля и рестарта многие современные приложения тупо не работают нормально.
Мануал на 10 страниц осваивать на надо. Не админу достаточно одну статью прочитать с базисом.
А вот про удобоваримый скрипт для запуска демона — гм, смотря что считать удобоваримостью.
Да в этом и проблема, что накидывание спам-очков крайне осложнено. Из моего опыта достаточного количества почты в сутки, с Softfail ее достаточно много, порядка 40%. Всем накидывать не будешь.
SRS да, у многих не работает (см. ниже mail.ru) или работает некорректно. В результате от страха перед некорректной пересылкой (который больше малюют, чем он есть на самом деле) все пишут ~all, так, на всякий случай.
Что Вы, разумеется, что я не считаю SPF методом борьбы со спамом. В первую очередь, борьбой с фишингом.
Во вторую очередь это можно считать борьбой со спамом, но с рядом оговорок.
Борьбу со спамом я делю на две большие задачи. Первая — это борьба на бордере, т.е. еще на этапе приема. Когда мы ничего не знаем про того, кто будет получать это письмо. Когда мы ничего не знаем про его спам фильтры. Наша задача — быстро устроить деление на «хорошее» и «плохое». (Плохое, кстати, необязательно реджектить, можно в грейлист отправлять).
В первой задаче SPF хорошо работает. Быстро отсекаем Fail, вайтлистим Pass (кроме тех, у кого +all, тех наказываем), подвергаем мукам Softfail.
А вот вторая задача — это уже спам-фильтрация с учетом того, от кого и кому доставлено письмо. Тут уже другие методы, но если кратко, то тут SPF абсолютно бесполезен. Вот как-то так.
А про SpamCop — на полном серьезе. Несколько абуз от сайтов, у которых стоит -all, что я им ответил «Нет такого пользователя» на спам.
Для случаев пересылки есть SRS, который вполне себе хорошо работает. Если пересылающий не умеет им пользоваться, то ССЗБ.
Если Вы еще ни разу не попадали в spamcop только потому, что ответили «нет такого пользователя» на спам от домена, у которого стоит -all, то все еще впереди.
Ну и про гомеопатию. На почтовой системе с примерно 200 тысячами сообщений в сутки в Fail по SPF уходит порядка 6-7%. Это крайне интересная цифра. Разумеется, что пересылки среди этих сообщений мизер, а вот спамеров — за 95%.
Вы задали прекрасный вопрос. Признаюсь, я ожидал его раньше :)
У меня есть несколько вариантов. Приведу их по мере повышения режима параноика.
1. Банальная глупость и желание «сделать лучше». Так бывает, когда люди, например, по непонятной причине включают firewall на системе, где закрывать нечего. Так и тут — перепутали семантику a c mx, вот и получилось. Либо меняли mx, и в какой-то момент накосячили.
2. Кому-то это было нужно. Формально запись выглядит правильной, а вот кто-то мог и фишить при помощи этого. Отличное прикрытие.
Во-первых, запись таки проверяется (нельзя выявить ошибку в записи, не проверив её, правда?).
Результатом проверки такой записи является Permerror. Давайте возьмем конфиг policyd-spf.conf из Ubuntu 16.04 и посмотрим туда.
# A permanent error has occured (eg. badly formatted SPF record)
PermError_reject = False
Т.е. никакого Reject не будет, письмо пойдет дальше. Кроме того, обычно работа с SPF не есть работа почтового сервера. В подавляющем большинстве случаев это делается некой внешней утилитой (неважно, как вызываемой), которая вполне себе может поддерживать RFC 7208 от 2014 года.
SHOULD, написанный в RFC, воспринимается, как рекомендация. Однако, я не вижу никаких причин ей не следовать.
Вообще, если посмотрите, то политика в отношении SPF-проблем крайне мягкая, это если брать конфиги по-умолчанию. У Сбера же применяется -all, что означает «жестить и никаких гвоздей».
У автора лично было несколько случаев, когда на старте системы /etc/init.d/service start отрабатывало с ошибкой. И никак не перезапускалось. И жизнь — боль :)
А что делать, если перезапускающий скрипт вылетит? :) systemd есть init, если он вылетел, то у нас есть проблема поважнее.
Вы совершенно правы, что произошло усложнение системы старта. Но не из-за systemd, а просто потому, что жизнь стала такой.
Если админ ничего не делал, а приложение ушло, то перезапустит. Приложение ведет лог, причем systemd помогает делать это в едином месте. Пусть админ потом разбирается, почему упало и что случилось.
Поверьте, эта логика важна для критичных сервисов. Допустим стоит у вас postfix, в котором нашлась ошибка критическая, которая позволяет повалить его злоумышленнику. Его повалили ночью. Сработал мониторинг, вы пошли его перезапускать. С systemd он будет перезапущен без Вас.
Однако в системе кто-то об этом побеспокоился и сделал велосипед /etc/init.d/service -> systemd, но что-то пошло не так, поскольку надо смотреть, как написан .service-файл.
Мануал на 10 страниц осваивать на надо. Не админу достаточно одну статью прочитать с базисом.
А вот про удобоваримый скрипт для запуска демона — гм, смотря что считать удобоваримостью.
А вообще, для сторонних сервисов внесут исключения, нет проблем.
Про SpamCop: мы с ними общаемся напрямую, на адрес noc пишут. А про DNS — посмотрите тут последние три вопроса-ответа. Очень забавляет :)
Вернее, я допускаю, что там есть легитимная пересылаемая почта. Но крайне мало.
SRS да, у многих не работает (см. ниже mail.ru) или работает некорректно. В результате от страха перед некорректной пересылкой (который больше малюют, чем он есть на самом деле) все пишут ~all, так, на всякий случай.
Как результат, имеем что имеем.
Что Вы, разумеется, что я не считаю SPF методом борьбы со спамом. В первую очередь, борьбой с фишингом.
Во вторую очередь это можно считать борьбой со спамом, но с рядом оговорок.
Борьбу со спамом я делю на две большие задачи. Первая — это борьба на бордере, т.е. еще на этапе приема. Когда мы ничего не знаем про того, кто будет получать это письмо. Когда мы ничего не знаем про его спам фильтры. Наша задача — быстро устроить деление на «хорошее» и «плохое». (Плохое, кстати, необязательно реджектить, можно в грейлист отправлять).
В первой задаче SPF хорошо работает. Быстро отсекаем Fail, вайтлистим Pass (кроме тех, у кого +all, тех наказываем), подвергаем мукам Softfail.
А вот вторая задача — это уже спам-фильтрация с учетом того, от кого и кому доставлено письмо. Тут уже другие методы, но если кратко, то тут SPF абсолютно бесполезен. Вот как-то так.
А про SpamCop — на полном серьезе. Несколько абуз от сайтов, у которых стоит -all, что я им ответил «Нет такого пользователя» на спам.
Если Вы еще ни разу не попадали в spamcop только потому, что ответили «нет такого пользователя» на спам от домена, у которого стоит -all, то все еще впереди.
Ну и про гомеопатию. На почтовой системе с примерно 200 тысячами сообщений в сутки в Fail по SPF уходит порядка 6-7%. Это крайне интересная цифра. Разумеется, что пересылки среди этих сообщений мизер, а вот спамеров — за 95%.
У меня есть несколько вариантов. Приведу их по мере повышения режима параноика.
1. Банальная глупость и желание «сделать лучше». Так бывает, когда люди, например, по непонятной причине включают firewall на системе, где закрывать нечего. Так и тут — перепутали семантику a c mx, вот и получилось. Либо меняли mx, и в какой-то момент накосячили.
2. Кому-то это было нужно. Формально запись выглядит правильной, а вот кто-то мог и фишить при помощи этого. Отличное прикрытие.
Про «большинство» не вижу смысла спорить, поскольку ни Вы, ни я не сможем доказать друг другу, как будет настроено то самое «большинство».
> host -t mx sberbank-ast.ru
sberbank-ast.ru mail is handled by 5 mail4.sberbank-ast.ru.
Тогда mail4 можно было бы не добавлять в список.
Но -all радует. Это хорошо.
Результатом проверки такой записи является Permerror. Давайте возьмем конфиг policyd-spf.conf из Ubuntu 16.04 и посмотрим туда.
# A permanent error has occured (eg. badly formatted SPF record)
PermError_reject = False
Т.е. никакого Reject не будет, письмо пойдет дальше. Кроме того, обычно работа с SPF не есть работа почтового сервера. В подавляющем большинстве случаев это делается некой внешней утилитой (неважно, как вызываемой), которая вполне себе может поддерживать RFC 7208 от 2014 года.
SHOULD, написанный в RFC, воспринимается, как рекомендация. Однако, я не вижу никаких причин ей не следовать.
Вообще, если посмотрите, то политика в отношении SPF-проблем крайне мягкая, это если брать конфиги по-умолчанию. У Сбера же применяется -all, что означает «жестить и никаких гвоздей».
А вот по поводу действительно ценной переписки — не забывайте, что фишинг никто не отменял. Банку жить без -all нельзя.