Есть закон и справедливость и это как известно, не тоже самое. Вы пытаетесь отбиться от наказания в рамках закона. Ваше право. Думаю что внутренняя справедливость каждого хабра юзера уже сделала свой выбор. Вам бы уже не на Хабр писать, а на юридический ресурс какой-нибудь…
Где-то прочитал, что каждый день надо съедать по одной «жабе». И гордится, что ты её съел. Поэтому неприятную пятиминутную работу стараюсь делать с самого утра ещё до всего (чая/интернета/аськи/перекура) иногда даже не раздеваясь. Зашёл, с порога сожрал «жабу» и весь день доволен. =)
Как добрые люди делают NAT на Linux на пару тысяч абонентов?
Вопрос в алгоритме использования диапазона белых IP. Если делать NAT одним правилом iptables большую серую сеть на небольшую белую, то Linux будет случайном образом выделять белый IP для каждого потока от абонентов. В этом случае некоторые сайтики (vkontakte, например) перестают нормально работать.
Можно ли поменять алгоритм использования диапазона белых IP?
Workaround известен. Нужно делать NAT маленькой серой сетки на один белый адрес. Но не удобно как-то…
Защита от dead lock реализована так — всегда принимать на адрес double-bounce@$myorigin. А если поменять address_verify_sender на что-нибудь своё?
Я к тому, что использование этой опции требует изучения подводных камней, а не просто включения. А то получается медвежья услуга.
Если бы статья была «проверка обратного адреса — плюсы и минусы». И в итоге вы показали бы, что для вас плюсов больше, чем минусов… Тогда бы я с вами согласился.
Не рекомендую использовать проверку обратного адреса (reject_unverified_sender). Достаточно много подводных камней. Самое простое — dead lock. Если два сервера будут с этой опцией, то как они смогут обмениваться почтой?
Статья похожа на обзор базовых возможностей, так что проверка обратного адреса тут точно лишняя. На практике поймаете несколько плохо диагностируемых проблем.
Считаю, что каждому своё, кому то лучше живётся с чёткими целями.
Прочитав статью понял, что я живу набором желаний. Поток жизни сам подкидывает мне возможности, главное не прозевать ;-). Заранее я слабо представляю себе какое из желаний реализуется первым. В этом смысле мысль материальна. И конечно, это не освобождает от труда и борьбы с лёнью
Да, про отсутствие определения ЭЦП… Смысл тот же что и структура статьи. Краткость определения в выводах даёт большой плюс к пониманию, чем просто объяснения.
Вопрос ближе к религиозному. Это ваш стиль изложения, возможно кому-то будет ближе…
Строго говоря — согласен. Применительно к данной статье НЕТ. По моему в статье идёт речь именно о ТАКОЙ цифровой подписи и для введения в криптографию определение подходит.
Кстати, не вижу правильного/вашего определения ЭЦП ;-)
Множество навыков, даже собранные в одну картину, это светлое пятно где-то в тёмной «комнате», при этом не понятно где стены. Такие навыки часто помогают увидеть решения, но они не помогут ясно увидеть, что решения НЕТ (в этой комнате).
Как то в школе у меня был набор навыков в Pascal вполне себе цельная картинка, мне нравились массивы чисел и рисование всяких поверхностей, но мимо меня прошла часть про строки. Как вы думаете что мне попалось на олимпиаде? Задача про кроссворд! И я даже её решил. Слово — массив строк, элемент буква. Куча циклов… Вообщем, решение не из той «комнаты»…
Я вот умею сжимать Гигабайт в 783 байта, а 10 Гигабайт в 7506 байт.
dd bs=1048576 count=1024 if=/dev/zero | bzip2 -z -c > zero.bz2
2 минуты идут длинные гудки, потом короткие гудки.
СМС-ки о пропущенных звонках при выключенном телефоне приходят.
Автоответчика нет.
Надеюсь всё так и останется.
Если работа по душе, то статья в тему. И, пожалуй, 3-х часовая «жаба» это слишком =). Надо искать другое определение и решение.
Вопрос в алгоритме использования диапазона белых IP. Если делать NAT одним правилом iptables большую серую сеть на небольшую белую, то Linux будет случайном образом выделять белый IP для каждого потока от абонентов. В этом случае некоторые сайтики (vkontakte, например) перестают нормально работать.
Можно ли поменять алгоритм использования диапазона белых IP?
Workaround известен. Нужно делать NAT маленькой серой сетки на один белый адрес. Но не удобно как-то…
Я к тому, что использование этой опции требует изучения подводных камней, а не просто включения. А то получается медвежья услуга.
Если бы статья была «проверка обратного адреса — плюсы и минусы». И в итоге вы показали бы, что для вас плюсов больше, чем минусов… Тогда бы я с вами согласился.
Вообще стоит почитать www.postfix.org/ADDRESS_VERIFICATION_README.html и особенно раздел Limitations of address verification.
Статья похожа на обзор базовых возможностей, так что проверка обратного адреса тут точно лишняя. На практике поймаете несколько плохо диагностируемых проблем.
Прочитав статью понял, что я живу набором желаний. Поток жизни сам подкидывает мне возможности, главное не прозевать ;-). Заранее я слабо представляю себе какое из желаний реализуется первым. В этом смысле мысль материальна. И конечно, это не освобождает от труда и борьбы с лёнью
Вопрос ближе к религиозному. Это ваш стиль изложения, возможно кому-то будет ближе…
Кстати, не вижу правильного/вашего определения ЭЦП ;-)
Но чувствуется бессистемность, что ли. Стиль изложения — зацепились за ниточку и раскручиваем «клубок», по мне так лучше разложенное по полочкам.
Лучшим для начала считаю
Введение в криптографию с сайта www.pgpru.com.
К сожалению так и не увидел определения ЭЦП. Объяснения есть, определения нет. Что из этого нужно в «сухом остатке»?
Цифровая подпись определённого человека — это результат хэш-функции документа, подписанный закрытым ключом этого человека.
И, пожалуйста, не называйте результат хэш-функции цифровой подписью. Пишите хотя бы «почти ЭЦП».
Как то в школе у меня был набор навыков в Pascal вполне себе цельная картинка, мне нравились массивы чисел и рисование всяких поверхностей, но мимо меня прошла часть про строки. Как вы думаете что мне попалось на олимпиаде? Задача про кроссворд! И я даже её решил. Слово — массив строк, элемент буква. Куча циклов… Вообщем, решение не из той «комнаты»…