Вышел Sendmail 8.16.1

что нужно поправить в макросах, чтобы sendmail не ругался

В большинстве современных случаев править не надо ничего: базовые макросы давно отлажены, и их там на большинство случаев жизни. sendmail.cf можно рассматривать просто как часть кода sendmail, которая может быть скорректирована без использования gcc. Что, кстати, с Postfix невозможно: если в коде беда, то вперёд за компилятор. :-)

там маршрутизация требовалась особенная. времена были суровые :)

И что, с Postfix сейчас бы ту маршрутизацию сделать удалось?

то есть, мои знаия sendmail образца конца 90-х не релевантны?

Разве что набора макросов: их стало больше. Ну и появился milter. А, ещё теперь он работает в двух режимах: один собственно MTA, другой submit для локальной отправки к MTA. В общем-то вот и всё наверное, что поменялось.

что же не хватало в постфикс, когда я с него вернулся на sendmail

У Postfix долгое время не было возможности обработки сообщений до помещения в очередь. В итоге сервера с Postfix вынуждены были быть источниками боунсов.

Да ладно!? Я констатировал факт про слепошару, а в ответ началось. :-)

Ты просто нахамил.

Вся необходимая функциональность там появилась гораздо раньше. После шло вылизывание кода, новые функции прикручивались через milter-интерфейс. Иными словами, если Вы освоили конфигурирование Sendmail версии 8.12, то справитесь и с версией 8.16 ;).

Речь шла не о том, справится ли некий админ с настройкой sendmail в принципе, а будет ли он вообще заморачиваться с ТАКОЙ документацией или предпочтёт осваивать и разбираться с Postfix, Exim или чем-то ещё другим.

Теоретики… ни разу с такими проблемами не сталкивался, всегда читал прекрасную инструкцию и все настраивал без малейших проблем. Теоретики могут посравнивать с exim. Postfix шибко урезанный… Если ты настраиваешь почту по HOWTO не вникая вообще как оно там, любой почтовик тебе в какой-то момент взбрыкнет и придется таки читать доки. И с шансами с sendmail удастся разобраться гораздо быстрее чем с прочими. Потому что удобная отладка и хорошая документация.

Ты просто нахамил.

Указать на то, что кто-то проморгал наличие полной документации (причём в одну команду из op.me можно сделать хоть текст, хоть pdf - Makefile рядом лежит) в распространяемом тарболе - это нахамить? Вот ты дальше нахамил.

Кто Вам такое сказал? sendmail.cf по-прежнему можно редактировать руками

Нельзя. Или, говоря другими словами: запрещено, прохибитед, ферботен. Если вы реализуете сценарий:

1. Пишем метаконфиг.
2. Генерируем из него конфиг.
3. Правим тот конфиг руками.

То ваш сменщик, глядя на метаконфиг будет заблуждаться, что он отображает реальность. Хуже всего, когда изменения незначительны. Это просто бомба замедленного действия и реальное вредительство.

Ошибаетесь. Я выше уже писал о причинах такого конфига у sendmail.

Я признаю былые заслуги и очень рад, что теперь функциональность обмена почтой межу usenet, fido и нормальной почтой (но по IPX/SPX) не востребована.

Перечитай ещё раз тот эпитет, которым ты меня назвал, хам!

Перечитай ещё раз тот эпитет, которым ты меня назвал, хам!

После того, как ты сказал, что документацию не найти? Эпитет? Да и вообще я думал, что мы об абстрактном недоадмине говорим. Я же не виноват, что это ты оказался. :-)

Нельзя. Или, говоря другими словами: запрещено, прохибитед, ферботен. Если вы реализуете сценарий:

Даже так можно: изменения можно внести прямо в метаконфиг. Можно вот в качестве примера sendmail/cf/cf/ucbvax.mc глянуть.

вы реально ожидаете от меня примеров горбатых конфигов 20-летней давности или просто рассчитываете на то, что я не в состоянии их предоставить?

Я не про конфиги, а про задачи. На словах можете описать, что именно Вы хотели добиться от почтового сервера?

То ваш сменщик, глядя на метаконфиг будет заблуждаться, что он отображает реальность. Хуже всего, когда изменения незначительны. Это просто бомба замедленного действия и реальное вредительство.

Извините, но проблема надумана. Всегда можно вести журнал изменений, добавить в конфиг или в метаконфиг комментарии, словами предупредить сменщика. Вариантов много. И все они лучше того, о котором говорите Вы - молча оставить сменщика с набором макросов в файле мс.

Вариантов много.

И все плохие. Начну с конца:

