accountnujen, IV как раз и нужен для того чтобы каждый раз получался разный результат и нельзя было между собой сравнить два шифрованных блока, аналогично соли в хеше. Поэтому сам по себе IV не секретен и хранят его так же как и соль, с результатом.
accountnujen, зачем его делать одинаковым? IV делают рандомным, просто хранят его вместе с результатом шифрования. Даже если вы дважды шифруете одни и те же данные - получите два разных результата с разными IV.
Пример не валиден, т.к. порядок команд имеет значение, proxy должна идти в конце, после задания ACL и редиректа.
Помимо этого, так стоит делать только в том случае, если порт 20001 будет прописан как HTTP прокси в клиенте. Если надо просто отобразить порт на порт, то достаточно команды
sendmail в данном случае просто название бинарника, чтобы из командной строки почту отправлять, а в качестве MTA стоит exim. Соответственно настраивать надо exim, а не sendmail.
Ставить sendmail не надо, это пережиток прошлого, сейчас обычно используются exim или postfix.
Многие получатели пессимизируют письма с доменов без MX-записей или полностью их блокируют, например в postfix есть такое правило, поэтому MX лучше делать всегда, даже если он совпадает с A-записью.
`mx` ест 2 разрешения имени и при этом вам не нужен
`a` ест 1 разрешение имени и при этом тоже вам не нужен (у вас даже PTR на этом IP нет)
getcourse.ru убирайте на отдельный домен - там полный треш или по крайней мере уносите в конец SPF записи чтобы он не топил остальные сервисы
Прописывайте везде DKIM, потому что в плане авторизации домена SPF и DKIM взаимозаменяемы и для надежности лучше иметь и то и другое
> а может сразу у хрома есть подобные ключи \ флаги в глубине настроек?
Насколько я знаю, по крайней мере раньше такого флага в хроме не было.
> но ping как рыба об лёд только с -6 работает даже если у домена только ip6
Все это знависит от того, по какому алгоритму пинг выбирает адрес назначения по имени. Этот алгоритм зависит от клиента и может (и будет) не совпадать с алгоритмом в Хроме. Используйте прокси, он гарантирует приоритет разрешения имен
Да, для клиентов поддерживающих RFC 6724 и не поддерживающих Happy Eyeballs тередо пессимизируется правилом приоритета равенства лейблов у адреса назначения и исходного адреса, для тередо они будут различаться. Можно попробовать решить это удалением префикса для тередо или заданием одинаковых лейблов для тередо и IPv6, но не уверен дает ли такое Windows и какие будут побочные эффекты.
Quqas, 2a03:2880:f213:e4:face:b00c:0:4420 и 157.240.205.174 это AAAA и A записи для одного имени, на уровне роутинга или трансляции адресов они никак не связаны и зная один из этих адресов никак нельзя получить другой (в общем случае). Приоритет имел бы значение, например, если бы был IPv6 стек с трансляцией IPv4 over IPv6, чтобы IPv4 мог ходить поверх IPv6, тогда за счет приоритета можно было бы выбирать куда идет IPv4 трафик. У тебя IPv4 и IPv6 ходят по разным сетям, поэтому все определяется тем, во что разрешилось имя.
ValdikSS, в случае dual stack клиент резолвит имя либо в IPv4 либо в IPv6 адрес и дальше делает коннект с этим адресом и попадает в соответствующий стек. Поэтому ответ про Happy Eyeballs более чем разумен.
Alexey Dmitriev, список обзора держит имена клиентов, он не хранит IP адреса, механизм разрешения имени в IP адрес не связан с обозревателем, это разные сервисы
Все это не так, отметка времени есть в DKIM-подписи и ее делает сервер, поэтому получатель подделать не может. Но чтобы это доказать нужна экспертиза полученного письма достаточно компетентным экспертом, а их нет. Опять же, если полученного письма нет, есть только письмо в отправленных положенное туда по IMAP, то DKIM подписи там может и не быть. Дата скорей всего может быть установлено по заголовкам, которые должны быть в нотариально заверенном скриншоте, но их разумеется там нет, потому что нотариально заверенные скриншоты должны делаться с экспертом, а хороших экспертов... ну вы поняли.
