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

Если вы не указывается 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. Вы можете в реальном времени узнавать, если на вашу рассылку идут жалобы пользователей.

Попробуйте перед этим проверить, что можете подключиться к компьютеру через
net use \\IP address\IPC$
если получите ошибку, то проблема именно в этом, попробуйте подключиться анонимно
net use \\IP address\IPC$ "" /u:""
или с указанием логина/пароля эккаунта на конечном компьютере
net use \\IP address\IPC$ /user:ИМЯ_ПОЛЬЗОВАТЕЛЯ

proxy -p8001 -eIP_VPN_1
proxy -p8002 -eIP_VPN_2
proxy -p8003 -eIP_VPN_3
где IP_VPN_1 - IP адрес локального интерфейса первого VPN.

В соответствии с гражданским кодексом, контент и все права на него принадлежит его автору (ГК РФ Статья 1255). Права могут быть переданы, но авторство не может быть отчуждено.
Но если вы напишете лицензию так, что легальный доступ к контенту будет получать пользователь посредством вашего клиента, т.е. вы не будете копировать контент куда-то и давать доступ к нему тем, кто не имеет доступа к контенту внутри вконтакта, а будете действовать исключительно как клиентское приложение, то никаких действий с объектом авторского права вы тогда не производите и ничьих прав не нарушаете.

Посмотрите
netstat -na | find "27500"
возможно у вас уже открыт порт из-под другого юзера?

Для резолвинга используется не имя Windows-домена, а домен прописаный в конфигурации DNS в TCP/IP (или отдаваемый DHCP-сервером)
https://s.mail.ru/8nh8/FC5e8inua

Проблема может быть в том, что между клиентом и сервером NAT и на роутере из-за неактивности "протухает" запись в таблице NAT. Но решение, которое подсказали выше (keep-alive) поможет и в данном случае, только помимо собственно keep-alive'а необходимо установить keep-alive timeout секунд в 300 хотя бы, т.к. дефолтное значение (обычно 7200 секунд) вас не спасет. Т.е. помимо SO_KEEPALIVE необходимо установить TCP_KEEPIDLE/SIO_KEEPALIVE_VALS в зависимости от системы. В качестве альтернативы вы можете предусмотреть отправку keep-alive пакетов на уровне прикладного протокола. Обычно протоколы, рассчитанные на длинные соединения с небольшим трафиком, например мессенджеры, используют именно протокольные keep-alive.

Статические методы не применяются к объекту класса, они существуют отдельно от объектов, поэтому не имеют доступа к любым нестатическим членам класса. Если вы хотите использовать свойство конкретного объекта - вы должны в явном виде передать ссылку на этот объект в статический метод (что в общем-то не имеет смысла, разуменый сделать метод не статическим)

Очень нехорошо иметь офисный NAT и почтовый сервер на одном IP. Скорей всего, кто-то в офисной сети подхватил троянца, через который идет активная рассылка спама, поэтому IP блеклистят, причем поскольку он является частью ботнета, то блеклистят как IP конечных пользователей, что скорей всего надолго. Репутация IP скорей всего убита, на ее восстановление у разных почтовых провайдеров может потребовать от недели до бесконечности.

Закройте доступ из локальной сети наружу по 25му порту. Это следовало сделать сразу, чтобы не подставлять почтовый сервер в подобных ситуациях + обязательно установите рейтлимиты по пользователям на самом почтовом сервере, чтобы нельзя было активно спамить через него, обязательно следите за превышениями рейтлимитов / блокируйте скомпрометированных пользователей.
После этого два варианта:
1. Ждать пока репутация восстановится, параллельно вынося себя из известных RBL'ей
2. Попросить у провайдера выделить дополнительный IP адрес или небольшую сеть и назначить отдельный IP почтовому серверу.

Напишите на support_target@corp.my.com - вам помогут.

Исходите из экономической обоснованности разработки своего функционала. Все зависит от того, является ли подобная рассылка для вас профильной, основным источником дохода или это вспомогательный инструментарий. Ориентируйтесь на затраты на пользователя при рассылке, если этот показатель близок к ARPU, то вам так или иначе придется делать свой функционал, чтобы заработать за счет снижения затрат. Если затраты на рассылку составляют небольшую часть, то вам не имеет смысла заниматься непрофильной разработкой, пользуйтесь готовыми услугами, если, конечно, у вас разработчики не простаивают.

Напишите на abuse@corp.mail.ru, приложите текст сообщения об ошибке доставки или заголовки письма из папки "Спам".