Владимир Дубровин

Firefox не умеет использовать cid: и data: для background, поэтому его можно сделать только внешней картинкой. В остальном проблем с фоновыми картинками не должно быть.

Ссылки напрямую ведут на конечные страницы или через редиректор Mailchimp'а? Если напрямую, то кликов в статистике мейлчимпа вы, разумеется, не увидите.

1. Отключите все расширения в хроме. Лучше вообще удалить (или временно переименовать) профиль пользователя в %USERPROFILE%/AppData/Local/Google/Chrome
2. В свойствах сетевого соединения (Центр управления сетями и общим доступом / Изменения параметров адаптера, там свойства сетевого и бесроводного соединений, смотря какие используются) / протокол Интернета версии 4
если прописаны параметры DNS-серверов, удалите их (переключите в "получать адрес DNS-сервера автоматически) или пропишите известные публичные адреса, например 8.8.8.8 от Google.
3. Удалите все записи в c:\windows\system32\drivers\etc\hosts

P.S.
если это не поможет, можно попробовать открыть командную строку и дать команды
netsh int ip reset c:\resetlog.txt
netsh winsock reset

Кодировка кириллицы в URI в запросе от клиента может отличаться от используемой сервером. Поэтому кириллические символы в URI обязательно надо percent-encode'ить.

Закладок обычно не бывает, но вполне открытым текстом может быть прописано требование не работать над конкурирующими проектами, в т.ч. в течении какого-то времени после увольнения. Это достаточно логично, потому что вы можете в свой личный проект принести идеи и технологии, которые получены совместным трудом в коммерческом проекте. Поэтому при трудоустройстве следует обговорить вашу возможность продолжать работать над своим личным проектом и условия такой работы, и желательно закрепить договоренности в договоре или в приложении к нему. Поскольку с точки зрения вашего работодателя, ваш опыт практически уникален, скорей всего он согласится на подобные условия, а, вполне вероятно, что и согласится на финансовую поддержку вашего проекта, т.к. участие в опенсорсном проекте может быть неплохой рекламой для коммерческого продукта - в большинстве случаев заказчик покупает не код, а услуги.

Например, статья по настройке IPv6 в 3proxy.

Да, есть смысл для bcrypt как минимум. Задача bcrypt в том, чтобы замедлить процесс брутфорса и сделать его ресурсоемким и сложно реализуемым на специализированном оборудовании / GPU / ботнетах и т.п. (см. например openwall.info/wiki/john/GPU/bcrypt). Это сильно замедляет возможности подбора даже относительно слабых паролей.
Есть еще более интересные алгоритмы, например Argon2 и yescrypt.

Вводить разные хэши для разных пользователей не стоит, решение с "перехэшированием" старых хэшей вполне безопасно.

Совершенно не обязательно использовать сторонние плагины, можно использовать аутентификацию посредством клиентского сертификата https://.

На DNS все это как правило не влияет, т.к. размер DNS-пакета обычно ниже MTU. Работа TCP-соединений при неправильно выставленном MTU зависит от выставленного параметра TCP MSS со стороны сервера (многие крупные сервисы специально его занижают, т.к. неправильно сконфигурированный MTU это весьма распространенная проблема) и функционирования в системах клиента и сервера алгоритмов blackhole router detection (PMTU Black Hole Detection / PMTU probing) которые включены по умолчанию в Windows, и доступны практически во всех системах. Поэтому можно достаточно долго не замечать проблем с MTU или замечать их только в определенных ситуациях, например при отправке формы с большим количеством данных или загрузке файла на сервер.
Если проблема всплыла на ютубе, скорей всего это означает что там используется дефолтный MSS и не используются алгоритмы PMTU Black Hole Detection для видеопотоков, возможно из-за использования каких-нибудь специальных железяк с урезанной поддержкой TCP.

Если вы не указывается charset в заголовках HTTP или в META, то браузер, встречая 8-битные символы в документе, пытается определить его кодировку. Работает это эвристически и по статистическим характеристикам текста. Поскольку реально ваш текст короткий, не является русскоязычным и не укладывается в статистические характеристики какой-либо кириллической кодовой страницы, то кодировка с большой долей вероятности определяется неправильно.

Если у вас уже есть AD и вы не любите зоопарки, то логичней использовать NPS
https://msdn.microsoft.com/en-us/library/cc732912(...

1. Основной метод контроля доставки - слежение за ошибками отправки (bounce). Ошибка чаще всего дается непосредственно в SMTP-сессию. В некоторых случаях сервер получателя принимает письмо, но в дальнейшем формирует сообщение о невозможности доставки (NDR).
По стандартам, выдача сообщения о невозможности доставки в SMTP-сессию или отправка NDR являются обязательными, если ваше письмо прошло авторизацию (SPF и/или DKIM) - вы можете быть уверены, что получите баунс в SMTP-сессию или NDR если письмо не будет доставлено практически на 100%. Поэтому если на письмо в разумное время не получено отлупа, можно считать его доставленным. Сообщения о невозможности доставки идут на адрес отправителя SMTP-конверта (envelope-from). Чтобы точно знать, на какой адрес какое письмо не было доставлено, можно для каждого отправляемого письма формировать уникальный envelope-from.

2. Есть расширение SMTP которое называется delivery status notification
https://tools.ietf.org/html/rfc3461
при отправке письма можно запросить, чтобы подтверждение доставки письма в ящик или на сервер получателя, не поддерживающего DSN пришло в явном виде. Подтверждения формирует MTA без участия пользователя. Поддерживается не всеми (например, postfix поддерживает, exim нет).

3. Есть нестандартный заголовок Return-Receipt-To, который работает примерно так же как DSN. Но поскольку он нестандартный, его поддержка крайне ограничена.

4. Есть стандартный (RFC 3798) заголовок Disposition-Notification-To упомянутый выше, это не уведомление о доставке, а уведомление о прочтении. Запрос на это уведомление как правило показывается пользователю и требует его подтверждения. Не надо использовать этот заголовок, если вы не хотите, чтобы вас прокляли.

5. Пиксель в письме - не поможет проверить доставляемость, но в некоторых случаях позволить узнать что письмо было прочитано.

6. (привет модератору). Таки есть службы типа postmaster.mail.ru и postmaster.yandex.ru, которые позволяют отслеживать доставляемость писем получателям данных сервисов, а это порядка 70-80% всех получателей. В данных службах можно смотреть статистику по доставляемости писем, попаданию в папку спам, действия с письмами (чтение, помечания спамом, удаления с прочтением/без прочтения). Причем можно задавать категории писем через специальный заголовок или селекторы DKIM и получать статистику раздельно по категориям писем. Это позволяет получить информацию даже по отдельному письму, задав ему отдельную категорию. Но делать так массово не стоит.
Это основной источник данных по попаданию в спам / удалению без прочтений, etc.

Немного не в тему, но может помочь:

7. Можно (и нужно, если вы организуете массовые рассылки) завести ящики-ловушки на разных сервисах, добавлять их в рассылки и отслеживать доставляемость писем до этих ящиков, в частности попало ли письмо в inbox.

8. Почти все крупные сервисы поддерживают FBL. Вы можете в реальном времени узнавать, если на вашу рассылку идут жалобы пользователей.