Нарушение правил передачи охраняемой компьютерной информации повлекшее блокирование компьютерной информации причинившее крупный ущерб это статья 274 УК РФ.
АртемЪ: Статья 1260 п.2 охраняет авторских права владельцев базы данных или сайтов на подборку информации. Это означает, что доступ к этим данным вы имеете на условиях соглашения, публикуемого владельцами сайта или базы данных независимо от авторских прав на отдельные статьи или записи. Публикуемое соглашение в данном случае выступает в роли договора оферты. С каких это пор договор оферты ничтожен?
robots.txt помимо прочего устанавливает технические ограничения на доступ к сайту, включая частоту запросов. Преднамеренное нарушение этих ограничений, при их наличии, приведшее к невозможности функционирования сайтов очевидно является умышленным.
Надо еще иметь ввиду, что владельцы сайтов могут запрещать сбор данных автоматизированными средствами + такой сбор может давать дополнительную нагрузку на сервер и приводить к его отказу, что в принципе уголовно наказуемо. Поэтому лучше следовать robots.txt и рекомендациям для спайдеров.
Павел: так а как вы их генерировали? Я не вижу большого смысла проверять ключи, если вы их делали с помощью какого-нибудь стандартного инструмента для DKIM.
Павел: возможно используется кэшированная DNS-запись, подождите немного. Проверьте пока письмо через dkimvalidator.com, он даст еще больше информации о том, почему бьется DKIM. И уточните, есть ли длинные строчки в теле письма.
Возможен еще вариант, что меняется содержимое письма после подписи. Чаще всего это бывает из-за неправильных переводов строк или слишком длинных строк в письме.
P.S. еще у вас в заголовке Content-Type треш, должно быть charset=utf-8. Но это не имеет отношения к проблеме, скорей всего.
Павел:
>Мне дали тот же самый DKIM только для селектора dkim
это нормально (хотя и не очень правильно) только в том случае, если вы экспортировали из яндекса приватный ключ и отдавали его хостеру. Лучше сгенерировать новую пару ключей, публичный ключ опубликовать как dkim._domainkey, а приватный клюс передать хостеру для использования в подписи.
Лучше продолжать использовать отдельный селектор для писем отправляемых с хостинга и опубликовать отдельный ключ для этого селектора (отличный от ключа используемого для "ручных" сообщений). Вообще лучше всегда использовать разные селекторы для разных категорий почты.
kernUSR: должно быть реализовано в железке. Как было сказано, многие управляемые свичи такую функцию имеют, дополнительного оборудования в таком случае не требуется.
Почти всегда именно по отраженному сигналу. Когда высокочастотный сигнал доходит до незаземленного оборванного "конца" кабеля - он отражается (т.к. поглощаться ему некуда) и идет в обратном направлении. По задержке и фазе отраженного сигнала можно установить дистанцию до точки обрыва, т.е. принцип практически тот же, что и в радиолокации.
В таком виде возможна replay-атака: один раз перехватываем хэш, а дальше повторяем его - и сим-сим открывается. Либо надо использовать challenge-response, когда используется не соль, а challenge присланный со стороны сервера. Но в любом случае перебирать возможные варианты - не самое удачное решение.