словами предупредить сменщика

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

Всегда можно вести журнал изменений

Отлично. Теперь, чтобы узнать параметры системы, мне вместо одного места нужно проверить три: метаконфиг, конфиг и список изменений. А ещё в случае непонятного поведения предательский голосок будет шептать: «А вдруг кто-то что-то поменял, а в „список изменений“ внести поленился. Может такое быть? Или не может? Ну, а вдруг?».

добавить в конфиг или в метаконфиг комментарии

Это лучше, но всё равно лишнии сложности и путанница, и лишнии усилия для понимания что происходит.

что именно Вы хотели добиться от почтового сервера

на вскидку, босс хотел всю почту, отправляемую клиентам по паттерну subject, архивировать на сервере головной конторы. были клиенты, которые требовали smtp-over-ssl с сертификатами на обоих концах. были отправители, письма которых босс хотел лично просматривать и отправлять только если он форварднет, и чтобы отправитель и получатель не догадывались.

времена были те еще. и ни одному разработчику макросов для sendmail такое и в голову прийти не могло.

я понимаю, что для матерого спеца это все фигня. но для меня это была просто подработка. я ни разу не админ. мне хозяин квартиры арендную плату на $10 поднял и стало кисло. в 1998 дефолт бомбанул. выживали как могли. а в марте 99 я свалил.

я это все к чему. в розовом мире, где пони пукают бабочками, можно и sendmail замутить. это не эффективно, но возможно.

были клиенты, которые требовали smtp-over-ssl с сертификатами на обоих концах

В конце 90-ых? Первое упоминание SSL у Sendmail в RELEASE_NOTES про 8.11, а это 2000 год. Интересно, какие MTA это тогда уже умели...

я это все к чему. в розовом мире, где пони пукают бабочками, можно и sendmail замутить.

В Sendmail это замутить должно было быть можно. А вот чем ещё в то время - снова вопрос. А учитывая, что в то время ещё UUCP не очень умер, то вопрос про Sendmail становился безальтернативен.

^^^

какие MTA это тогда уже умели

туннель. и про uucp даже не заикайтесь - я в инкомбанке занимался именно этим, когда в россии про интернет даже не все слышали.

2:5070/52

и про uucp даже не заикайтесь

А что не заикаться? Одно дело, когда в чистом виде, а другое - когда надо, как раз, переход SMTP-UUCP получить. В чистом виде я тоже с этим позанимался, без SMTP и Интернет. И, отклоняясь от темы, могу вспомнить даже про такие штуки, как ftp-mail сервера. :-)

время было суровое

2:5070/52

Ноду я не держал, но поинтом бывал. :-)

поинт должен ноду два раза ку делать :)

в банкоматах везде была полуось и uucp. i know shit

и про uucp даже не заикайтесь

2:5070/52

Вы Fido с uucp не перепутали? ;)

По поводу задач понял, спасибо. Решались они с помощью Sendmail довольно легко (кроме SSL, но про это же написали).

а другое - когда надо, как раз, переход SMTP-UUCP получить.

У меня в такой конфигурации до середины 2000-х годов работало. Пока uucp-адреса окончательно не умерли.

в банкоматах везде была полуось

У меня тоже. Не в банкоматах. :-)

Вы Fido с uucp не перепутали? ;)

Вообще я решил, что он до кучи. Было бы неожиданно. :-)

время было суровое

Да нет, конец 90-х - это уже халява. У того же Sendmail уже mc есть. Да и доступ в Internet по ppp, а не по slip с ручной авторизацией ;).

Вы Fido с uucp не перепутали?

гейтовать я научился ранше, чем ты в штаны не ссать. инкомбанк обладал единственной сетью в россии, интегрированной в at&t и прочая.

прошу прощения, но достали уже

У меня они до сих пор местами работают :/

Ну я знаю, что сейчас модно что-нибудь не уметь и хвастаться об этом на всех заборах. Но причем здесь почта?

Смысловая нагрузка не обнаружена. Должно быть сообщение повредило при передаче.

У меня они до сих пор местами работают :/

uucp? Сегодня?? Очень интересно подробности узнать, если не секрет - в чем смысл использовать сегодня uucp?

Уже и сам емейл отмирает

С каких это пор?

всё норовят в мессенджер, коих тьма отписать.

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

// А е-мейл он один для всех.

гейтовать я научился ранше, чем ты в штаны не ссать

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

прошу прощения

Ok.

Решались они с помощью Sendmail довоочно не подпищусьльно легко

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

я был не прав. приношу искренние извинения.

