December 19th, 2009

404

О WSUS'е с высоты пингвиньего полёта

Главное, что в нём бесит - это не его существование и возникающие при этом проблемы (это неизбежно). А совершенно, омерзительно тупой интерфейс у wuauclt. Невозможно понять, почему конкретно в этот момент он не хочет обращаться на сервер (да, я знаю про /detectnow и /resetauthorization). Он - всего лишь посылалка сигналов для сервиса. А сервис не имеет столь приятного сердцу режима -vvv[dc], как большинство уважающих себя демонов.

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

Собственно, о чём я? Ну починил я эту херню. Стал сервер снова доверять майкрософту и посланникам его. Отлично. Большая часть апдейтов накаталась. Осталось 3 апдейта. Пытаюсь поставить - ноль реакции. Просто НОЛЬ. Оно не пишет об ошибке. Оно ничего странного не пишет. Оно просто не реагирует на /detectnow. Более того, даже понять невозможно - оно не поставилось или ещё не отрапортовало на сервере...

И это типичное поведение - через N минут оно просрётся. Само.

А сейчас -
00-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.

И никаких соединений в netstat. Просто молчит. Сука.
404

Shikabane

Главное, что ужасает в Shikabane - это поток совершенно нелепых референсов на Еву. То каждая вторая аморфная тварь на Рей (в её критические дни) похожа, то Лилим видится, то вообще референс на финал ЕоЕ (Shikabane Hime Kuro 11 18:20), то Синдзик местами проглядывает, то намёки на Аску...

И всё это как-то совсем вяленько и не по делу.
404

(no subject)

Гугль встроил в линукс-версию Хрома бэкдор. С какой целью не знаю, но встроил. При установке deb-файла он самовольно добавляет посторонний репозитарий в aptitude и прописывает его как доверенный.

from kastaneda via alexkuklin
404

Эксчейнж, релей и SPF

Конструкция: релей на постфиксе (сендмейле) смотрит в интернет, за ним спрятан эксчейнж (2007).

Предыдущая почтовая система была настроена на перезаписи адресов (т.е. релей менял user@inetdomain.ru на user@localdomain.ru и пересылал на эксчейнж).

Подумал я, что сие не кузяво, объявил эксчейнж авторитетным за inetdomain.ru и сделал релей простым ретранслятором. Оно работает, но эксчейнж кладёт в спам и пишет (интересное выделено жирным):

Received: from relay.ru (192.168.0.16) by exchange.domain.ru
(192.168.0.12) with Microsoft SMTP Server id 8.1.393.1; Sat, 19 Dec 2009
22:00:20 +0300
Received: from desunote.ru (desunote.ru [95.161.2.76]) by relay3.ru
(Postfix) with SMTP id D01959BBC for <user@domain.ru>; Sat, 19 Dec
2009 21:59:55 +0300 (MSK)
Message-ID: <20091219190002.D01959BBC@relay3.ru>
Date: Sat, 19 Dec 2009 21:59:55 +0300
From: <amarao@desunote.ru>
To: undisclosed-recipients:;
MIME-Version: 1.0
Content-Type: text/plain
Return-Path: amarao@desunote.ru
X-MS-Exchange-Organization-PRD: desunote.ru
X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (ex-srv-02.norma.spb.ru: domain of transitioning
amarao@desunote.ru discourages use of 192.168.0.16 as permitted sender)

X-MS-Exchange-Organization-SCL: 7
X-MS-Exchange-Organization-PCL: 2
X-MS-Exchange-Organization-Antispam-Report:
DV:3.3.8414.660;SID:SenderIDStatus SoftFail;OrigIP:192.168.0.16


Каким образом эксчейнж можно принудить к принятию для SPF-проверки не для того, кто ему это прислал, а того, кто прислал релею? Или вообще SPF из-за этого выключать? -_-.....
404

Кстати, об SPF

Вообще говоря, я сейчас задумался - и я не понимаю, каким образом при SPF вообще могут существовать резервные MX'ы. Если сервер принимает почту от резервного сервера, то sender_ip не тот, который разрешён в SPF. Если мы добавим IP резервного сервера в белый список, то тогда и спам, прошедший через него, мы тоже примем.

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

Нашёл статью на эту тему: http://blogs.3sharp.com/deving/archive/2007/01/11/2773.aspx

Грустно. Получается, SPF не совместим с "пост-фильтрацией"...

В принципе, я вижу альтернативный метод - дописывать в письма заголовок для эксчейнжа (с неким уровнем порядка 1-5) и принуждение эксчейнжа к добавлению этого уровня для дальнейшей оценки контента....

За вычетом этой красивой схемы, я не вижу возможности учитывать SPF. Точнее, пока видится такая картинка:

RBLPTRSPFaction
inbad/nonefailreject
inbad/nonenonereject
inbad/nonepassreject
inokfailreject
inoknonereject
inokpassreject
not inbad/nonefailreject
not inbad/nonenonereject (????)
not inbad/nonepassaccept
not inokfailreject (????)
not inoknoneaccept
not inokpassaccept


Итого, 2 случая, когда SPF does matter:
1) Хост не в RBL, но имеет тупой PTR. При этом он разрешён для домена. - pass
2) Хост не в RBL, имеет нормальный PTR, но запрещён для отправки - reject.