Этот вопрос к криптографии отношения не имеет. Это просто данные документа в каком-то формате, который надо знать и который наверняка где-то можно найти, поскольку скорей всего это международный стандарт.
Любой из этих методов рабочий и нормальный, выбирайте то, что вам удобней. Трогать яндекс-почту чтобы слать с того же домена не требуется, достаточно сконфигурировать 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 есть стандартные механизмы и библиотеки, и для клиента и для сервера, например его скриптом не получишь и в логах на сервере он наверняка не осядет
У почты mail.ru нет открытого документированного HTTP API, ссылка выше на API "Моего мира" поэтому почтовых функций там нет, можно посмотреть вызовы API в веб или мобильных приложениях, но работоспособность такого способа никто не гарантирует. Правильней для ваших целей использовать IMAP или POP3.
Есть фронтенд, есть бекенд и есть клиентсайд (то что работает в браузере). Насколько я понимаю. POST у вас формирует клиентсайд. Дальше этот POST из браузера куда идет? Если в то, что вы называете бекендом минуя фронтенд, то это не бекенд, а фронтенд сервера авторизации. Он в клиентсайд (видимо) возвращает рефреш-токен кукой (кука на домен сервера авторизации, потому что с рефреш-токеном ходят на сервер авторизации, а не в API) + аксес токен. Т.е. кука с рефреш токеном должна быть не с локалхоста, а с того сервера, который атворизует пользователя. Что вы дальше будете дергать с аксес токеном? Если ходить в фронтенд на локалхосте, то сделайте ручку на локалхосте, куда передается аксесс-токен из клиентсайда и которая проставляет этот токен в куку (или генерирует отдельную сессионную куку а токен хранит серверсайдно). Либо можете из клиентсайда передавать токен с каждым запросом в API на фронтенд. Если аксесс-токен протухает - делаете редирект на сервер авторизации для получения нового аксесс-токена. Клиентсайд приходит туда с рефреш-токеном в куке и получает новый аксесс-токен, который пробрасывает в ваше ручку, которая проставляет куку (или просто обновляет токен в клиентсайдной переменной внутри скрипта, если токен передается в запросах к API)
