М-м-м-м... Надо бы внимательно поизучать pfctl -s all на предмет сгенереных динамических правил, и, если в них все кошерно - смотреть в tcpdump на предмет ISN.
Есть мнение, что правило по keep state создается на пару src_ip / dst_ip + dst_port. А если это так, то с одной и той же машины сколько хочешь соединений провалится.
Конкретнее сейчас ничего не скажу, надо тору почитать, посмотреть поподробнее.
telnet запускаете с одной и той же машины?
Уже запущенные telnet-сессии не дохнут к тому времени, как вы следующие три запускаете?
lftp mirror :-)
Есть такой фтп-клиент, lftp. Консольный, умеет скрипты. В нем есть коммандулька mirror, делает ровно то, что тебе надо.
Соответственно, вешается на рабочем столе ярлык, делающий
lftp ftp://user:pass@host/path/to/web -c 'mirror htdocs'
При клике на этом ярлыке оно синхронизирует каталог htdocs с сервера.
Гм. Удобнее, чем один раз нажать на кнопку?
Тогда не знаю.
lftp, функция mirror.
postfixadmin.
Лично я поставил один раз, и снес. Оно требует существенно более сложную структуру БД для хранения пользовательских данных, чем самописное :-)
Все верно. Только вот кастомизация такого решения может стать серьезной проблемой - если вам нужно сделать что-то сложнее правки шаблона веб-почты.
А, да, еще - интерфейс к антивируснику есть. А сам антивирус - отдельно, за деньги :-)
Увы, поддержка ответит исключительно про их софт.
Имею богатый опыт скрещивания коммунигейта с биллингом, и дофичивания еще кое-какого коммерческого почтового софта - во всех случаях ТП не отвечала на вопросы вида "почему ваша система не авторизуется у меня в LDAP".
За exim не скажу. Подобное собирается на postfix + dovecot + spamassasin + clamav за час, единственное, что нужно изобретать - веб-интерфейс администрирования сервера. Хотя есть и готовые.
CommuniGate.
А, простите, коммерческий продукт - принципиально? Я как-то ни разу не видел коммерческого почтового сервера, который бы интегрировался во что-то проще, чем свободный.
В моих железках все операции управления почтовым сервером делаются инсертом и апдейтом sql-таблицы :)
Вопрос ценника. Дорогой специалист дорожит своей репутацией.
И тут работает предыдущий аргумент. Увы, эта область деятельности достаточно узка, люди вобщем-то одни и те же.
Отдельно замечу, что пытаться кинуть действительно грамотного специалиста - себе дороже. Нужно иметь под рукой человека более высокого класса, чтобы не поиметь проблем. Много раз уже видел, чем заканчиваются такие дела.