У VK проблема в том, что они меняли домен для фоток как минимум четыре раза (cs*.userapi.com → cs*.vk.me → pp.vk.me → pp.userapi.com), и даже несмотря на то, что фотки живые — старые ссылки нередко битые. А о том, что можно поменять домен на правильный, нужно ещё откуда-то знать
В том, что слепая замена naive datetime на aware datetime скорее всего сломает программы ещё сильнее (и, что самое страшное, может сломать незаметно, а тут хотя бы сразу с очевидной ошибкой грохнется)
Ну, когда понадобится «исчезнуть» — выпустят новый edition, в котором изменят поведение строковых литералов и подсунут в prelude новую реализацию String, и в целом ничего страшного не произойдёт (хотя экосистеме понадобится какое-то время для переката, но нам не впервой — вон призрак UCS-2 нас уже лет тридцать преследует)
Те же Хабр и MediaWiki не используют List-ID, но ладно — есть ли внятное описание, как реагируют на наличие List-ID почтовые сервисы, хотя бы тот же Gmail? Учитывается ли он в алгоритме работы кнопки «Отписаться» и влияет ли на последующую вероятность попадания в спам? На всякий случай уточню, что меня как автора рассылок интересует не сферический RFC в вакууме, а реальное поведение реальных почтовых сервисов
Про идентификацию разных рассылок в RFC 2369 я тоже ничего не заметил. Видимо, подразумевается, что рассылка идентифицируется по адресу отправителя — это нормально для mailing lists (для которых эти RFC, собственно, и написаны), но вот на современных сайтах такое встречается, мягко говоря, нечасто
Для современных сайтов имеет значение разделение в первую очередь по сущностям, на которые выполняется подписка — у того же Хабра это, например, посты, а на MediaWiki это, например, статьи. Наверное, они могли бы использовать адреса вида «noreply+new-comment-in-post-766016@habr.com» или «wiki+new-edit-in-FIVB-Volleyball-Womens-Intercontinental-Olympic-Qualification-Tournaments@wikimedia.org» для каждой из тысяч-миллионов сущностей — но что-то мне подсказывает, что от таких адресов пользователи взвоют ещё сильнее, чем от отсутствия нативной кнопки «Отписаться»
Тот же Хабр шлёт все уведомления с одного адреса. Гитхаб, например, тоже с одного. Ещё из того, что есть в моей почте: Steam — с одного, хостинги — с одного, MediaWiki — с одного, Crowdin — с одного. Наверное, если взять почти любой сайт — он будет слать всё с одного адреса.
И это написано в блоке «other methods» после блока про List-Unsubscribe. Должен ли я это интепретировать как то, что сам гугл рекомендует избегать использования List-Unsubscribe?
Не увидел там ничего про ситуацию с сотней рассылок. Зато вижу подтверждение своих страшилок:
he URI in the List-Unsubscribe header MUST contain enough information to identify the mail recipient and the list from which the recipient is to be removed, so that the unsubscription process can complete automatically.
Что ещё раз говорит о том, что предлагаемую вами страницу сделать технически невозможно и что использование List-Unsubscribe несёт вред.
Что такое «the list»? Какой конкретно «the list», если их сотня?
Или ещё более страшный случай — пользователь отписался, а потом подписался снова. Ощущается как гарантированный способ улететь в спам... По вот таким вот причинам я на данный момент принципиально игнорирую List-Unsubscribe (хотя был бы рад добавить, если бы имел внятное представление, как он должен работать)
Когда-то давно тут на Хабре видел страшилки, что почтовый сервис (как минимум mail.ru) переходит по ссылке сам в фоне, и никакой страницы в принципе быть не может
https://github.com/AntiZapret/antizapret
Это лишь одни из вариантов ссылок (причём относительно новые), за годы существования VK их накопилось гораздо больше, в том числе битых
У VK проблема в том, что они меняли домен для фоток как минимум четыре раза (cs*.userapi.com → cs*.vk.me → pp.vk.me → pp.userapi.com), и даже несмотря на то, что фотки живые — старые ссылки нередко битые. А о том, что можно поменять домен на правильный, нужно ещё откуда-то знать
В том, что слепая замена naive datetime на aware datetime скорее всего сломает программы ещё сильнее (и, что самое страшное, может сломать незаметно, а тут хотя бы сразу с очевидной ошибкой грохнется)
Вполне логично именно покупать, потому что, как я уже упоминал ранее,
Разбирать всю эту чушь мне лень, но особенно резануло глаз вот это:
Можно какой-нибудь пример «этого», что в systemd поменялось с поломкой обратной совместимости в течение последних десяти лет?
dconf используется по сей день
Вчера в чатике Aspia весь день читал сообщения о том, что этот самый Aspia не работает
Что именно глючит? Лично меня по состоянию на сейчас трекер уже устраивает
Все говорят, лол. Или вы родились и выросли не в России, а в какой-то совсем другой культуре?
Ну, когда понадобится «исчезнуть» — выпустят новый edition, в котором изменят поведение строковых литералов и подсунут в prelude новую реализацию String, и в целом ничего страшного не произойдёт (хотя экосистеме понадобится какое-то время для переката, но нам не впервой — вон призрак UCS-2 нас уже лет тридцать преследует)
Зато
my_string1[0..1]уже скомпилируется. Безопасность тут ни при чём, это всего лишь следствие использования кодировки UTF-8Те же Хабр и MediaWiki не используют List-ID, но ладно — есть ли внятное описание, как реагируют на наличие List-ID почтовые сервисы, хотя бы тот же Gmail? Учитывается ли он в алгоритме работы кнопки «Отписаться» и влияет ли на последующую вероятность попадания в спам? На всякий случай уточню, что меня как автора рассылок интересует не сферический RFC в вакууме, а реальное поведение реальных почтовых сервисов
Про идентификацию разных рассылок в RFC 2369 я тоже ничего не заметил. Видимо, подразумевается, что рассылка идентифицируется по адресу отправителя — это нормально для mailing lists (для которых эти RFC, собственно, и написаны), но вот на современных сайтах такое встречается, мягко говоря, нечасто
Для современных сайтов имеет значение разделение в первую очередь по сущностям, на которые выполняется подписка — у того же Хабра это, например, посты, а на MediaWiki это, например, статьи. Наверное, они могли бы использовать адреса вида «noreply+new-comment-in-post-766016@habr.com» или «wiki+new-edit-in-FIVB-Volleyball-Womens-Intercontinental-Olympic-Qualification-Tournaments@wikimedia.org» для каждой из тысяч-миллионов сущностей — но что-то мне подсказывает, что от таких адресов пользователи взвоют ещё сильнее, чем от отсутствия нативной кнопки «Отписаться»
Тот же Хабр шлёт все уведомления с одного адреса. Гитхаб, например, тоже с одного. Ещё из того, что есть в моей почте: Steam — с одного, хостинги — с одного, MediaWiki — с одного, Crowdin — с одного. Наверное, если взять почти любой сайт — он будет слать всё с одного адреса.
Все делают рассылки неправильно?
И это написано в блоке «other methods» после блока про List-Unsubscribe. Должен ли я это интепретировать как то, что сам гугл рекомендует избегать использования List-Unsubscribe?
Не увидел там ничего про ситуацию с сотней рассылок. Зато вижу подтверждение своих страшилок:
Что ещё раз говорит о том, что предлагаемую вами страницу сделать технически невозможно и что использование List-Unsubscribe несёт вред.
Что такое «the list»? Какой конкретно «the list», если их сотня?
Или ещё более страшный случай — пользователь отписался, а потом подписался снова. Ощущается как гарантированный способ улететь в спам... По вот таким вот причинам я на данный момент принципиально игнорирую List-Unsubscribe (хотя был бы рад добавить, если бы имел внятное представление, как он должен работать)
Когда-то давно тут на Хабре видел страшилки, что почтовый сервис (как минимум mail.ru) переходит по ссылке сам в фоне, и никакой страницы в принципе быть не может