`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 подписи там может и не быть. Дата скорей всего может быть установлено по заголовкам, которые должны быть в нотариально заверенном скриншоте, но их разумеется там нет, потому что нотариально заверенные скриншоты должны делаться с экспертом, а хороших экспертов... ну вы поняли.
haniaman, по крайней мере хром - да, только через расширения. Firefox тоже не поддерживает в стандартных настройках, но возможно поддерживает в каких-то сценариях типа командной строки или PAC, не тестировал
Признак конца файла может появляться и пропадать не только в терминале, например
1. Читаете файл
2. Получаете EOF
3. Пишете тот же файл (возможно через другой дискриптор)
4. Флушите файл
5. Читаете файл
Получите вы EOF или нет зависит не только от системы и libc, но и от конкретного устройства, и на разных ФС может быть разное поведение, например у IBM поведение документировано и здесь указано что последующее чтение может пройти без ошибки, а здесь что конкретно на HFS и терминалах автоматически этого не происходит.
Причем в вашем примере вы тоже читаете и пишете одно и то же устройство (терминал или консоль), и результат потенциально может поменяться, например, если вы уберете fprintf. А может и не поменяться. В целом надо учитывать что тот файл, который вы читаете может в какой-то момент "вырасти". Если вы хотите учитывать такие ситуации - сбрасывайте признак конца файла через clearerr(), если вы добавите clearerr() в ваш пример - он будет вести себя одинаково везде. Обычно принято после получения EOF завершать обработку. Но, например, в утилите tail есть опция -f, без нее утилита завершится после EOF, а с ней будет ждать не вырастет ли файл и с ^Z / ^D это работает ожидаемым способом (т.е. без -f tail завершается по ^Z / ^D, с -f продолжает чтение)
для генерации кода используйте /dev/urandom или криптографически стойкие ГПСЧ, длину кода делайте такой чтобы было не менее ~100 бит. Если необходимо делать короткие коды, то обязательно ограничивайте количество попыток на пользователя и делайте рейтлимиты на ip в единицу времени
rand() не является криптографическим ГПСЧ и его значение можно угадать или вычислить. Поскольку код подтверждения генерируется по событию пользователя, атакующий при таком способе генерации кода будет знать его время генерации и может вычислить код не имея доступа к письму с подтверждением
`a` ест 1 разрешение имени и при этом тоже вам не нужен (у вас даже PTR на этом IP нет)
getcourse.ru убирайте на отдельный домен - там полный треш или по крайней мере уносите в конец SPF записи чтобы он не топил остальные сервисы
Прописывайте везде DKIM, потому что в плане авторизации домена SPF и DKIM взаимозаменяемы и для надежности лучше иметь и то и другое