• Mein Konfig: экскурсия по dotfiles
    0
    > Почему не писать в tmpfs, а не в шифрованный раздел?

    Ну потому что всё же view/undo и прочее мне нужно :-). Это точно не эфемерная информация. А так да: можно и в tmpfs бы было.

    Если ваш терминал умеет много наворотов, то согласен что от tmux-а многий функционал отпадает. Держать приложения в tmux это только для «надёжности»: вдруг X11 отвалится, вдруг dwm, вдруг st или ещё чего. Ну а для серверов это must-have, ибо канал связи может когда угодно отвалиться.

    sendmail команда всюду и везде будет фигурировать, ибо и Postfix и Exim «эмулируют» её поведение — можно сказать что это такой API.

    % pkg which =sendmail
    /usr/local/sbin/sendmail was installed by package postfix-3.3.1_1,1
    


    Касательно urlview и URL-ов терминала: мне кажется что терминал не может чисто технически точно знать информацию об URL. У меня полно встречаются очень длинных URL-ов, которые не умеющаются на одной строке экрана. Если эта строка будет показана в Vim, то чисто технически это длинная часть URL на одной строке, далее идёт вторая строка, начинающаяся с колоночек Vim-а (всякие номера строк, fold, ...), а потом продолжение части длинного URL. Терминал не имеет представление что кусок одной строки является продолжением второй. Mutt при wrapping строчек любит рисовать красный "+" — терминал же тоже не знает что этот "+" не является частью длинной URL строки. Некоторые приложения, знающие ширину экрана, после каждой визуальной строки могут вставлять "\n", а какие-то не парятся по этому поводу — тоже может смутить терминал. Согласен что удалённый Mutt тогда не сможет у меня локально что-то запустить, поэтому… тут применяю tmux перехват экрана для парсинга URL-а… получая все те же самые потенциальные проблемы (с длинными URL) как и обычный бы терминал :-). Я URL-ы в терминале парсил когда-то в urxvt — не спорю что это конечно тоже бывает удобно.

    Про ~/.Xmodmap спасибо за намёк — надо будет поискать. Возможно у меня другие коды клавиш посылаются и из-за этого всё равно он будет нужен.

    >F2 далеко от home row

    Это аргумент из той же серии как и Escape, часто используемый в vi, тоже далеко находится. Парировать мне нечем — действительно далеко :-). Есть знакомые которые Esc на другие клавиши переносят. Но… вот честно, даже Esc никогда не парил меня. Просто наверное привык так часто проводить рядом с этим высоким рядом клавиш своими руками, что просто не замечаю. А если более серьёзно подойти к этому вопросу, то есть мнение что рукам тоже нужно давать «волю» и временами выполнять не совсем на 100% эффективные действия (чтобы они двигались рядом с одним местом, грубо говоря), заставляя их переносить к отдалённым клавишам чтобы хоть насколько то давать им отдых, сбрасывать напряжение от 100% эффективности. Есть просто такое мнение, которое греет мои Esc и функциональные клавиши — типа для здоровья полезнее, пускай и небольшим падением КПД.

    > Имхо удобнее это делать выставлением формы курсора

    Хм, даже не знаю как эта форма меняется, если честно — не силён тут в терминальных штуках. Но если её можно поменять какими-нибудь escape-последовательностями (и st терминал это поддерживает), то мне этот вариант однозначно нравится!

    > Microsoft Outlook

    Понимаю что был бы я в других организациях, то это могло бы и навредить, но от спама это ОЧЕНЬ хорошо помогает!

    > ~/work/pyderasn

    habr.com/ru/post/444272
    habr.com/ru/post/498014
  • Mein Konfig: экскурсия по dotfiles
    0
    Спасибо! Выглядит интересно и достойно, но мне не хватает возможности множественного выбора (fzf -m). Я действительно очень часто выбираю сразу по несколько элеменов предложенных, особенно для git команд.
  • Mein Konfig: экскурсия по dotfiles
    +3
    Сейчас даже использование слова «master» будет задевать миллионы людей. Не поверите, но я спросил и коллег и родителей, не возникает ли ассоциации с чем-то непотребным у моего названия — ни у кого не возникло. В страшное мы время живём, раз написать «my config» по немецкий (или вообще всё что связано с «mein k*»?), из-за того что у меня этот язык по умолчанию, будет задевать людей.
  • Mein Konfig: экскурсия по dotfiles
    +3
    Отсылкой бы был «mein konf». А у меня на компьютере немецкий язык по умолчанию.
  • Идеальный пароль по науке: трудно взломать, невозможно забыть
    0
    Для открытия зашифрованного диска у меня парольная фраза под 120 символов, а для PGP ключей под 100. Набираю каждый день и не один раз. Около 40 символов для SSH ключей. Даже не задавался вопросом удобно ли это, ибо без проблем набирается шустро.
  • Почему я по-прежнему пользуюсь RSS
    0
    Всю информацию и новости, кроме почтовых рассылок, получаю из RSS/Atom. Newsboat как читалка. И из года в год количество feed-ов на которые я подписан всё только растёт и уже приближается к 400: www.stargrave.org/Links.html. Там же их список можно скачать и в recfile формате, и в XBEL и OPML.
  • Пользуемся офлайн-браузингом, как будто сейчас 1995 год
    0
    Согласен. И, более того, авторы сайтов, как правило, и не заинтересованы в этом содействии.
  • Пользуемся офлайн-браузингом, как будто сейчас 1995 год
    +2
    Сейчас есть даже де-факто стандарт для архивирования web-сайтов: en.wikipedia.org/wiki/Web_ARChive (WARC). А вообще можно используя GNU Wget делать «зеркалирование» (--mirror) целых сайтов, автоматически заменяя внутри HTML-ек ссылки с абсолютных на относительные и иметь возможность локально в offline смотреть сайты. Wget может из коробки и WARC-и делать. На python есть программы которые позволяют в режиме прокси «путешествовать» по .warc файлам. Тема offline-а не мертва, все инструменты до сих пор вовсю имеются. В документации к NNCP (утилиты для store-and-forward обмена данными) даже есть раздел посвящённый WARC-ам и пересылкам друг другу целых сайтов: www.nncpgo.org/WARCs.html. Учитывая всё разрастающуюся цензуру в Сети, это точно будет всё актуальнее.
  • Знакомство со Skein
    0
    «В конце хотелось бы упомянуть области применения хеш-функции Skein...» — упомянута только часть применений описанных в Skein reference whitepaper. Tree-hashing очень полезная штука, имеющаяся и в BLAKE(2?), помогающая распараллеливать вычисления хэша, в BLAKE3 вообще сразу из коробки работающая для «больших» сообщений. Skein из коробки имеет возможности для задания randomized hashing и personalization. Кроме PRNG Skein может безопасно использоваться и для симметричного шифрования. Всё это штатно предлагается и описывается к применению авторами Skein.
  • Знакомство со Skein
    +1
    «алгоритм Skein уступил в финале SHA-3 более быстрому и менее уязвимому Keccak» — это очень голословное утверждение, так как Keccak был одним из самых медленных среди всех конкурсантов, а Skein быстрым, причём как на «больших» компьютерах, так и на встраиваемых процессорах. www.skein-hash.info/sha3-engineering eprint.iacr.org/2010/531.pdf. Как и утверждение про «уязвимость» Keccak vs Skein, мягко говоря, очень спорное (на чём основано?). Среди требований к SHA3 было и то, что хэш наоборот не должен быть слишком быстрым, что возможно было одной из причин «проигрыша» Skein. По анализам www.researchgate.net/publication/235677375_Security_Margin_Evaluation_of_SHA-3_Contest_Finalists_through_SAT-Based_Attacks вообще Skein имеет самый высокий порог безопасности, тогда как Keccak плетётся в конце финалистов SHA3. BLAKE считается имеет очень большой «запас прочности» и в BLAKE2 даже снижали его, ради производительности (BLAKE2 поэтому в целом очень и очень популярен во множестве задач, ибо быстрее MD5, при этом всё равно имея высочайшую безопасность).

    «Изначально созданные для повышения эффективности цифровых подписей» — вообще криптографические хэш функции появились задолго даже до протокола Диффи-Хельмана, не говоря про асимметричные подписи: crypto.stackexchange.com/questions/56404/what-was-the-first-hash-and-what-problem-was-it-supposed-to-solve

    «что показало наличие уязвимостей в алгоритмах и ставило под сомнение безопасность электронной цифровой подписи на основе данных хеш-функций» — тоже очень громкое утверждение. Проблемы с коллизиями есть у SHA1. Потенциально могут быть в теории у SHA2, который имеет схожую конструкцию. Это не значит что они есть, не значит что конструкция сама по себе плоха, не значит что SHA2 уязвим/сломан, поэтому на данный момент, даже когда создают какие-то системы с нуля (например Git переводят с SHA1), то всё равно продолжают с чистой совестью выбирать SHA2, так как SHA3 даже по производительности не покажет ощутимые плюсы и его выбор мало даст очевидных и осязаемых преимуществ. Никто от SHA2 не избавляется и не считает его уязвимым. А смысл перехода на SHA3 у многих вызывает скепсис.
  • Шифруем по-русски, или отечественные криптоалгоритмы
    +2
    В LibreSSL ГОСТовые есть, в GnuTLS тоже. В OpenBSD, DragonflyBSD, HardenedBSD и ряде GNU/Linux дистрибутивов вообще LibreSSL по умолчанию ставится, соответственно и наши алгоритмы из коробки идут.
  • Кунг-фу стиля Linux: великая сила make
    0
    Если что, то распараллелить команды можно и через GNU parallel (небольшая программа на Perl): parallel «convert {} {.}.png && touch -r {} {.}.png && rm {}» ::: *.bmp. Плюс не будет проблем с пробелом.
  • Шифруем по-русски, или отечественные криптоалгоритмы
    +1
    www.gost.cypherpunks.ru/Russian.html — а вот тут собраны ссылки и на другие стандартизованные алгоритмы, тоже активно используемые в «наших» TLS/CMS протоколах, типа MGM, ACPKM, SESPAKE.
  • Кунг-фу стиля Linux: великая сила make
    0
    apenwarr.ca/log/20181113 — mtime крайне мало даёт гарантий.
  • Кунг-фу стиля Linux: великая сила make
    +6
    Вот только сейчас Make не справляется с поставленными для него задачами (из-за использования mtime для определения свежести целей) и требует изучения нового декларативного языка (а точнее одного или сразу нескольких диалектов Make). Можно ничего нового не изучать и писать на любимом языке, полностью выполняя все аналогичные задачи: habr.com/ru/post/517490
  • Потроха IPsec, меримся с TLS 1.3, ГОСТ и Go
    0
    Лично я тоже считаю что для «обычных» домашних применений это всё допустимо. И действительно оно *очень* экономит round-trip-ы, что особенно заметно в WiFi/сотовых сетях с бОльшими задержками. Кроме того, что это всё нужно включать, так ещё и application протоколы тоже должны уметь этим всем пользоваться и предоставлять EarlyData (или pre-Finish application data со стороны сервера) при вызове функций запуска TLS handshake.
  • Потроха IPsec, меримся с TLS 1.3, ГОСТ и Go
    0
    Я не хочу сказать что EarlyData это прям не безопасно. Это просто спорный tradeoff. В ГОСТ TLS 1.3 решили что этот режим работы не допустим. RFC на TLS 1.3 считает позволительным. Каждый сам решает за/против.
  • Потроха IPsec, меримся с TLS 1.3, ГОСТ и Go
    0
    Верно, только при продолжении сессии по iPSK. Но EarlyData отправляется до Finished сообщений, до того, как противоположная сторона вообще ответила TLS-handshake пакетом, не говоря о том, что аутентифицировала handshake сообщения. С одной стороны: мы отправляем зашифрованные данные, на ключе который может знать только знающий iPSK и поэтому вроде бы ничего опасного. С другой стороны: это всё равно остаётся отправкой application данных ещё совершенно не аутентифицированной стороне.
  • Потроха IPsec, меримся с TLS 1.3, ГОСТ и Go
    0
    * Не утверждали что оно по безопасности хуже. Просто ваш неиссякаемый сарказм натолкнул меня на это. Ok. SIV режим мне тоже нравится.
    * Всё зависит от реализаций. Я видел и более быстрые аппаратно ускоренные Кузнечики, чем AES-ы. Про timing атаки не поспорю — но это касается и AES-а того же в той же степени.
    * Поэтому чтобы не получиться nonce reuse и говорят про 127/63 векторы инициализации. Мои реализации MGM явно проверяют верхний бит и не дают такое использовать. Nonce reuse фатален.

    Это всё не nonse-reuse-resistant алгоритмы, использующие таблицы замены — да, это всё мне тоже не нравится. Но я изначально только сказал что MGM является улучшенной версией. Да, не уточнил по какому параметру. С безопасностью у него лучше. И мне очень нравится что у нас безопасность ставят выше остального. Удручает двойное применение шифрования? Поставьте в два раза больше шифраторов/процессоров — не такое уж оно всё и медленное в софте (а в железе не проблема).
  • Потроха IPsec, меримся с TLS 1.3, ГОСТ и Go
    –2
    * MGM в каком-то месте в плане безопасности хуже?
    * Не ясно что не так с производительность Кузнечика (реализаций его куча, варианты оптимизаций (предрасчёт таблиц) тоже есть)
    * Посмотрите для чего применяется nonce и увидите что верхний бит используется для указания режима (шифрование/аутентификация). Я думаю в любую реализацию MGM передаётся 128-бит nonce, просто верхний бит обнуляется и MGM явно показывает потерю энтропии в этот 1-бит

    Не ясен ваш сарказм на пустом месте.
  • Make на мыло, redo сила
    0
    А какая разница как описать структуру проекта? Декларативно или в виде набора команд с флагами разными? Грубо говоря, количество информации которое вам, как разработчику, нужно ввести в компьютер, чтобы объяснить ему правила для сборки — и в том и в другом случае одинаковое. Но для декларативного описания нужно изучать этот yet another декларативный формат/язык. Если все ваши .c файлы (например) собираются во всём проекте с одними и теми же флагами, то можно обойтись одним мизерным default.*.do файлом хоть в корне проекта. Описания опций/флагов/параметров/путей до зависимостей — что в CMake файлах, что в shell скрипте занимают одинаково места. С CMake у меня несколько месяцев назад был небольшой опыт в большом проекте — с ходу вот прям не вспомню где бы он мне ощутимо больше/лучше помог, чем redo-like подход.
  • Make на мыло, redo сила
    +1
    А в чём проблем shell-а? В чём не комильфовость? Всё равно на нём же пишутся (в Unix-like системах, конечно же) все вызовы того как и что надо собирать. Но redo не обязывает писать на shell — многие реализации позволяют использовать любой язык или просто исполняемые файлы, лишь бы вызывали redo-* команды.
  • FreeBSD: гораздо лучше GNU/Linux
    0
    Что это без баша не прожить? Много лет назад как избавился от него на всех своих системах, так и нету его. Бесполезен. Причём раньше я ещё встречал частенько какие-нибудь (не свои) скрипты написанные на «bash», а не POSIX shell — сейчас такого значительно меньше.
  • Российские госсайты: иллюзия безопасности
    0
    Только при этом с криптографией для паспортов облажалась по полной: www.usenix.org/system/files/sec20summer_parsovs_prepub.pdf arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids
  • Российские госсайты: иллюзия безопасности
    0
    Про Chrome я отталкиваюсь вот от этого: victor-sudakov.livejournal.com/388776.html — чего-чего, но причём тут «инструмент разработчика»? Предполагается что простой пользователь не должен штатно управлять своими довериями?
    Про Firefox уже смутно помню конкретику, но запомнилось что со временем вроде тоже менялось в менее доступную сторону.
  • Российские госсайты: иллюзия безопасности
    0
    Я понимаю что он будет пугать, но шифрованное соединение у него при этом будет, что более безопасно чем совсем нешифрованное. Пользователь, как правило, всё равно «под контролем» нескольких корпораций, производящих ОС/броузер: если они не доверяют тому-то, то обойти это решение пользователю будет проблематично. У самого под рукой современных броузеров нет, но наслышан что там сертификатами всё сложнее управлять или чуть ли уже невозможно добавить собственные.

    Вы постоянно говорите про «мирное»/«военное» время — у меня таких понятий (касательно сайтов в Интернете) в голове нету, поэтому я не могу ответить на вопрос с подобным делением времени. Информационная война ведётся постоянно, особенно если речь про США. CA отвечает за аутентичность ресурса. CA либо доверен (для обоих сторон), либо нет: либо он может/хочет/будет мухлевать с аутентификацией ресурса, либо вероятность такого близится к нулю. Ну а дальше вопрос критичности/ценности данных ресурса. Обсуждения пёсиков клуба города XXX наверное не представляют никакой ценности и там плевать какой CA. А официальная информация госсайтов представляет. Отсутствие TLS при этом (сосед Вася может ваш трафик менять) — непорядок. Но броузер пользователя предупредит что «имей в виду что информации на экране верить нельзя, ибо соединение ничем не защищено». В идеале пользователь должен быть на стороже и пытаться аутентифицировать информацию (если ему надо) ещё и сторонними способами. С «не доверенным» CA пользователю скажут что всё ok, промолчат что аутентичность зависит не только от сайта ФСБ, но и от третьей стороны за границей (на данный момент) — именно она (почему то) решает что госинформация вашей страны является аутентичной.
  • Российские госсайты: иллюзия безопасности
    0
    На практике никто криптографические примитивы почти никогда не атакует: считанные случаи (DRM там) когда это делали. Криптография это непробиваемая стена, но которую в 99% случаев можно обойти (атаковать реализации, ОС, железо, людей, итд).

    Не понял про «в исполнении NIST». Наша эллиптика это ГОСТ Р 34.10. Математически вычисления идентичны ECDSA/ECDH/whatever — придуманные математиками задолго до. ГОСТ кривые и реализации никак не связаны с NIST или его решениями.
  • Российские госсайты: иллюзия безопасности
    +1
    Сужение круга атакующих это не плохо, но пользователю не говорится что «сужен круг» — ему сообщается что «соединение защищено», «соединение безопасно». Новых векторов атаки не появляется, но может (в броузерах) появится, вводящее в заблуждение, сообщение о безопасности.

    Я то только за внедрение TLS на подобных ресурсах (точнее, я бы хотел чтобы IPsec везде был, ибо TLS-у места в идеальном IPv6/IPsec мире нет :-), но это отдельная тема)! Кухню ФСБ/СВР не знаю, но вряд ли там позволят сгенерировать сертификат и просто на жёстком диске его Web-сервера иметь — нужно решение посерьёзнее (в плане защиты приватных ключей), плюс ещё думать что делать с дублированием серверов (на них иметь свои собственные приватные ключи или один и тот же скопировать?). Задача включения TLS не тривиальна.

    Здесь главный вопрос всё же не про безопасность (в принципе то оно безопасно от прослушивания кем попало, ибо шифрование применяется в любом случае), а ghj аутентификацию и аутентичность данных с сервера. Недоверенный CA (с точки зрения ФСБ) аутентичности не добавит. С таким же успехом можно сделать самоподписанный сертификат и приватность/безопасность пользователя, за счёт шифрования, будет обеспечена. Это всё равно лучше чем отсутствие TLS, безусловно.
  • Российские госсайты: иллюзия безопасности
    +1
    Если любому, то это я бы и назвал «иллюзия безопасности». Иллюзия это когда вам говорят что всё безопасно, но на самом деле это не так. Отсутствие TLS не строит никаких иллюзий: пользователь чётко понимает что у него не безопасное соединение и он оценивает риски. Когда же используется TLS но «не очень» доверенный, то это иллюзия: вроде бы как и безопасно, а так шут его знает, не поймёшь.

    TLS в госкомпаниях используется вполне себе (тем более и на ГОСТовой криптографии), но только в условиях когда CA сертификаты (не глобальные) явно подкладывают руками и софтом являются application-specific клиенты, а не «general purpose» броузеры и люди. А для для «обычного» пользователя приходящего на сайты — всё плохо, это да.
  • Российские госсайты: иллюзия безопасности
    +2
    Интересно какой же CA будет отвечать за аутентичность сайтов ФСБ, МВД, СВР и прочих? Кому эти организации могут доверять как третьему доверенную лицу между ними и пользователем? А теперь какой из доверенных CA есть у всех этих пользователей в их броузерах и ОС? Ниодного, потому что софтом управляют де-факто компании зарубежные. Чтобы поднимать TLS на наших сайтах — нужно иметь доверенный нашим государством и нашими пользователями CA: пока такого ещё не сделали и под большим вопросом сможет ли он попасть в Microsoft/Apple/Google ОС/броузеры при этом, ведь это же исключительно политический вопрос.
  • Где прячется Российская электроника
    +3
    Хотя бы о криптографии приходится многим слышать, связанным с криптографической защитой: www.gost.cypherpunks.ru/Russian.html
  • Единый реестр российских программ и GPL. Мои пять копеек
    +7
    «софт под GPL практически не пригоден для извлечения прибыли путем его доработок и распространения дистрибутивов на коммерческой основе» — а Торвальдс, тысячи оплачиваемых разработчиков вносящих свой вклад в Linux (по сути ядро то пилится исключительно за деньги на коммерческой основе), покойный Ян Мёрдок (не бедный человек), RedHat, Google, Facebook знают что прибыль нельзя было извлекать?
  • Неожиданные HTTP-заголовки
    –1
    www.gnuterrypratchett.com — ещё один вариант заголовков, реализующих «GNU» протокол, для того чтобы Терри Пратчетт оставался в нашей памяти.
  • Введение в TLS для п̶р̶а̶к̶т̶и̶к̶о̶в̶ Патриков (часть 1)
    0
    Лично по мне — одна фигня. Им недоверяю одинаково. Причём централизованной штуке я бы априори меньше доверял, ибо лакомый кусочек для контроля и атак.
  • Введение в TLS для п̶р̶а̶к̶т̶и̶к̶о̶в̶ Патриков (часть 1)
    0
    В этом случае жадный мистер Крабс будет отвечать за валидацию DNSSEC. Причём с ещё меньшим выбором CA. Только DNSCurve нам поможет (+DANE под ним).
  • 15 мая RU-Center может добавить вам платную услугу без вашего участия
    +1
    Сделать что? Написать им «я тут получил сообщение, где сказано чтобы я с вами связался и дал вам документы»? И что я получу в ответ: «да, мы хотим получить от вас документы»? Если их ответ попадёт в личный кабинет, то что мешало сразу в нём оставить сообщение о том что да, они действительно хотят документы. У меня не укладывается в голове для чего нужен этот round-trip. Если моё сообщение должно завести тикет, в контексте которого дальше мы там с ними будем общаться и передавать документы, то почему бы тикет сразу не завести? Это не укладывается в голове, не логично.

    А что логично, так это то, что в их сообщении написано не просто про /contant, а то что документы можно отправить прямо по email в PDF формате. Если люди уж продолжают вестить на выигрыши в миллион долларов от нигерийского принца, то уж в это то тем более поверят и многие отошлют свои документы. Смысл этого письма исключительно только в этом, а /contact и прочее это для отвода глаз. Какой смысл в этом если ответное письмо идёт от пользователя на support.gandi.net? Да, это могло бы быть странно, либо спамеры слушают трафик SMTP и видят корреспонденцию до support.gandi.net (между ДЦ и прочее) и это целенаправленная атака на клиентов Gandi. Не вижу в этом ничего нереального, ибо наслышан как всё плохо с безопасностью у большинства компаний.

    Похоже, меня в этом письме напрягло больше всего их «may send us these documents by email in PDF». Если бы не это, тогда действительно я бы не понимал зачем спамеру такое отсылать, какой profit.
  • 15 мая RU-Center может добавить вам платную услугу без вашего участия
    +1
    Со своего сервера я могу форсировать использование TLS только до первого hop-а (до mail*.gandi.net например), а дальше я уже не знаю как там и что дальше пойдёт. Может MX сервера находятся в одном ДЦ, а другие hop-ы в другом и между ними нет шифрования и оно гоняется между гос-вами. Безусловно, это же касается и любого рода серверов, но https до gandi.net Web-страницы это всё же endpoint их, а свою почту они может дальше просто на gmail.com ящики отправляют.

    «продвинутый фишер сможет легко подделать письмо любой сложности» — поэтому важно чтобы его как-то можно было бы аутентифицировать как-то ещё. В личном кабинете нет, ссылок на какой-нибудь rt.gandi.net нет — ничего нет. Вариант «спросить поддержку» наверное для большинства пользователей сойдёт, но я такой вариант не ожидал. Поддержка же в любом случае заведёт тикет, что-то мне напишет, что окажется в личном кабинете — что им мешает сразу там что-то написать?

    Узнать что что-то можно сделать только почтой, само собой. Если спамер послал сообщение, мы потратили время и зашли в кабинет, но ничего не увидели связанного с сообщением — значит это был спам, мы потратили впустую время. но, ничего, бывает, главное что не стали на него отвечать или переходить по подозрительным ссылкам (если бы они были). Это худший вариант — мы потеряли время, но и спамер в общем-то ничего не получил (если мы конечно ему не ответили PDF-кой как он и хотел). От российских регистраторов (а я был на nic.ru, потом r01.ru (или наоборот), теперь на reg.ru) все письма что приходят — так или иначе светятся в кабинете. Или сами письма/сообщения или alert/alarm о том что домен протухает или что-то там требуется.

    Если люди не читают почту потому что можно подделать — это очевидно не правильно. Читать то можно, но нельзя аутентифицировать (просто): она может быть либо от спамера, либо легитимна и нужно убедиться в последнем, зайдя в личный кабинет или ещё куда-то, боле доверенное чем email.

    «Как, по вашему, могло выглядеть из письмо без шанса быть подделкой» — без криптографии, то что это не подделка я не могу точно узнать, но если оно содержит ссылку на https:// rt.gandi.net (гипотетический) или оно будет присутствовать в сообщениях личного кабинета (где, подчеркну, даже вся их новостная реклама есть), то этого будет достаточно для того, чтобы поверить в легитимность этого письма. Спамеру точно нет никакого резона давать ссылки на настоящие тикеты.
  • 15 мая RU-Center может добавить вам платную услугу без вашего участия
    0
    А если проблема в ментальности… ну, тогда тем более я правильно что пользуюсь услугами своих же регистраторов :-), хоть и грабителей (судя по комментариям людей тут, хотя лично я с этим не сталкивался, но у меня и доменов то несколько штук и на лицевом счёте никогда лишнего нет и даже DNS сервера свои использую), но зато не теряю домены :-)
  • 15 мая RU-Center может добавить вам платную услугу без вашего участия
    0
    Моим же первым (ну может вторым) письмом в поддержку был вопрос, собственно, как мне отправить документы то безопасно то них? Не, безусловно, если бы я не посчитал это спамом, начал бы переписку с поддержкой и выложил бы документы, то само собой блокировок доменов бы не было. Но проблема в том, что я никогда бы не мог не посчитать подобное письмо (и его отсутствие в личном кабинете) не спамом. Так что чего уж мечтать то…
  • 15 мая RU-Center может добавить вам платную услугу без вашего участия
    +1
    Как я могу настроить или повлиять на использование TLS между SMTP серверами? Это невозможно. От клиента (MUA) до сервера — могу. Надеятся (только надеяться) что от сервера до gandi SMTP будет только один hop — могу. А в общем случае я никак не управляю и не знаю будет ли TLS в SMTP использован.

    Если ссылка будет вести на gandi.net, тот самый, на который я сам всегда логинился, то для меня этого будет достаточно. «Похожие» ссылки (то бишь фишинг)… ну об этом вроде бы всех пользователей устали предупреждать что это такое.

    Скорее вы правы в том, что сколько PGP/DKIM/whatever не суй, но простому пользователю это будет всё параллельно. К сожалению. И наверное тоже может быть разумно не тратить время (зарплату технарей) на поддержку всей этой криптоинфраструктуры, ибо ради небольшого меньшинства не стоит оно того. Ну что ж… именной по этой причине, значит, Gandi лично мне и не подошёл и я был «отключен» от мира на несколько дней (благо что всего несколько дней! многие MTA наверное даже не успели удалить у себя из очередей письма недоходившие до меня).

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