А это уже культура разработки, которой может не быть, человеческий фактор, не проставил, или проставил не то, не та версия инкрементнулась.
Это решаемо. Например, утилита https://git-cliff.org/ позволяет вручную корректировать такие "плохие" описания коммитов. В ней это сделано для генерации ChangeLog из коммитов, но она и SemVer отлично вычисляет (и её удобно использовать для определения версии на CI).
В этом плане календарное версионирование решает проблему.
И CalVer и EvoVer - это просто альтернативные/красивые способы записи BuildID. Никакой проблемы помимо увеличения номера версии они не решают.
Вполне свободный: обновиться сейчас или позднее, отказаться от обновления, перейти на другую библиотеку…
После выпуска новой мажорной версии библиотеки предыдущая ветвь развиваться не будет.
Зависит от библиотеки, некоторые продолжают поддерживать багфиксами предыдущий мажорный релиз ещё какое-то время. Особенно если по объективным причинам многие пользователи не хотят обновляться на последний мажор.
В такой ситуации разработчик вынужден переходить, даже если нет в этом необходимости, либо копить техдолг.
Отказ от перехода на новый мажор - это не всегда техдолг.
Но в общем и целом - всё это незначительные мелочи. Важно то, что SemVer даёт ключевую информацию необходимую для принятия таких решений, а другие схемы - не дают.
Не совсем так. SemVer оперирует понятием "совместимое изменение". И это ключевой фактор: чтобы определить является ли изменение совместимым нужно иметь возможность как-то эту совместимость оценивать. Если продукт это библиотека, то способ оценить совместимость очевиден: по API. Но если продукт это CLI/GUI приложение, то понятие совместимость становится крайне туманным. Например для CLI можно считать совместимостью формат аргументов/флагов, но является ли совместимым изменением незначительное отличие в формате выводимых данных - уже не так очевидно.
Ещё один ключевой момент SemVer, который упустил автор статьи - задача SemVer коммуницировать ключевую информацию чтобы пользователь мог определиться нужно ли ему (полезность) и когда лучше (сложность) обновляться. Это полезно только в ситуации, когда время обновления выбирается пользователем. Что, очевидно, не так для микросервисов и для веб-фронта - и то и другое обновляется централизованно компанией, а не вразнобой пользователями.
При отсутствии любого из этих двух факторов пропадает смысл использовать SemVer.
Это совсем не так просто. Потому что дальше понадобится обмен данными между разными юзерами (те же скачанные в браузере файлы). А потом и между разными приложениями (ссылку из телеги открыть в браузере, ссылку из браузера в zoom, etc.). Доступ к буферу обмена. Обеспечить визуальное отличие этих двух браузеров, чтобы понимать в каком сейчас работаешь. В общем, я соглашусь с тем, что в Linux есть все или практически все необходимые механизмы, но активировать их достаточно сложно и делать это нужно ручками - что для среднего десктопа равно отсутствию этой фичи.
Сам я этим пользуюсь, в т.ч. и для ограничения доступа AI-агента исключительно кодом рабочих проектов, но на сегодня это скорее исключение, чем норма. И, кстати, рекомендую для таких целей присмотреться к firejail - эта утилита сильно упрощает изоляцию разных приложений, избавляя от необходимости заводить кучу отдельных юзеров, и многое даже работает из коробки.
В целом верно, за исключением пассажа про "информационное сжатие кода". AI-агент выполняющийся на устройстве пользователя защищён ровно так же, как и все остальные локальные приложения. Ключевое отличие - крайне сложно контролировать какие именно данные пользователя он считает и отправит в интернет. Что с отправленными данными будет происходить дальше - ровно так же невозможно узнать, как и в отношении любых других данных отправленных в интернет любыми другими локальными приложениями.
По большому счёту, все десктопные ОС (исключая разве что малоизвестные вроде Qubes OS) совершенно не защищены от атак типа "любое локальное приложение может считать и отправить в интернет любые данные текущего пользователя". Есть попытки защитить отдельные приложения (полагаю, Signal, KeePass, etc.) на уровне ОС от, например, автоматических скриншотов, но это реально капля в море.
Просто если в отношении других локальных приложений доверие держится на уровне банальной надежды, что приложение не будет делать того, чего от него не ожидает пользователь (например читать не относящиеся к этому приложению файлы и отправлять их в интернет), то в отношении ИИ-агентов такой надежды изначально нет, потому что от них как раз ожидается что они сами найдут любую полезную для них информацию и обработают как посчитают нужным, без особых/явных ограничений.
А если уровень сервиса локального решения не будет отличаться от иностранного - как будто все только выиграют и пострадавших не будет.
К сожалению, уровень сервиса решения, которое продвигается не рыночными методами а давлением государства и зарабатывает не на пользователях а из бюджета - всегда будет на порядок хуже "иностранных" (а точнее честно выигравших на рынке, вне зависимости от страны происхождения). Просто потому, что владельцы этого локального решения никак не зависят от удовлетворённости пользователей.
Для начала - не нужно поддерживать сомнительные инициативы. Даже частично или косвенно (что вполне себе прозвучало в Вашем предыдущем комментарии).
Нужно ли вообще защищать детей от информации - вопрос на который нет однозначного ответа (и нет никаких адекватных научных исследований доказывающих явную пользу или вред такой защиты). В таких ситуациях самое адекватное решение - оставить этот вопрос на ответственности родителей.
Распространение ограничения информации с детей на вообще всё население без возможности отказаться - ну очевидно же, что тут дело не в том, кто достаточно взрослый и ответственный, а кто ещё ребёнок.
Власть могла честно заявить населению "вы - быдло, которое должно молча делать что сказано и не пытаться думать самостоятельно и ставить наши распоряжения под сомнение, поэтому мы ограничиваем вам доступ к любой информации не соответствующей текущей политике". Но они вместо этого сказали "мы это делаем для защиты ваших детей от педофилов и суицидов". Зачем нужно это наглое враньё? А вот как раз затем, чтобы такие как Вы начали сомневаться и частично соглашаться с тем, что что-то делать надо, ведь бедные дети совершенно беззащитны, может не совсем таким образом, но ведь что-то надо же делать… и на этом месте любой протест тупо тонет в сомнениях и колебаниях.
Роль государства - выделить человека, который сможет выработать решение на некоторый вопрос, которому должны будут следовать остальные граждане. Просто потому, что В МАССЕ СВОЕЙ граждане не разбираются практически ни в чём.
С таким подходом государство будет регулировать вообще всё, что ему захочется - хотя это совершенно тупое оправдание для вмешательства. Государство - это не абстракция заботящаяся о населении, а вполне конкретные люди, действующие в первую очередь в своих личных интересах. Более того, полно очевидных примеров, когда "государство" назначает вырабатывать решения людей, у которых даже нет профильного образования и которые разбираются в заданном вопросе не больше, чем все остальные - просто потому, что государству не нужен качественный, правильный и работающий на пользу населению ответ на этот вопрос, ему нужен вполне конкретный ответ соответствующий текущей политике/интересам конкретной властной группировки. Не стоит верить всему, что Вам в школе рассказали. Да, где-то в идеальном мире может или даже должно быть так - но мы живём не в нём.
Вмешательство государства оправдано там, где ущерб для всего социума от невмешательства будет больше, чем ущерб от вмешательства. Хорошие примеры - наличие полиции и ПДД, потому что без них всё было бы намного хуже, даже с учётом того, насколько паршиво и избирательно они работают. Защита детей от информации в инете явно в эту категорию не попадает, не говоря уже о распространении этой "защиты" на взрослых.
Если считать всех взрослых несамостоятельными незрелыми идиотами нуждающимися в опёке, то возникает вопрос: а кто их опекает тогда? Такие же нуждающиеся в опёке "взрослые"? Зрелость мышления что, наступает в момент избрания в депутаты или получения должности чиновника? Простите, но Вам просто насрали в голову на школьной скамье, вот и всё.
Да, несколько раз заказчику "приходил аппетит во время еды", который трансформировался в допсоглашения с допТЗ.
Это уже не "чёткое ИЗНАЧАЛЬНОЕ представление" позволяющее спокойно работать по водопаду. Формально, под вариант с допсоглашениями попадёт любой проект на аутсорсе на условиях fixed price - их тьма и речь явно не о них, верно? Нет, я имел в виду как раз "чёткое ИЗНАЧАЛЬНОЕ представление" - когда заказчик ставит задачу, ждёт завершения водопада, и довольный принимает результат. Можно сказать, что я такое видел на мелких (размером в несколько дней) фрилансерских проектах, но такие микро-проекты мы тут вроде тоже не обсуждаем. А уже на мелких проектах размером хотя бы от 2-3 месяцев мне такое не встречалось.
Ключевое отличие software от hardware как раз в том и состоит, что граница между проектом и процессом размыта до неразличимости из-за мягкости производимого продукта. Можно считать условным проектом процесс разработки до получения минимально необходимого/полезного функционала и первых реальных пользователей, но с этого момента добавление любой новой фичи или значимого изменения можно воспринимать и как проект и как процесс - это мало на что будет влиять. Можно считать проектом каждый релиз коробочного продукта или новых версий мобильного приложения, но для бэкенда и веб-приложений обновляемых практически непрерывно грань опять же полностью размыта. По большому счёту проектом считают ситуацию, когда любой ценой необходимо уложиться в выделенные ресурсы (время/деньги). Что не мешает использовать аджайл, применяя его гибкость не для того, что внезапно добавлять только что придуманные фичи, а для того, чтобы выпиливать на ходу те, на которые не хватило ресурсов.
Одно другому не мешает - жёсткость с заказчиком можно и нужно проявлять в т.ч. при аджайле. Просто степень этой жёсткости будет ниже ("вот эту фичу мы если и будем делать, то в далёком будущем"), чем в водопаде ("на текущем этапе проекта никакие изменения невозможны в принципе"). По большому счёту аджайл прекрасно работает в стиле группы параллельных и последовательных небольших водопадов, позволяя соблюдать баланс и получать лучшее из обоих подходов.
Увеличилось, конечно. Чтобы писать достаточно портабельный код, который запустится в любом окружении, нужна более высокая квалификация, нежели чтобы написать код работающий в единственном окружении - контейнере. Причём одной квалификации мало, нужно ещё и больше времени на реализацию и тестирование. Т.е. это объективно заметно дороже для бизнеса. Контейнеры дают возможность и разработчикам меньше напрягаться, и бизнесу нанимать более дешёвых разработчиков и при этом получать результат быстрее. Качество результата ниже, но, как мы видим, для бизнеса это не критично и окупается другими плюсами. С точки зрения идеального мира - это может и не очень хорошо, но в реальном мире выбор большинства проектов был сделан в пользу контейнеров.
Что до AI - пока всё ещё период хайпа. Реальные плюсы/минусы станут видны со временем. Работать с AI можно разными способами, в т.ч. такими, при которых качество вообще не страдает, удовлетворённость разработчиков выше, продуктивность тоже (хоть и не настолько, как мечтали). Но вряд ли от этого инструмента откажутся полностью, скорее просто выработают правила по его использованию - разные для разных типов проектов с разными требованиями к качеству кода, разумеется. Если посадить писать проект джунов без контроля (а некоторые так делают) - они напишут примерно то же самое, что AI при вайб-кодинге, только намного медленнее и намного дороже чем AI. А если квалифицированный сениор будет адекватно ставить задачи и полноценно ревьювить код, то нет принципиальной разницы, кто этот код написал, джун или AI - сениор всё-равно продавит необходимые изменения для получения качественного результата. Но с AI качественный результат будет получен намного быстрее, что плюс. Правда, при этом не будет обучаться джун, что минус. В общем, поглядим, куда это всё придёт, сейчас пока ещё рано делать выводы про качество кода AI.
Зависит от задачи. Если задача - дать доступ модели к содержимому локальных документов, то да, RAG или агент+MCP. Но в статье задача "дообучить", и тут RAG не поможет.
У любого знания есть цена (как минимум - время на изучение, но далеко не только это) - и не каждое знание стоит свою цену лично для Вас.
А ещё "знание" бывает ложным, даже если этого вообще никто в текущий момент времени не знает. В истории полно примеров того, как не знающие что что-то "невозможно" умудрялись это что-то сделать/изобрести, в то время как опытные-знающие были на это не способны.
А бывает, когда знаний в какой-то момент становится слишком много, и это вызывает аналитический паралич мешая принятию любых решений.
…плюс много других ситуаций, где лишние знания - совсем не благо.
У меня на DO почтовые порты открыты. Серверу, правда, уже несколько лет, может они изменили правила для новых клиентов - а может после обращения в саппорт эти порты открывают (я уже не помню, обращался ли я или сразу было открыто).
А вот на AWS почтовые порты мне открыть уже несколько лет назад не удалось, даже после месяца активной переписки с несколькими саппортами.
Тема тестовых так и не раскрыта! Очевидно, сегодня просить такие тестовые смысла мало. Чем будем их заменять?
Это решаемо. Например, утилита https://git-cliff.org/ позволяет вручную корректировать такие "плохие" описания коммитов. В ней это сделано для генерации ChangeLog из коммитов, но она и SemVer отлично вычисляет (и её удобно использовать для определения версии на CI).
И CalVer и EvoVer - это просто альтернативные/красивые способы записи BuildID. Никакой проблемы помимо увеличения номера версии они не решают.
Вполне свободный: обновиться сейчас или позднее, отказаться от обновления, перейти на другую библиотеку…
Зависит от библиотеки, некоторые продолжают поддерживать багфиксами предыдущий мажорный релиз ещё какое-то время. Особенно если по объективным причинам многие пользователи не хотят обновляться на последний мажор.
Отказ от перехода на новый мажор - это не всегда техдолг.
Но в общем и целом - всё это незначительные мелочи. Важно то, что SemVer даёт ключевую информацию необходимую для принятия таких решений, а другие схемы - не дают.
Не совсем так. SemVer оперирует понятием "совместимое изменение". И это ключевой фактор: чтобы определить является ли изменение совместимым нужно иметь возможность как-то эту совместимость оценивать. Если продукт это библиотека, то способ оценить совместимость очевиден: по API. Но если продукт это CLI/GUI приложение, то понятие совместимость становится крайне туманным. Например для CLI можно считать совместимостью формат аргументов/флагов, но является ли совместимым изменением незначительное отличие в формате выводимых данных - уже не так очевидно.
Ещё один ключевой момент SemVer, который упустил автор статьи - задача SemVer коммуницировать ключевую информацию чтобы пользователь мог определиться нужно ли ему (полезность) и когда лучше (сложность) обновляться. Это полезно только в ситуации, когда время обновления выбирается пользователем. Что, очевидно, не так для микросервисов и для веб-фронта - и то и другое обновляется централизованно компанией, а не вразнобой пользователями.
При отсутствии любого из этих двух факторов пропадает смысл использовать SemVer.
SemVer прекрасно рассчитывается автоматически на базе префиксов коммитов (feat!:, feat:, fix:, etc.).
Это совсем не так просто. Потому что дальше понадобится обмен данными между разными юзерами (те же скачанные в браузере файлы). А потом и между разными приложениями (ссылку из телеги открыть в браузере, ссылку из браузера в zoom, etc.). Доступ к буферу обмена. Обеспечить визуальное отличие этих двух браузеров, чтобы понимать в каком сейчас работаешь. В общем, я соглашусь с тем, что в Linux есть все или практически все необходимые механизмы, но активировать их достаточно сложно и делать это нужно ручками - что для среднего десктопа равно отсутствию этой фичи.
Сам я этим пользуюсь, в т.ч. и для ограничения доступа AI-агента исключительно кодом рабочих проектов, но на сегодня это скорее исключение, чем норма. И, кстати, рекомендую для таких целей присмотреться к firejail - эта утилита сильно упрощает изоляцию разных приложений, избавляя от необходимости заводить кучу отдельных юзеров, и многое даже работает из коробки.
В целом верно, за исключением пассажа про "информационное сжатие кода". AI-агент выполняющийся на устройстве пользователя защищён ровно так же, как и все остальные локальные приложения. Ключевое отличие - крайне сложно контролировать какие именно данные пользователя он считает и отправит в интернет. Что с отправленными данными будет происходить дальше - ровно так же невозможно узнать, как и в отношении любых других данных отправленных в интернет любыми другими локальными приложениями.
По большому счёту, все десктопные ОС (исключая разве что малоизвестные вроде Qubes OS) совершенно не защищены от атак типа "любое локальное приложение может считать и отправить в интернет любые данные текущего пользователя". Есть попытки защитить отдельные приложения (полагаю, Signal, KeePass, etc.) на уровне ОС от, например, автоматических скриншотов, но это реально капля в море.
Просто если в отношении других локальных приложений доверие держится на уровне банальной надежды, что приложение не будет делать того, чего от него не ожидает пользователь (например читать не относящиеся к этому приложению файлы и отправлять их в интернет), то в отношении ИИ-агентов такой надежды изначально нет, потому что от них как раз ожидается что они сами найдут любую полезную для них информацию и обработают как посчитают нужным, без особых/явных ограничений.
К сожалению, уровень сервиса решения, которое продвигается не рыночными методами а давлением государства и зарабатывает не на пользователях а из бюджета - всегда будет на порядок хуже "иностранных" (а точнее честно выигравших на рынке, вне зависимости от страны происхождения). Просто потому, что владельцы этого локального решения никак не зависят от удовлетворённости пользователей.
Для начала - не нужно поддерживать сомнительные инициативы. Даже частично или косвенно (что вполне себе прозвучало в Вашем предыдущем комментарии).
Нужно ли вообще защищать детей от информации - вопрос на который нет однозначного ответа (и нет никаких адекватных научных исследований доказывающих явную пользу или вред такой защиты). В таких ситуациях самое адекватное решение - оставить этот вопрос на ответственности родителей.
Распространение ограничения информации с детей на вообще всё население без возможности отказаться - ну очевидно же, что тут дело не в том, кто достаточно взрослый и ответственный, а кто ещё ребёнок.
Власть могла честно заявить населению "вы - быдло, которое должно молча делать что сказано и не пытаться думать самостоятельно и ставить наши распоряжения под сомнение, поэтому мы ограничиваем вам доступ к любой информации не соответствующей текущей политике". Но они вместо этого сказали "мы это делаем для защиты ваших детей от педофилов и суицидов". Зачем нужно это наглое враньё? А вот как раз затем, чтобы такие как Вы начали сомневаться и частично соглашаться с тем, что что-то делать надо, ведь бедные дети совершенно беззащитны, может не совсем таким образом, но ведь что-то надо же делать… и на этом месте любой протест тупо тонет в сомнениях и колебаниях.
С таким подходом государство будет регулировать вообще всё, что ему захочется - хотя это совершенно тупое оправдание для вмешательства. Государство - это не абстракция заботящаяся о населении, а вполне конкретные люди, действующие в первую очередь в своих личных интересах. Более того, полно очевидных примеров, когда "государство" назначает вырабатывать решения людей, у которых даже нет профильного образования и которые разбираются в заданном вопросе не больше, чем все остальные - просто потому, что государству не нужен качественный, правильный и работающий на пользу населению ответ на этот вопрос, ему нужен вполне конкретный ответ соответствующий текущей политике/интересам конкретной властной группировки. Не стоит верить всему, что Вам в школе рассказали. Да, где-то в идеальном мире может или даже должно быть так - но мы живём не в нём.
Вмешательство государства оправдано там, где ущерб для всего социума от невмешательства будет больше, чем ущерб от вмешательства. Хорошие примеры - наличие полиции и ПДД, потому что без них всё было бы намного хуже, даже с учётом того, насколько паршиво и избирательно они работают. Защита детей от информации в инете явно в эту категорию не попадает, не говоря уже о распространении этой "защиты" на взрослых.
Если считать всех взрослых несамостоятельными незрелыми идиотами нуждающимися в опёке, то возникает вопрос: а кто их опекает тогда? Такие же нуждающиеся в опёке "взрослые"? Зрелость мышления что, наступает в момент избрания в депутаты или получения должности чиновника? Простите, но Вам просто насрали в голову на школьной скамье, вот и всё.
Это уже не "чёткое ИЗНАЧАЛЬНОЕ представление" позволяющее спокойно работать по водопаду. Формально, под вариант с допсоглашениями попадёт любой проект на аутсорсе на условиях fixed price - их тьма и речь явно не о них, верно? Нет, я имел в виду как раз "чёткое ИЗНАЧАЛЬНОЕ представление" - когда заказчик ставит задачу, ждёт завершения водопада, и довольный принимает результат. Можно сказать, что я такое видел на мелких (размером в несколько дней) фрилансерских проектах, но такие микро-проекты мы тут вроде тоже не обсуждаем. А уже на мелких проектах размером хотя бы от 2-3 месяцев мне такое не встречалось.
Я такого за последние 36 лет работы с кодом не видел ни разу, а Вы?
Ключевое отличие software от hardware как раз в том и состоит, что граница между проектом и процессом размыта до неразличимости из-за мягкости производимого продукта. Можно считать условным проектом процесс разработки до получения минимально необходимого/полезного функционала и первых реальных пользователей, но с этого момента добавление любой новой фичи или значимого изменения можно воспринимать и как проект и как процесс - это мало на что будет влиять. Можно считать проектом каждый релиз коробочного продукта или новых версий мобильного приложения, но для бэкенда и веб-приложений обновляемых практически непрерывно грань опять же полностью размыта. По большому счёту проектом считают ситуацию, когда любой ценой необходимо уложиться в выделенные ресурсы (время/деньги). Что не мешает использовать аджайл, применяя его гибкость не для того, что внезапно добавлять только что придуманные фичи, а для того, чтобы выпиливать на ходу те, на которые не хватило ресурсов.
Одно другому не мешает - жёсткость с заказчиком можно и нужно проявлять в т.ч. при аджайле. Просто степень этой жёсткости будет ниже ("вот эту фичу мы если и будем делать, то в далёком будущем"), чем в водопаде ("на текущем этапе проекта никакие изменения невозможны в принципе"). По большому счёту аджайл прекрасно работает в стиле группы параллельных и последовательных небольших водопадов, позволяя соблюдать баланс и получать лучшее из обоих подходов.
Увеличилось, конечно. Чтобы писать достаточно портабельный код, который запустится в любом окружении, нужна более высокая квалификация, нежели чтобы написать код работающий в единственном окружении - контейнере. Причём одной квалификации мало, нужно ещё и больше времени на реализацию и тестирование. Т.е. это объективно заметно дороже для бизнеса. Контейнеры дают возможность и разработчикам меньше напрягаться, и бизнесу нанимать более дешёвых разработчиков и при этом получать результат быстрее. Качество результата ниже, но, как мы видим, для бизнеса это не критично и окупается другими плюсами. С точки зрения идеального мира - это может и не очень хорошо, но в реальном мире выбор большинства проектов был сделан в пользу контейнеров.
Что до AI - пока всё ещё период хайпа. Реальные плюсы/минусы станут видны со временем. Работать с AI можно разными способами, в т.ч. такими, при которых качество вообще не страдает, удовлетворённость разработчиков выше, продуктивность тоже (хоть и не настолько, как мечтали). Но вряд ли от этого инструмента откажутся полностью, скорее просто выработают правила по его использованию - разные для разных типов проектов с разными требованиями к качеству кода, разумеется. Если посадить писать проект джунов без контроля (а некоторые так делают) - они напишут примерно то же самое, что AI при вайб-кодинге, только намного медленнее и намного дороже чем AI. А если квалифицированный сениор будет адекватно ставить задачи и полноценно ревьювить код, то нет принципиальной разницы, кто этот код написал, джун или AI - сениор всё-равно продавит необходимые изменения для получения качественного результата. Но с AI качественный результат будет получен намного быстрее, что плюс. Правда, при этом не будет обучаться джун, что минус. В общем, поглядим, куда это всё придёт, сейчас пока ещё рано делать выводы про качество кода AI.
Зависит от задачи. Если задача - дать доступ модели к содержимому локальных документов, то да, RAG или агент+MCP. Но в статье задача "дообучить", и тут RAG не поможет.
Не любое знание есть благо.
У любого знания есть цена (как минимум - время на изучение, но далеко не только это) - и не каждое знание стоит свою цену лично для Вас.
А ещё "знание" бывает ложным, даже если этого вообще никто в текущий момент времени не знает. В истории полно примеров того, как не знающие что что-то "невозможно" умудрялись это что-то сделать/изобрести, в то время как опытные-знающие были на это не способны.
А бывает, когда знаний в какой-то момент становится слишком много, и это вызывает аналитический паралич мешая принятию любых решений.
…плюс много других ситуаций, где лишние знания - совсем не благо.
Не почту как таковую, а её федеративность - всех загоняют на крупных провайдеров вроде gmail. И это полный беспредел!
У меня на DO почтовые порты открыты. Серверу, правда, уже несколько лет, может они изменили правила для новых клиентов - а может после обращения в саппорт эти порты открывают (я уже не помню, обращался ли я или сразу было открыто).
А вот на AWS почтовые порты мне открыть уже несколько лет назад не удалось, даже после месяца активной переписки с несколькими саппортами.
Eсть способ "решить" эту проблему: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme