Вадим, обычно в цепочке и будет два 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)
Если безопаснику приходится разбираться с криптографией, значит он точно делает что-то не то, потому что с криптографией должен разбираться только криптограф, и криптография не терпит самопальных решений.
Бьерн Страуструп, автор языка C++ преподает своим студентам python, потому что это тот язык, с которого лучше начинать изучение программирования чтобы не отбить себе желание им заниматься.
EVGENIJ NEFEDOV, в результате точно найдете тех, кто хостится у одного хостера. На аффилированность могло бы указывать что у сервисов одинаковый admin-contact, но сейчас его не показывают, да и вообще более чем у половины организаций домен зарегистрирован на частное лицо, там вообще ничего не показывают.
gmail не использует spamhaus. Убедитесь что у вас нормально прописан PTR и что сеть из которой выделен IP нормально оформлена во whois как корпоративная (что там нет чего-нибудь типа residential, NAT, dynamic и тп). И пройдитесь по https://habr.com/en/company/vk/blog/239963/ чтоб по каждому пункту новый вопрос не задавать
