Adamos, 8 битные кодировки и их стандартизация это вообще страдание, к счастью почти вымершее. Это старая история https://en.wikipedia.org/wiki/Windows_code_page#AN... - на тот момент стандартов на 8-битные кодировки просто не существовало. Сначала планировалась совместимость с разрабатываемым стандартом ANSI и API декодирования (например) назвали типа OemToAnsi. Потом ANSI отказалась от стандартизации 8-битных кодировок и методы переименовали (в OemToChar например), но старое название прижилось, потому что ISO в итоге стандартизировало другие кодировки и в итоге оказалось на N пропиетарных стандартов больше
Adamos, ANSI это не то же что ASCII, в Windows так принято называть 8-битные Windows-кодировки, т.е. если кириллица выбрана как язык, то ANSI-кодировкой будет Windows-1251, OEM-кодировкой cp866. Можно попробовать системный язык установить в кириллицу.
Этот вопрос к криптографии отношения не имеет. Это просто данные документа в каком-то формате, который надо знать и который наверняка где-то можно найти, поскольку скорей всего это международный стандарт.
Любой из этих методов рабочий и нормальный, выбирайте то, что вам удобней. Трогать яндекс-почту чтобы слать с того же домена не требуется, достаточно сконфигурировать DKIM и SPF для отправляющего сервера.
Отправитель не будет отправлять письмо на два сервера, если вы хотите получать почту на два сервера, вам необходимо самостоятельно настроить пересылки с одного сервера на другой или какой-то другой способ синхронизации почты.
Если у тебя стандартный http прокси, то скорей всего, должно быть
proxies={'http': 'proxi'}
даже если через прокси делается https запрос. https пркоси это когда трафик к прокси дополнительно оборачивается в TLS еще раз
Для DNS TransparentPlugin не требуется, если вы еще и транспарентный прокси используете то нужны команды transparent до tcppm и notransparent после. Убедитесь что вы трафик который идет от прокси не заворачиваете обратно в прокси.
Вадим, обычно в цепочке и будет два Received - один от сервера отправителя, второй от сервера получателя. Длинные цепочки скорей исключениеа. В примере выше отправитель пользуется облачным Office 365 для корпоративного домена, оттуда письмо ушло на корпоративный сервер отправителя (cisco.com), там достаточно сложная схема внутренней маршрутизации, оттуда письмо отправилось на сервер списков рассылок, где тоже достаточно сложная схема обработки + передача письма в Amavis для проверки и обратно и только потом на сервер получателя, но это одна из самых длинных цепочек встречающихся на практике.
перенаправляет трафик по 80му порту в локальный http прокси, это позволяет видеть в логах HTTP запросы и писать правила специфичные для HTTP, если этого не требуется -- можно убрать. transparent/notransparent влюкчает транспарентный режим для tcppm и отключает для сервисов ниже. proxy в вашей конфигурации скорей всего не нужен, если вы его не используете и его можно убрать
Ваш почтовый сервер будет делать то, на что вы его настроили. Вам нужно настроить проверку SPF, DKIM и DMARC, https://exim.org/exim-html-4.93/doc/html/spec_html...
сейчас у вас, судя по отсутствию заголовков Authentication-Results, ничего из этого не проверяется.
тем что для basic есть стандартные механизмы и библиотеки, и для клиента и для сервера, например его скриптом не получишь и в логах на сервере он наверняка не осядет