Curiouser and curiouser!
А все зло в проприетарном драйвере. Несмотря на прописанное
Option “UseFastTLS” “2″
в xorg.conf, разные ‘on execute access’, ‘on write access’, ‘on read access’ вылеты остаются. Пока что, вобщем-то, решение одно. Откатиться на какие из более ранних версий драйверов. У меня что-то работало на 8.1, что-то на 8.2. Ждем включения 3D поддержки в свободном драйвере radeonhd. Чтобы забыть про fglrx, как про страшный сон.
Открыл для себя Америку. Оказывается некоторые хосты, в том числе рамблер при приеме почты делают обратную проверку получателя. Если их хост заблокирован по каким-то причинам, то и принимать почту с блокирующего хоста они не будут.
SMTP-02861(ilimpulp.ru) [142336561] return-path rejected, got:578 xxx@xxx address rejected with reverse-check
Такая вот патовая ситуация получается. Наверно это побочный эффект, основная цель все-таки в проверке, существует ли такой отправитель.
Updated: К этому же типу относится ошибка типа:
“451 Could not complete sender verify”.
Для тех, кто любит банить подсети, ну или просто пытается составить себе картину, с каких адресов больше всего валится спам. Есть замечательный ресурс:
http://www.spamcop.net/spamstats.shtml
Помимо “Worst /24,/16 blocks based on total spam count or on spam ratio” там есть чертовски удобная вещь: “Browseable map of IPv4 netspace”. Для каждого из диапазонов ip можно посмотреть наиболее спамовые подсети. Собственно, благодоря статистике спамкопа я сначала пришел к довольно не новой мысли о необходимости банить динамические и диалапные диапазоны. Впоследствии там же нашел dyn/dial диапазоны Turketelecom, которые неохвачены ни pbl.spamhaus.org, ни в dul.dnsbl.sorbs.net.
Единственное - затрудняюсь сказать, какая периодичность у них в обновлении данной информации.
Учитывая масштабы спама одолевающего в последнее время - все больше задумываюсь над разными алгоритмами блокировки этой гадости. К примеру, на одном из хостинговых серверов по работе статистика следующая: По совокупным усилиям всех rbl листов и черных списков за сутки
заблокирован прием почты с 200283 уникальных ip, которые пытались
отправить почту 3263992 раз. Больше трех миллионов…
В последнее время получило довольно широкое распространение блокировка всех non-MTA customer ranges, то бишь тех диапазонов, которые предполгают лишь доступ в интернет, а отправку почты только через smtp сервер интернет-провайдера. Весьма целесообразное решение, но весь впорос в его конкретном вооплощении.
Можно использовать rbl листы:
pbl.spmahaus.org ( за удовольствие стянуть полностью зону rsync’ом нужно будет платить)
dul.dnsbl.sorbs.net
dul.ru
Минус - некоторое, но постоянное отставание от реального положения дел, так как постоянно добавляются новые подсети,
существующие меняются и переодически появляется некоторое
количество хостов в таких подсетях, которые используются как почтовые сервера отдельных организаций и у частных лиц.
В некоторых куроводствах в интернете можно встретить рекомендации блокировать по паттернам в обратной зоне по примерному регекспу:
pool|modem|dial|cable|client|dsl|dhcp|dyn|ppp.
Основная мысль - если человек хочет отправлять почту со сервера, размещенного да adsl канале или в домашней сети, то он сделает нормальную обратную запись. Остальные идут лесом. То есть, в отличии от rbl листов - не надо никакого выносить из какого-то блок-листа. Как только администратор сделал нормальную обратную запись - все в порядке, почта ходит.
Естественно, что для того, чтобы не блокировать почту с нормальных хостов нужны более конкретные регекспы, пусть даже они будут значительно более сложными. Добавлю сюда свои несколько копеек. В качестве эксперимента собрал по этому регекспу список хостов за сутки на одном из серверов. Получилось 66571 уников:
#wc -l uniqhosts
66571 uniqhosts
#head uniqhosts
dsl88.241-38078.ttnet.net.tr
adsl-598433fb.monradsl.monornet.hu
pool-71-115-197-105.spknwa.dsl-w.verizon.net
82.200.213.84.dial.online.kz
dsl88-226-60417.ttnet.net.tr
8-219-112-92.pool.ukrtel.net
bl4-220-22.dsl.telepac.pt
96.89.220.87.dynamic.jazztel.es
201-92-50-50.dsl.telesp.net.br
201-34-151-6.jvece702.dsl.brasiltelecom.net.br
По количеству вхождений получилась следующая статистика:
#grep modem uniqhosts | wc -l
236
#grep client uniqhosts | wc -l
1448
#grep dhcp uniqhosts | wc -l
1667
#grep dial uniqhosts | wc -l
3470
#grep cable uniqhosts | wc -l
4045
#grep pppoe uniqhosts | wc -l
4756
#grep pool uniqhosts | wc -l
7820
#grep ppp uniqhosts | wc -l
8139
#grep adsl uniqhosts | wc -l
12105
#grep dynamic uniqhosts | wc -l
15091
#grep dyn uniqhosts | wc -l
19182
#grep dsl uniqhosts | wc -l
29025
Если делать более точными регекспы во избежание блокировки
нормальных хостов, типа pppoe.org и *dsl*, то кол-во совпадений
естественно снизится. Кто-то этим может пренебречь, но для предоставляемых сервисов клиентам это недопустимо. В принципе, по всех обратным зонам проcлеживается некоторая тенденция, которая наверняка описана в этом документе: http://www.tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00, но мне его было лень читать, поэтому нашел сам.
По получившимуся регекспу улов получается значительно более весомый:
#cat uniqhosts | perl -lane ‘print if m/(\d+(\.|-)){3}[a-zA-Z]/’ | wc -l
47878
Рекомендую 
Конечно, лучше использовать все в совокупности, поскольку ни одно из средств не дает стопроцентного результата.
Ну и под конец опишу еще один вариант поддержания информации о таких сетях в актуальном состоянии. Этот вариант будет работать только с добросовестными интернет-провайдерами, которые не ленятся прописывать названия сеток и как-то это дело структурировать:
$ whois -h whois.ripe.net PIPEX-DSL-DYNAMIC| grep inet | awk ‘{ print $2 ” ” $4 }’ | while read net; do ipcalc -r $net; done | grep -v de
81.178.128.0/17
81.179.64.0/18
81.179.128.0/18
81.179.192.0/18
85.210.64.0/18
85.210.0.0/18
85.210.128.0/18
85.210.192.0/18
85.211.0.0/16
81.178.70.0/23
81.178.72.0/21
81.178.80.0/20
81.178.96.0/19
Несколько полезных ссылок:
http://www.senderbase.org/
http://www.db.ripe.net/whois
http://ipindex.homelinux.net/index.php
В процессе обсуждения в списках рассылки dovecot@dovecot.org
поднятого мною вопроса о невозможности компиляции xexec с версией 1.1 Stephan Bosch сделал патч, который я, соответственно, протестировал у себя. Пропатченный модуль нормально работает с новой веткой dovecot 1.1, которая, правда, пока находится на стадии rc, но этой весной должен выйти стабильный релиз.
Патч и уже пропатченную версию модуля я, с разрешения авторов модуля и патча, поместил в вики.
Прямые ссылки на файлы:
Из-за пертрубаций в dovecot вики выложил файлы и у себя:
Наиболее подробное описание процесса на Рейзером. Обновляется после каждого заседания суда.
На ‘американском’ английском.
http://blog.wired.com/27bstroke6/hans_reiser_trial/
Производит, правда, довольно тягостное впечатление, как оно все там тянется 
Согласно рекомендациям Timo я сделал такой простейший патч:
— src/master/mail-process.c.orig 2008-03-18 19:55:04.000000000 -0400
+++ src/master/mail-process.c 2008-03-18 19:55:35.000000000 -0400
@@ -75,7 +75,8 @@ mail_process_group_lookup(enum process_t
struct mail_process_group lookup_group;
lookup_group.process.type = type;
- lookup_group.user = t_strdup_noconst(user);
+ /*lookup_group.user = t_strdup_noconst(user);*/
+ lookup_group.user = “”;
lookup_group.remote_ip = *ip;
return hash_lookup(mail_process_groups, &lookup_group);
@@ -89,7 +90,8 @@ mail_process_group_create(enum process_t
group = i_new(struct mail_process_group, 1);
group->process.type = type;
- group->user = i_strdup(user);
+ /*group->user = i_strdup(user);*/
+ group->user = “”;
group->remote_ip = *ip;
i_array_init(&group->processes, 10);
— src/login-common/sasl-server.c.orig 2008-03-19 09:36:56.000000000 -0400
+++ src/login-common/sasl-server.c 2008-03-19 09:37:21.000000000 -0400
@@ -51,7 +51,7 @@ master_callback(struct client *client, e
case MASTER_LOGIN_STATUS_INTERNAL_ERROR:
break;
case MASTER_LOGIN_STATUS_MAX_CONNECTIONS:
- data = “Maximum number of connections from user+IP exceeded”;
+ data = “Maximum number of connections from ip exceeded”;
break;
}
call_client_callback(client, reply, data, NULL);
patch
Вcе работает, но имхо, это может быть только временным воркэраундом, так как работает не так, хотелось бы. Оное ограничивает только кол-во _логинов_ с одного ip. Может кому-то это покажется тем же самым или совсем несущественной разницей, но при этом не ограничиваются коннекты, их можно
сделать сколько угодно, переполнив пул соединений сервера. Так
что будем ждать более правильного решения. Правда в мейллист
все-таки отпишусь, чтобы как-то повлиять на предполагаемую реализацию сего. Кстати, хотелось бы иметь возможность
ограничивать как общее кол-во соединений с ip, так и кол-во соединений к конкретному аккаунту.
Вчера в мейллист dovecot’а написал вопрос об возможных путях решения вопроса об ограничении одновременного кол-ва коннектов с одного хоста, как это можно сделать, опять же, в том же CGP. На что уже сегодня получил ответ от Timo (автора dovecot’а) и еще один.
> Hi everyone!
> >
> > I want to manage mail server resource part (like it can CGP) and with it
> > I have one question. Is any way to limit overall max simultaneous
> > connections to imap/pop3 server from one(each) host, except use
> > iptables/ipfw and so on? Like a patch to dovecot or, maybe, it can be
> > released in future versions?
Probably in future versions.
> > I know about
> > mail_max_userip_connections in dovecot 1.1
It should be pretty easy to patch this code to ignore the user and just
limit IPs. You could basically just remove “user” from struct
mail_process_group and fix the code to compile. Or even easier:
static struct mail_process_group *
mail_process_group_lookup(enum process_type type, const char *user,
const struct ip_addr *ip)
{
user = “”; // use the same empty user for everyone
// …
static struct mail_process_group *
mail_process_group_create(enum process_type type, const char *user,
const struct ip_addr *ip)
{
struct mail_process_group *group;
user = “”; // use the same empty user for everyone
и
Sounds like
> > Probably in future versions.
could be trivially implemented with a “mail_process_group_lookup_key”
setting that defaults to %u
Opensource всячески рулит Есть решение на уровне патча для исходных текстов, а также, возможно, это будет реализовано в более поздних версиях. И то и другое хорошо. Первое я даже попробую реализовать в ближайшее время.
//Странно, что этот вопрос никто не задавал до меня. Хорошо, что я его задал. Если это еще и реализуют, это будет совсем прекрасно.
Всем приятной ночи :-)
Немного в продолжение предыдущего поста. Я обещал написать про
xexec. В процессе все тех же поисков рулеза нашел в документации
dovecot’а информацию про этот модуль. Помечен, как
экспериментальный, но мне думается не в силу качества кода,
а в силу того, как они сами написали, что его действия не попадают в стандарты rfc по imap протоколу и, соответственно, не поддерживаются никакими клиентами.
Имхо, замечательная вещь, возможно, в будущем панацея для системных администраторов почтового сервера. Собственно описание можно ограничить одной фразой с сайта:
“Execute any server side application and communicate with it through plugins over IMAP”
Для начала немного примеров:
# telnet 127.0.0.1 143
Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
* OK Dovecot ready.
001 login viliar@dungeon.local xxxXx
001 OK Logged in.
002 xexec user
* OK User: viliar@dungeon.local, effective uid: 2003
002 OK command exited successfully
Теперь чуть подробнее
003 xexec more
* OK Dovecot gave next info about you:
* OK your account viliar in domain dungeon.local
* OK home at /home/mail/dungeon.local/viliar/ and your uid 2003
* OK connected by IMAP service
* OK local ip 127.0.0.1, your ip 127.0.0.1
003 OK command exited successfully
То есть плагин используется в контексте пользовательского процесса, с
его привелегиями! Теперь давайте вспомним, что я писал про passwd-like файлы. Можно на стороне нарисовать очень простой интерфейс, который будет проверять полученные данные от довекота о пользователе, проверять входные данные и менять файлы конфигурации, которые созданы под его юидом. Никакого доступа к чувствительной информации. Кайф? Не то слово.
Ну и так, до кучи поменяем пароль:
004 xexec chpass XdaRT34
* OK password successefully updated
004 OK command exited successfully
005 logout
* BYE Logging out
005 OK Logout completed.
Connection closed by foreign host
На стороне сервера это будет выглядеть примерно таким образом:
/etc/dovecot/dovecot.conf
plugin {
quota = maildir:ignore=Trash
xexec = date:/usr/local/bin/date
xexec2 = user:/usr/local/bin/user %u
xexec3 = chpass:/usr/local/bin/chpass %u
xexec4 = more:/usr/local/bin/more.sh %n %d %s %p %l %r %h %i
}
Скрипты могут быть любыми, хоть как тут для примера, на баше. Это не то узкое место, где обязательно нужно оптимизировать, потому что эти скрипты не будут так часто запускаться и обрабатывать бешенные обьемы информации, как какой-нибудь демон типа spamassassin, которому с точки зрения ресурсов стоит предпочесть написанный на сях dspam.
Плюсы очевидны. Гибкость и безопасность. Если, условно, сравнить с postfixadmin, хотя это сравнение, я понимаю, не очень корректно, так как сравнивается протокол и интерфейс администрирования. Скорее я сравниваю и то и другое как возможность администрирования почтового сервера и это касается скорее не самого postfixadmin’а, а методов работы таких “вебморд”.
У них, как правило, конкретная привязка к определенному типу хранилища. Ну может быть к нескольким однотипным, на основе sql. Postfixadmin работает только с mysql. Это ограничивает нас существенно. И этому, возможно, очень замечательному интерфейсу я должен дать _полный_ доступ до базы. Это самое ужасное. При возникновении дыр в нем самом, или специфических дыр в php в этом случае можно, простите за выражение, огрести по полной. При совокупности дыр, через mysql, если кому-то придет нелепая идея использовать его еще для чего-то, можно тоже
получить и утечку данных и все-такое. Но это уже из области допущений и можно в расчет не принимать. Но все равно несекурно
совсем как получается. Можно ограничить доступ до административного интерфеса при помощи basic auth и вобще заставлять пользователей ходить только через https. Таким образом мы уменьшаем число потениальных взломщиков только до числа зарегистрированных пользователей. Но это из разряда вспомогательных решений и не хотелось бы надеяться только на дополнительные меры. Хочется секурного “из коробки”, чтобы в основании были более безопасные методы работы с информацией.
При использовании xexec мы получаем возможность использовать любой интерфейс на стороне сервера и на стороне клиента, то есть веб-приложения. Написать, например, модуль для squirrelmail. И это будет
значительно более безопасное решение, потому что веб-интерфейсу мы не даем ключ от квартиры пароль от базы, где лежат
все данные. Ну а если доводить идею об безопасности до абсурда, то сквирмейл, во избежания модификации скриптов, если будут дыры - держать на read-only разделе с единым профилем для всех. Шучу.
Это так, немного информации к размышлению и очередной бонус
активно развивающемуся проекту dovecot. Модульность рулит