id: Гость   вход   регистрация
текущее время 11:21 29/03/2024
создать
просмотр
ссылки

Свой Gmail с преферансом и барышнями


Коллеги, подскажите, есть ли готовое решение для быстрого разворачивания своего mail-сервера, где каждый аккаунт будет сразу и mail и xmpp адресом?
Изначально выбор упал на Roundcube c плагином rc_openpgpjs
В идеале сразу зеркалить в скрытый сервис Tor и отдельный i2p-сайт.
Чтобы с бубном не танцевать, т.к. разворачивать придется часто – ищется готовое решение или отдельный скрипт-костыль.
В какой доменной зоне лучше всего зарегистрировать домен?
Что на счет паники 2016 года, касательно серверов за границей? Оплатить на 5 лет вперед или ничего страшного не произойдет?


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— SATtva (14/07/2014 14:14)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Стили должны располагаться в самом html документе, с помощью тега "style" или без него, и всегда подгружаться вместе с документом.

OMG. Картинки тоже в html встраивать?
— Гость (14/07/2014 16:58)   <#>
OMG. Картинки тоже в html встраивать?

Не, картинки много весят и это не кодовый объект, их проще отдельно.
А css файлы наоборот, только усложняют код.

Но картинки обычно итак загружаются, в крайнем случае, можно тянуть картинки на прокси-сервер, а дальше не качать. css имеет кучу подстроек под пользователя (стандартного пользователя нет), не грузить – тоже биты в профиль. Посему css суть диавол и его надобно изгонять всюду.
— SATtva (14/07/2014 17:54)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Вы, очевидно, не верстали ничего сложнее, чем <html><body>Hello world!</body></html>. Инлайн-стили в html — примерно такой же идиотизм, как в программировании монолитный код и смешение логики и данных.


Например?


Грузите, но не применяйте, кто ж мешает. Про картинки я спросил по аналогии, между ними и css нет никаких различий. При этом картинки могут нести такие последствия, какие не снились даже css3.
— Гость (15/07/2014 01:44)   <#>
Да зачем они нужны? Профилировать пользователей? (хотя бы по включенному css)

Стили позволяют создавать более чистый html-код. Например замена таблиц <table> блоками <div> делает вёрстку намного легче. Это конечно, если верстать вручную в текстовом редакторе, а не с помощью Dreamweaver или других генераторов html-кода. Кроме этого, правильная идея отделения дизайна тегов от структуры документа. Один бит в профиль – мелочь по сравнению с другими источниками. Баланс пользы и вреда на стороне CSS (речь опять только о базовой версии, не CSS3).

Стили должны располагаться в самом html документе, с помощью тега "style" или без него, и всегда подгружаться вместе с документом.

Не нахожу в этом никакого смысла, CSS-код интерпретируется одинаково, описан он в html или отдельном файле. В файле удобней задвать глобальные настройки для всего сайта, а в html описывать исключения для отдельных страниц.

Вообще, весь html код должен приводиться к эквивалентному каноническому виду, включая форматирование, причем за время линейно растущее от размера документа.

Бессмысленное требование с точки зрения безопасности и анонимности. Устанавливает новые ограничения без необходимости.
— Гость (17/07/2014 08:09)   <#>

Если физически сервер один, то да, он может отдавать контент одновременно в разные сети. Это как если у сайта есть два домена на одном IP. Другое дело — реально распределённая сеть для хранения данных, устойчивая к изъятию серверов (к слову, SATtva отказался такое реализовывать для pgpru.com; видимо, это сопряжено с большими сложностями).


Скрипты часто ставят на сайты с большим наплывом посетителей и DDoS-атаками для защиты от последних. JS позволяет легко фильтровать ряд DDoS'ов на веб-сервер (конечно, от DDoS'а на сам канал связи это не спасёт).


Семь бед — один ответ: виртуалки.


Не знаю, как в других браузерах, но в TBB GitHub выглядит отвратительно. В инете пошла новая мода: иконки, скруглённые картинки, кнопочки, много кнопочек, какие-то странные слишком крупные шрифты и много непродуманных элементов интерфейса. Наверно, сейчас все считают, что это выглядит модно и стильно. Сайт гитхаба, на мой взгляд, отвратителен.


Да, это всё так и есть. В пределе получается Перельман. Даже среди учащихся старших курсов это становится хорошо заметно: люди перестают следить за собой, вовремя мыться, одеваются, как бомжи, теряют интерес к чему-либо в реальной жизни. Они целиком и полностью погружаются в мир виртуальной реальности, где любое достижение в последнем, даже самое посредственное — уже что-то, а любой успех в «реальной жизни» — ничто. Такое же поведение прослеживается у гамеров/геймеров, у страдающих зависимостью от соцсетей, от наркотиков, алкоголя и пр.


