Кажется, форварлинг форварлингу рознь.
На практике postmaster MailRu настоятельно советует, например, включать для домена DMARC в p=reject вместо p=none, но в то же время множество случаев, когда большие ESP пересылают письма между своими внутренними хостами без поддержки ARC и все — DKIM сломан, DMARC не проходит, при p=reject письмо отвергается.
Как быть с таким?
Я дико извиняюсь, последний раз с апачем имел дело в 2010, но во-первых, CharsetSourceEnc требует включенного mod_charset, а во-вторых, внутри используется iconv на каждый запрос — не слишком ли это дорого для шаред хостингов?
Справедливо, но нет. Или нужна открытая документация, а ещё лучше — способ описать "важное" письмо самим письмом: метадата в верстке или ещё что-то. В противном случае сервис не может никак заранее предвидеть будет ли его уведомление в текущем дизайне действительно распознано как "важное", или свалится вслед за остальным маркетингом. Или заводить десятки ящиков сотрудникам и тренироваться на них, что тоже даёт такие себе гарантии.
Забороть спам — намерение, безусловно, благое. Но мы все ведь знаем, куда такие намерения могут привести.
Вот просто например.
Есть сферический сервис в вакууме — service.tld. Этот сервис шлёт с info@service-mail.tld письма с маркетингом ("черная пятница", етц) и письма "ваша подписка продлена".
Юзер получает за год 3-5 писем с маркетингом, "отписывается" от рассылки, и в итоге уведомления о продлении подписки или, что хуже, невозможности продления (карта кончилась) не увидит. Как быть?
Так тоже самое происходит с доменами, например. И, если мне память не изменяет, были в прошлом истории с регистрацией освободившихся доменов и чтением писем, на них приходящих "по старой памяти".
А не означает ли это, что скомпрометированный компьютер в корпоративной сети потенциально будет иметь доступ к локальному веб-серверу на других компьютерах сети? Есть ли в локальном веб-сервере проверки на то, откуда пришел запрос?
Или ответственность за это перекладывается на админов?
Это все, конечно, замечательно, но держать в продукиве апач только ради SSO как-то не охота. А nginx, когда я последний раз смотрел, с керберосом особо не дружил.
Приходится пользователям немного страдать все еще…
Не очень понятно о чем конкретно статья.
Автомобиль лучше или хуже велосипеда? А вертолет автомобиля?
Облако — суть еще один способ решения задачи, остается задача выбора способа решения и эту задачу каждый решает сам.
Развернуть сегодня 1С внутри офиса на 10-15 пользователей стоит на круг (железки и софт) порядка полумиллиона рублей в клиент-сервере и сильно меньше (можно уложиться и в сто тысяч) при толстых клиентах и файловых базах на шарах. Или за 50-150 тысяч в год облака.
А вот развернуть у себя, например, сервис для большого количества заказчиков (sla, резервирование и вот это вот все) — уже миллион и выше. Или опять 50-150 в год облака.
Но как часто в SMB нужно обновлять серверные парки 1С? А серверные парки растущих клиентских сервисов?
Вокруг облака много пиара, просто потому, что про другой способ все и так знают, а единовременные затраты оборотных средств на облако всегда ниже, на это и упор.
Что значит «не в их компетенции»? Я не холивара для, а интереса из.
Ведь если вы продаете услуги отечественным юрлицам — у вас либо есть ооо/ип/проч., зарегистрированный в РФ (и как тогда быть с предписанием?), либо бухгалтерия клиента должна уметь и смело платить иностранным контрагентам (что тоже не всегда и везде просто).
Или платит лично директор с карточки?
Это так.
Но вот банальный и попсовый кейс: кто-то хакнул чей-то сайт и вместе с контентом прилетает обфусцированный «злой» код на JS. Это противно, но понимаемо — код можно развернуть и понять что и как.
В случае же бинарных данных — что делать? Всем срочно учить asm, дизассемблировать бинарники и ковыряться? По мне — для предприятий проще будет забанить на уровне корпоративной прокси получение таких данных, а за корпоративными проксиками так или иначе находится приличный процент веб-аудитории.
Как по мне, так Ruby — просто еще один язык. Нет в нем вещей (особенно под веб), которые нельзя сделать на другом языке, равно как и наоборот.
Что меня сильно напрягает пока что в нем — символы. Чувакам захотелось создавать хэши как {a: «b»}, и чтобы быстрее, чем {«a» => «b»} и чуваки запилили новый тип данных по сути. Это какая-то страшная глупость, по-моему. Все эти .to_sym, .to_s и прочие .intern нехило рвут шаблон по первости.
Претензии к windows тоже не очень понятно зачем — в окошках удобно жить только с с# и прочим дотнетом, для всего остального, переносимого из unix, надо будет что-то делать руками. А зачем? Имхо, пытаться строить системы на ОС только потому, что в команде есть фанаты данной ОС и им «неудобно» — еще одна страшная глупость, прямо как символы в Ruby.
Все равно может не спасти.
Я подозреваю, что полетная документация — штука не публичная (если вообще не закрытая и не выдаваемая «под роспись») и для ее распространения на планшеты используют какую-либо MDM-систему (щас они почти все умеют разливать по устройствам защищенный контент и им управлять).
В случае, если система не сможет залить документы (например банальное: забыли перевыпустить сертификат) — она не зальет их на все устройства, которые обслуживает.
Справедливости нет.
Однако пока в одной чксти света результатом работы людей является новый поезд, в другой части света результатом работы людей является акт сдачи/приемки в эксплуатацию. Разницу чувствуете? :)
Кажется, форварлинг форварлингу рознь.
На практике postmaster MailRu настоятельно советует, например, включать для домена DMARC в p=reject вместо p=none, но в то же время множество случаев, когда большие ESP пересылают письма между своими внутренними хостами без поддержки ARC и все — DKIM сломан, DMARC не проходит, при p=reject письмо отвергается.
Как быть с таким?
Нашел для себя не менее (в чем-то и более) декларативную штуку — docopt: https://github.com/docopt/docopt
Я дико извиняюсь, последний раз с апачем имел дело в 2010, но во-первых, CharsetSourceEnc требует включенного mod_charset, а во-вторых, внутри используется iconv на каждый запрос — не слишком ли это дорого для шаред хостингов?
Справедливо, но нет. Или нужна открытая документация, а ещё лучше — способ описать "важное" письмо самим письмом: метадата в верстке или ещё что-то. В противном случае сервис не может никак заранее предвидеть будет ли его уведомление в текущем дизайне действительно распознано как "важное", или свалится вслед за остальным маркетингом. Или заводить десятки ящиков сотрудникам и тренироваться на них, что тоже даёт такие себе гарантии.
Забороть спам — намерение, безусловно, благое. Но мы все ведь знаем, куда такие намерения могут привести.
Вот просто например.
Есть сферический сервис в вакууме — service.tld. Этот сервис шлёт с info@service-mail.tld письма с маркетингом ("черная пятница", етц) и письма "ваша подписка продлена".
Юзер получает за год 3-5 писем с маркетингом, "отписывается" от рассылки, и в итоге уведомления о продлении подписки или, что хуже, невозможности продления (карта кончилась) не увидит. Как быть?
Так тоже самое происходит с доменами, например. И, если мне память не изменяет, были в прошлом истории с регистрацией освободившихся доменов и чтением писем, на них приходящих "по старой памяти".
Или ответственность за это перекладывается на админов?
Приходится пользователям немного страдать все еще…
Автомобиль лучше или хуже велосипеда? А вертолет автомобиля?
Облако — суть еще один способ решения задачи, остается задача выбора способа решения и эту задачу каждый решает сам.
Развернуть сегодня 1С внутри офиса на 10-15 пользователей стоит на круг (железки и софт) порядка полумиллиона рублей в клиент-сервере и сильно меньше (можно уложиться и в сто тысяч) при толстых клиентах и файловых базах на шарах. Или за 50-150 тысяч в год облака.
А вот развернуть у себя, например, сервис для большого количества заказчиков (sla, резервирование и вот это вот все) — уже миллион и выше. Или опять 50-150 в год облака.
Но как часто в SMB нужно обновлять серверные парки 1С? А серверные парки растущих клиентских сервисов?
Вокруг облака много пиара, просто потому, что про другой способ все и так знают, а единовременные затраты оборотных средств на облако всегда ниже, на это и упор.
Ведь если вы продаете услуги отечественным юрлицам — у вас либо есть ооо/ип/проч., зарегистрированный в РФ (и как тогда быть с предписанием?), либо бухгалтерия клиента должна уметь и смело платить иностранным контрагентам (что тоже не всегда и везде просто).
Или платит лично директор с карточки?
Но вот банальный и попсовый кейс: кто-то хакнул чей-то сайт и вместе с контентом прилетает обфусцированный «злой» код на JS. Это противно, но понимаемо — код можно развернуть и понять что и как.
В случае же бинарных данных — что делать? Всем срочно учить asm, дизассемблировать бинарники и ковыряться? По мне — для предприятий проще будет забанить на уровне корпоративной прокси получение таких данных, а за корпоративными проксиками так или иначе находится приличный процент веб-аудитории.
И каждый сайт теперь — черный ящик?
А потом выкинем все нафиг и будем использовать JSON. Ну ок.
Что меня сильно напрягает пока что в нем — символы. Чувакам захотелось создавать хэши как {a: «b»}, и чтобы быстрее, чем {«a» => «b»} и чуваки запилили новый тип данных по сути. Это какая-то страшная глупость, по-моему. Все эти .to_sym, .to_s и прочие .intern нехило рвут шаблон по первости.
Претензии к windows тоже не очень понятно зачем — в окошках удобно жить только с с# и прочим дотнетом, для всего остального, переносимого из unix, надо будет что-то делать руками. А зачем? Имхо, пытаться строить системы на ОС только потому, что в команде есть фанаты данной ОС и им «неудобно» — еще одна страшная глупость, прямо как символы в Ruby.
Я подозреваю, что полетная документация — штука не публичная (если вообще не закрытая и не выдаваемая «под роспись») и для ее распространения на планшеты используют какую-либо MDM-систему (щас они почти все умеют разливать по устройствам защищенный контент и им управлять).
В случае, если система не сможет залить документы (например банальное: забыли перевыпустить сертификат) — она не зальет их на все устройства, которые обслуживает.
Однако пока в одной чксти света результатом работы людей является новый поезд, в другой части света результатом работы людей является акт сдачи/приемки в эксплуатацию. Разницу чувствуете? :)