estic

Или с самими запросами беда, но я не стал повторять то, что уже написано в теме.

Кэширующий прокси 😊

Facepalm. Поставьте хотя бы 5.4 (.45) 😊

Необязательно. Можно кэшировать страницу не при первом обращении, а заранее (отдельное действие, действие при сохранении основных данных станицы, запускаемый вручную или автоматически фоновый процесс). Также можно использовать кэширование при первом обращении, но выполнять это обращение самому (действие "предпросмотра", запускаемый вручную или автоматически процесс "обхода" определенных страниц).

Ждем следующую тему: Кэш страниц разросся до невероятных размеров. Что делать? 😊

Индексы нужно периодически перестраивать. Но в данном случае они скорее всего просто неправильно составлены.

В некоторых принято: Уведомления о письмах по HTTP

См. выше. Яндекс такого не умеет, но зато поддерживает пересылку почтовых уведомлений (коротких писем о приходе писем). Есть и другие SMTP-to-HTTP-шлюзы, но они обычно платные. Можно и на своем почтовом сервере разместить подобный шлюз.

"Обратные вызовы" обычно выполняются методом POST, не GET 😉

Могут и не разгадывать (каждый раз), а просто нужные куки подставлять. "Самодельные, простенькие" капчи этим часто страдают.

Я бы так активно (или вовсе) не использовал mx в SPF. Свои серверы и сети ты обозначаешь при помощи ip4 (не уверен, что допустимо ipv4), а сторонние - при помощи include. Если используешь только сторонние одного провайдера, тогда просто redirect= 😉

Вот это тоже перепроверьте: vspf1=1 😉

А по-моему этот сервис вполне лоялен, если следовать простым, уже практически стандартным на сегодняшний день, правилам. Gmail построже будет. В нем без "стадии обучения" на "не спам" практически не обходится. А в Mail обычно достаточно заглянуть в postmaster, чтобы в очередной раз убедиться, что все в порядке.

Проблема может быть даже при доступе с одного устройства. Если бы все было так просто, можно было хранить различающиеся IP для каждого устройства пользователя, с которого он входил.

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

Можно использовать код "возобновления сеанса". Как с недавних пор делает Сбербанк.

Даже при использовании JWT обычно нет необходимости хранить данные прямо в токене. Достаточно идентификатора пользователя. Если не хотите его "опубличивать" (здесь речь уже не про JWT), можете "солить" в индивидуальном порядке и динамически менять соль между сеансами.

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

Вот это хорошо. В основном так и защищаются. Конечно, токен должен быть достаточно длинным.

Я тоже не согласен с "проблем не будет", но зачем так резко выражаться? 😊

И я не понял. Зачем-то подняли 10-летнюю тему со своим вопросом и к вечеру уже стали знатоком в этом вопросе 😀 В SPF домена нужно перечислить все источники, с которых могут отправляться письма с адресами отправителя на этом домене. Способ обозначения источника выбирается такой, какой удобнее для конкретного источника (или группы источников).

Тема 2014 года.

Все-таки лучше указывать "имя сервера", а не почтовый домен. Обычно в качестве имени сервера используют домен третьего уровня. Но это не требование, а просто распространенная практика. Можно и второго. В этом случае вероятность совпадения имени сервера с одним из почтовых доменов выше.