Нет выделенок на участке. Нет и все (то есть нет и не будет). Радио нельзя (да и неоткуда). Да и пользователь один на 20км. На сотовых может сделают в следующем году, если никто не запретит. Просто совок, лес и странные люди. Интернет есть в 5км от участка, обновляторы ездят, да. Зато красиво.

А смысл в uucp что оно работает на тех «невыделенных» линиях на лапше по березам. PPP экспериментально поднимал, но блин, я так уже не могу и POP3 с 5-й попытки работает и удаляет письма, которые недокачались (подозреваю баги в их TheBat! которую они ставили). А ящик в углу у них как-то сам работает, почта ходит, линия свободна в основном, ничто не шуршит. TheBat! работает.

кто выбрал sendmail по тем или иным причинам, не смогут внятно объяснить, как это сделать.

За всех отвечать не готов. Сегодня самый простой способ - через милтеры. Так что sendmail.cf трогать не придется ;). Но в обсуждаемое время поддержки мильтеров в sendmail вроде бы не было (точно уже не помню, проверять лень). Так что остается три варианта - поднимать вторую копию sendmail, либо фильтровать исходящую почту с помощью procmail, задав соответствующий mailer в /etc/mail/mailertable. Оба способа также не требуют редактирования /sendmail.cf.

Ну и конечно, можно написать локальные правила подстановки адресов - либо непосредственно в sendmail.cf, либо, учитывая критику ugoday, через файл mc.

Как видите, путей решения много, и только один из них требует детально разбираться в правилах подстановки адресов ;).

Нет выделенок на участке. Нет и все (то есть нет и не будет). Радио нельзя (да и неоткуда). Да и пользователь один на 20км.

А какие плюсы uucp по коммутируемым линиям (я правильно понимаю, речь о телефонных линиях идет?) по сравнению с тем же esmtp поверх ppp?

На сотовых может сделают в следующем году, если никто не запретит.

Если сотовая связь есть, то вообще непонятен смысл коммутируемых линий.

Прошу прощения, не дочитал до конца и задал вопросы, на которые Вы же ответили. Спасибо. Хотя, конечно, история с почтовым клиентом странная.

не смогут внятно объяснить, как это сделать. я точно не подпишусь. а давайте прямо здесь и спросим

Сейчас так например:

        QUARANTINE:any text
                        Quarantine the message using the given text as the
                        quarantining reason.

For example:

        From:cyberspammer.com   ERROR:"550 We don't accept mail from spammers"
        From:okay.cyberspammer.com      OK
        Connect:sendmail.org            RELAY
        To:sendmail.org                 RELAY
        Connect:128.32                  RELAY
        Connect:128.32.2                SKIP
        Connect:IPv6:1:2:3:4:5:6:7      RELAY
        Connect:suspicious.example.com  QUARANTINE:Mail from suspicious host
        Connect:[127.0.0.3]             OK
        Connect:[IPv6:1:2:3:4:5:6:7:8]  OK

А смысл в uucp что оно работает на тех «невыделенных» линиях на лапше по березам.

А ещё ведь и докачку поддерживает, если склероз не изменяет. Без такого «по берёзам» совсем сложно наверное.

Connect:suspicious.example.com QUARANTINE:Mail from suspicious host

IMHO, это не совсем то - фильтровать надо не по серверу получателя, а по теме письма. Тут либо фильтр вроде procmail, либо с правилами заморачиваться (см. выше).

А какие плюсы uucp по коммутируемым линиям (я правильно понимаю, речь о телефонных линиях идет?) по сравнению с тем же esmtp поверх ppp?

Если я про докачку правильно помню, то вот оно. В случае PPP можно надеяться на быстрый реконнект с фиксированным IP, но если реконнект будет долгий, будет облом. Особенно если сообщение большое попадётся.

IMHO, это не совсем то - фильтровать надо не по серверу получателя, а по теме письма.

А, да. Не перепроверил, что по теме. Почему-то отложилось, что по отправителю: From и To использовать тоже можно. Если тема, то уже надо или milter, или макросы. В sendmail/cf/cf/knecht.mc есть пример работы с полями заголовка, в том числе и Subject, но тут надо думать будет про всякие Base64/QP.

В случае PPP можно надеяться на быстрый реконнект с фиксированным IP, но если реконнект будет долгий, будет облом. Особенно если сообщение большое попадётся.

Зато на ppp можно компрессию канала организовать - для почты это может дать существенный выигрыш (2.5-3 р.).

Я не говорил, что не найти. Теперь ты ещё и врёшь.