- А какие очки-то? Сколько у меня диоптрии? - Вы приходите на осмотр, платный, мы посмотрим и скажем.
Хах. Похоже это общее. Если вы проходите медкомиссию для работы - вам там везде годен и поставят - "хотите результат - приходите по направлению или платно"
Вообще в видео автор говорит, что кейсов со сгаллюцинированными бумагами настолько много, что он просто перестал о них делать видео (у него на канале как минимум 3 таких). Это конкретный кейс - самый выдающийся что он видел.
Насколько я понял, адвокаты сами сознаются, так как это несёт меньше проблем чем "я целенаправленно соврал". Но вообще там типичные признаки: сгалюцинированные кейсы которых никогда не было и несуществующие
То есть в случае для входа используется именно пара email/пароль?
Логика говорит, что наверное стоит спрашивать email как он был введён пользователем изначально. Пользователь знал, что он делал. Наверное. Кроме, может быть, таки регистра, потому что многие считают и ожидают что email регистронезависим. А если нужно отправить email - использовать адрес в точности как его ввёл пользователь. Если вы при регистрации отправляли письмо и пользователь подтвердил получение - то вы уже знаете, что письмо дойдёт.
Аналогично. Я не говорю что вы должны делать case sensitive на почтовом сервере. В rfc написано сервер может делать с ними что ему вздумается, пока он следует корректному синтаксису адресов. Хоть всю почту в один ящик скинуть.
Вопрос именно в том, как сторонние сервисы воспринимают адрес получателя. Для максимальной совместимости "нормализовать" (к чему?) и менять регистр нельзя.
"Не приветствуется" и "никогда не случится" - это разные вещи. Лично я исхожу из принципа, что нужно следовать пессимистичному сценарию: - С точки зрения сервиса отправляющего почту - что адреса должны быть именно в той форме, в которой адрес дал ему пользователь, иначе почтовый сервис не доставит письмо. - С точки зрения почтового сервера - что сервис отправляющий почту будет творить всякую ересь вроде попытки "канонизировать" адрес только по одному сервису известному принципу.
Я не говорю что такого не существует или не должно существовать, но я ни разу не видел сервиса который мы давал имя пользователя на основе email. Это всегда заполняемое вручную поле. И если я ввёл адрес с суффиксом - это значит я хочу получать корреспонденцию от сервиса именно на имя с суффиксом.
Эта боль - неотъемлемый атрибут всех спецификаций с поведением.
Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith".
Мой коммент скорее про то, что у email нет канонического вида. У каждого сервера свои правила - тот же гугл - наверное единственный, кто точку в адресе игнорирует. А по поводу нормализации для ДБ - я, как пользаватель, ожидаю что user+test1@gmail.com и user+test2@gmail.comкак раз два разных адреса с точки зрения сервиса. Ну и как бы email-адреса авторизации скрывать принято. А если сервис боится, что пользователь зарегистрирует два аккаунта, то ему придётся с этим смериться. Пользователь может создать второй ящик.
Правильное решение: перед сохранением в базу данных email нужно нормализовать — привести к каноническому виду.
Неправильное. RFC (не вспомню какой, правда) запрещает преобразование email адреса где-либо, кроме сервера-владельца. Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
Не с 2003, там оригинально тоже "Белоруссия" была. В одной из редакций поменяли.
Как-то стало интересно, откуда же этот бессмысленный срач пошёл:
У нас в России название закрепили как "Беларусь" или "Республика Беларусь" в 2011м:
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=157385;fld=134;dst=100006;rnd=0.4737048347014934#SBz4ZtUGCsK3H2Wv
Хах. Похоже это общее. Если вы проходите медкомиссию для работы - вам там везде годен и поставят - "хотите результат - приходите по направлению или платно"
Из "легитимных" - пакеты для взлома, которые потом продаются гос-органам заинтересованных стран.
А уже имеет. Из Япония расследует на тему нарушения антимонопольного законодательства.
В точности. Причём предположительно потому, что их закидала письмами группа активистов (собственно потому народ их сейчас и спамят)
Ок, статья написана без понимания сути проблемы
Основные аргументы:
Это попытка попытка вставить ногу в дверь (успешная)
Уже на данный момент забаненны несколько инди-хорроров
Бан не на NSFW контент, а на тематики. То есть вы даже не можете упомянуть какую-то тему в вашей игре, будь то это шутка или часть сюжета
Точные критерии не опубликованы, никто не знает пройдёт ли их игра "проверку" или нет.
Вообще в видео автор говорит, что кейсов со сгаллюцинированными бумагами настолько много, что он просто перестал о них делать видео (у него на канале как минимум 3 таких). Это конкретный кейс - самый выдающийся что он видел.
Насколько я понял, адвокаты сами сознаются, так как это несёт меньше проблем чем "я целенаправленно соврал".
Но вообще там типичные признаки: сгалюцинированные кейсы которых никогда не было и несуществующие
Вот как пример:
https://www.youtube.com/watch?v=6RBQrcp0Lrg
Это случайно не одна и та же "юридическая фирма"?
https://habr.com/ru/news/917128/
То есть в случае для входа используется именно пара email/пароль?
Логика говорит, что наверное стоит спрашивать email как он был введён пользователем изначально. Пользователь знал, что он делал. Наверное.
Кроме, может быть, таки регистра, потому что многие считают и ожидают что email регистронезависим. А если нужно отправить email - использовать адрес в точности как его ввёл пользователь. Если вы при регистрации отправляли письмо и пользователь подтвердил получение - то вы уже знаете, что письмо дойдёт.
Захожу на Google (по привычке)
Ввожу запрос
Вижу бред в ИИ сводке и бред в первых результатах
Ухожу на Duckduckgo
Но да, я увидел ИИ-сводку и не нажал ни одной ссылки
Аналогично. Я не говорю что вы должны делать case sensitive на почтовом сервере. В rfc написано сервер может делать с ними что ему вздумается, пока он следует корректному синтаксису адресов. Хоть всю почту в один ящик скинуть.
Вопрос именно в том, как сторонние сервисы воспринимают адрес получателя. Для максимальной совместимости "нормализовать" (к чему?) и менять регистр нельзя.
"Не приветствуется" и "никогда не случится" - это разные вещи.
Лично я исхожу из принципа, что нужно следовать пессимистичному сценарию:
- С точки зрения сервиса отправляющего почту - что адреса должны быть именно в той форме, в которой адрес дал ему пользователь, иначе почтовый сервис не доставит письмо.
- С точки зрения почтового сервера - что сервис отправляющий почту будет творить всякую ересь вроде попытки "канонизировать" адрес только по одному сервису известному принципу.
Нельзя lowercase. email case sensitive в общем случае.
Я не говорю что такого не существует или не должно существовать, но я ни разу не видел сервиса который мы давал имя пользователя на основе email. Это всегда заполняемое вручную поле. И если я ввёл адрес с суффиксом - это значит я хочу получать корреспонденцию от сервиса именно на имя с суффиксом.
Сохраните email как его ввёл пользователь и не пытайтесь его обработать:
https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.11
Не надо. И таки да, по RFC это два разных email:
https://datatracker.ietf.org/doc/html/rfc5321#section-2.4
А зачем их вообще проверять? Я, как пользователь, ожидаю, что сервис их будет обрабатывать именно как два разных ящика.
Мой коммент скорее про то, что у email нет канонического вида. У каждого сервера свои правила - тот же гугл - наверное единственный, кто точку в адресе игнорирует.
А по поводу нормализации для ДБ - я, как пользаватель, ожидаю что
user+test1@gmail.comиuser+test2@gmail.comкак раз два разных адреса с точки зрения сервиса. Ну и как бы email-адреса авторизации скрывать принято.А если сервис боится, что пользователь зарегистрирует два аккаунта, то ему придётся с этим смериться. Пользователь может создать второй ящик.
Неправильное. RFC (не вспомню какой, правда) запрещает преобразование email адреса где-либо, кроме сервера-владельца. Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
Просто пошлите письмо