А что в этом неадекватного? Клиент арендует адресное пространство. Накопление подобных неразрешенных проблем анализируется и, в зависимости от аналитика, может приводить как минимум к снижению репутации айпи адресов или диапазонов адресов, а иногда и к блокировкам на уровне того же Spamhaus. Излишне говорить о том, что это не нужно на самому дата центру ни его клиентам.
Что касается пересылки "ненужных" жалоб - тут вообще все предельно просто. Дата центр просто следует законодательству. Согласно законодательству Германии дата центр не может анализировать абузу - их функции ограничены пересылкой клиенту . Поэтому пересылать они обязаны, а разбираться в том, кто и что прислал - нет. Не ответил - получил блокировку. Все вполне корректно. Считаете, что абуза глупая - так и напишите, в этом случае, никто вас блокировать не станет.
Здравствуйте!
Не вдаваясь в подробности, такие ссылки стоит удалять, так как они реально могут вредить искомому ресурсу - ПС пессимизирует его рейтинг о чем собственно и написано. Вопросы тут скорее к ПС, конечно, но что есть, то есть. Вероятно, вы не ставите своей целью вредить кому либо и, если так, с легкостью удалите затребованную ссылку. Если же вы из тех, кто готов по любому поводу бежать на майдан, то вас будут учить, что это неправильно и необходимо соблюдать сетевой этикет, который подразумевает доброжелательность и готовность идти на сотрудничество когда это реально требуется.
Закона такого нет но, есть принятая сетевая этика.
От меня почта отправляется по защищенному каналу.
Вот именно что от вам до вашего почтового сервера. А дальше зависит от того, какой маршрут следования письма. От 1 до 5-10 и более хостов (серверов) может быть на пути следования вашего письма и в любой точке после вашего почтового сервера письмо может быть скопировано. Если трафик защищен по ssl/tls тогда его третья сторона (сбоку от передающего или принимающего сервера) перехватить не сможет. Но, сможет сторона имеющая доступ к передающему или принимающему серверу.
Поэтому, единственный вариант защиты - шифровать письмо пгп к примеру и слать его так получателю у которого есть вас публичный ключ. В этом случае, только он или вы сами сможете прочитать письмо и перехватывать его смысла не будет никакого (тупо не смогут прочитать).
Какой размер ОЗУ (оперативной памяти)
Термины надо использовать правильно. ОЗУ - оперативное запоминающее УСТРОЙСТВО.
Само собой звучит как бред в отношении шаред хостинга так как, при всем желании выпендриться, ни один хостер не может его "выделить" одному или нескольким клиентам. Он может только лимит установить - в пределах которого, пользователь может использовать имеющееся на сервере ОЗУ. Либо как, уже сказали выше - на процесс, либо как на общее использование аккаунтом клиента либо на то и на другое одновременно. В рамках виртуальных серверах в то же время, ОЗУ как термин может использоваться так как, хоть это ОЗУ виртуальное, но оно, как правило, гарантированное (в отличие от шаред хостинга, где память выделяется динамически и гарантирована либо изолирована от "соседей" быть не может).
Тема ТС не об аптайме и о технических проблемах, которые, конечно, случаются везде и всюду. Речь идет о недостаточно подготовленном (с точки зрения ТС) договоре, по мнению ТС позволяющим подать претензию к провайдеру. Поэтому не стоит ТС учить аптаймам, техническим ошибкам и прочему не относящемуся к теме топика.
Вопрос в целом интересный и без дополнительных фантазий:
а) Как доказать клиенту факт отправки письма? Представляется, что логи могут служить таким доказательством. Если, конечно, степень доверия клиента к провайдеру допускает прием таких доказательств. У ТС мы видим явно недостаточную степень доверия (возможно, она и обоснованна, мы здесь об этом судить не можем). Тем не менее, по запросу суда и/или компетентных органов, можно получить логи приема писем на стороне ТС и, таким образом, в результате сверки логов, получить вполне объективную картину произошедшего. Само собой, если степень доверия клиента была бы больше, хватило бы и лога провайдера об отправки сообщения клиенту.
б) Насколько я понял, письмо и не отправлялось. Возникает вопрос, почему, в таком случае, не была произведена повторная рассылка? Затрудняюсь сказать, какая рода ответственность может наступить у провайдера в результате этого, так как, это определяется договором и законодательством но, почти в любом договоре, указано, что основным средством коммуникации является сайт + емайл. Представляется логичным, что если письмо не дошло в результате действий третьих лиц (то есть сервис провайдера клиента или промежуточного хоста, который участвовал в пересылке сообщения), то любая ответственность с провайдера снимается. Но, если провайдер сам или в результате технического сбоя, не отправил письмо, то ответственность ложится на провайдера.
5.2 не поддерживается, обновления для закрытия уязвимостей не выпускаются. Да и джумла 1.0.15 уже фиг знает какой давности, дырявая как решето. Иметь такой сайт на хосте - считай дверь открыть всем. Если сайт не динамический проще всего было бы перевести его в чистый хтмл.
colocat.ru полет нормальный:
sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +41.0°C (high = +85.0°C, crit = +95.0°C)
Core 1: +35.0°C (high = +85.0°C, crit = +95.0°C)
Core 9: +36.0°C (high = +85.0°C, crit = +95.0°C)
Core 10: +34.0°C (high = +85.0°C, crit = +95.0°C)
А эти другие подключены к интернету тем же провайдером, что и вы? Открыл - быстро грузится.
Результаты определения размера страницы и скорость ее открытия у разных сервисов будет всегда отличаться, так как это зависит от того, какие именно скрипты используются + место размещения и качество связи между точкой с которой делают измерение и страницей которую собственно меряют.
Это был "сарказм" (с) если кто не понял :)
Это все города в Калифорнии.
