estic

В некоторых принято: Уведомления о письмах по 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 года.

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

Даже так? )

Тогда нам с вами не о чем говорить. Хотя формально MVC != единая точка входа 😉

Ну, чисто теоретически, можно что-нибудь придумать и для множества точек входа. Но из реального опыта ничего не подскажу. Это было очень давно.

От ВКонтакте не нужна. Ее заменяет обычная ссылка на страницу ВКонтакте.

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