Рабское сознание требует царя. Царь в науке — это эдакий сверхгений, который управляет миром. Тысячи людей не смогли догадаться, а он взял и догадался. История говорит о другом: одни и те же идеи появляются примерно в одинаковое время у разных людей. Если сообщество дозрело, оно сделает соответствующий шаг вперёд безотносительно того, будет там присутствовать один лишний «гений» или нет.
— unknown (17/07/2014 10:45, исправлен 17/07/2014 10:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Найдите простую Jekyll-тему. Там можно на уровне HTML "Hello World" и свою тему с нуля создать (есть примеры), если не найти подходящей готовой или никак не доработать напильником те, что есть.

— SATtva (17/07/2014 10:59)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Где-то на странице движка это обсуждалось. Главная сложность — доверие к узлам (их операторам), что они не станут искажать содержимое сайта, и у меня нет понимания, как в парадигме обычного веб-сайта (без надстроек в виде специального расширения на уровне браузера), пусть и распределённого, обойти это ограничение. С ним в модели угрозы возникает огромная дыра, не защищаться ведь только от изъятия сервера / отключения хостинга: взятие сервера/оператора под контроль (искажать данные может даже хостер) — атака примерно того же порядка.

От идеи зеркалирования я не отказываюсь (с возможностью раскрытия всей БД без существенной утечки данных), но точкой ввода данных может оставаться только один сайт.
— Гость (17/07/2014 11:24)   <#>

Первое, что приходит в голову — идея «браузер скачивает содержимое со всех зеркал, после чего сообщает, какие из зеркал отдают отличающийся контент, выдавая предупреждение». Действительно, я не знаю, как это сделать без доп. расширения на уровне браузера.


Раз большинство пишет через Tor, а читающее большинство пользуется сайтом не через Tor, можно сделать запись только через соответствующий onion-домен, а чтение — в том числе, через обычный домен в сети. ☺
— Гость (17/07/2014 12:50)   <#>
JS позволяет легко фильтровать ряд DDoS'ов на веб-сервер (конечно, от DDoS'а на сам канал связи это не спасёт).

Не могли бы привести пример, когда javascript защищает от ддоса? Ещё лучше если это будет единственно возможным способом.
— SATtva (17/07/2014 13:03)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Использование JS и cookies — обычные механизмы для отсечения паразитных клиентов, если атака ведётся на ресурсозатратную логику приложения. Как правило, DoS-боты не умеют обрабатывать JS и куки, что позволяет отличить их от полновесных браузерных клиентов.
— Гость (17/07/2014 13:41)   <#>
Выключены скрипты – значит бот, так что-ли? Выходит что вся "защита" основана на наивном предположении что боты не понимают скрипты. Кстати wget понимает куки (хотя речь не о них), а httrack умеет обращаться со скриптами. Всё же хотелось бы знать, какая ресурсозатная логика имеется в виду. Стандартный случай – сценарии на php/perl/python генерят html-страницы для Apache, возможно с использованием базы данных mysql. Каким образом javascript помогает пресекать атаки на ресурсы – не понятно.
— SATtva (17/07/2014 14:38)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Предположение в большинстве случаев оправданное, боты, как правило, не умеют исполнять JS.


Не способен обрабатывать JS → ты бот → не получаешь никакого динамического контента: тебе могут отдать заглушку (если сайт находится под атакой) или редко обновляемую статическую копию страницы из кэша.
— Гость (17/07/2014 21:56)   <#>
Получается что сам яваскрипт не защищает от доса. Сайт даёт говнеца в виде js, и если браузер не хочет его есть, значит он – бот. Гениально. При том, что есть стандартные средства защиты типа modsecurity.
— SATtva (18/07/2014 11:37, исправлен 18/07/2014 11:38)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Никто не утверждал об обратном.



Кому что кажется проще.

— unknown (15/08/2014 14:30, исправлен 15/08/2014 14:37)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В то время как всё прогрессивное человество (с Github) использует Jekyll, и для страниц сайтов, и для блогов.

Кому ещё нужен свой бложик с коментами и статическими страницами?


Haggis: A static site generator with blogging/comments support:


Haggis is a static site generator, written in Haskell. It allows you to write your blog posts in any format that pandoc supports, using your chosen directory structure and file names as the site's url structure.

To post comments, the templates of your pages should have an html form in them that posts to some kind of script which inserts posts into the database haggis points at. Optionally, this script could re-generate the entire site after each user post, or you could schedule this via a cron job.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3