Кажется у mail.ru создаются с каждым ящиком разные аккаунты-страницы в мой мир и т.п. сервисах, а ссылки этих аккаунтов выглядят как /bk/vashlogin/ и они просто парсятся спамерами как почтовые ящики. Помню такое было пару лет назад, не знаю, исправили ли это или нет.
Основная проблема с почтой mail.ru, что нормальные письма не то что не попадают в папку спам, они вообще до ящика не доходят. Это самое ужасное. Часто наши письма на mail.ru даже со ссылкой на восстановление пароля не доходят вообще на ящик. С другими почтовыми системами такой проблемы нет.
Т.е. вы фильтруйте, но пусть вся почта все равно поступает в папку «спам», а не не пропадает где-то в фильтрах.
Все красиво расписано, но по-факту без мата вспоминать ваш сервис сложновато.
У нас финансовый сервис, около 300к подписчиков по емейл во всем мире. С мейл.ру всегда проблемы, вот вообще всегда — письма даже вида ваш месячный баланс или восстановление пароля иногда пачками уходят в спам. Ваша прекрасная служба поддержки произносит один и тот-же чудесный ответ: улучшайте качество рассылки, даже однократные сигналы от пользователей могут отправить рассылку в спам.
С другими почтовыми сервисами проблем вообще нет. После 4 или 5 контакта с вашей ТП просто забили на это дело и попросили пользователей использовать ящики на нормальных сервисах.
А можете дать нам номер последней заявки, чтобы мы смогли проанализировать ситуацию?
Решение о блокировке писем принимается по совокупности факторов, одного нажатия кнопки «Это спам» недостаточно.
О факторах, которые могут повлиять на доставляемость писем, мы писали здесь: https://habrahabr.ru/company/mailru/blog/216535/
Общую информацию о правилах рассылок можно прочесть тут: https://help.mail.ru/mail-help/rules/info
На самом деле, я искал другую ссылку в тот комментарий, но вовремя не нашел https://panopticlick.eff.org
Как ты собрался спасаться виртуалкой с впном, если у тебя останется всё тот же браузер, с тем же набором плагинов и еще какие-то штуки через канвас там получают, емнип.
В общем, вы меня пока не переубедили. Пока еще всё тлен.
А еще интересно насчет миграции с Parse. Вот мы мигрировали, допустим — что дальше? Я так понимаю, фронтенд нужно переписывать полностью с вашими SDK? Если да, то приятного мало. Если нет, то, следовательно, ваши SDK на уровне API совместимы с Parse SDK. Но это догадки, а где прямые и явные утверждения? Вы говорите потенциальным пользователям — ребята, вы собираетесь куда-то переходить с Parse — давайте к нам! А дальше — молчок. Ведь это неизбежные вопросы, которые возникнут у каждого Parse-юзера, который ищет (если еще не нашел) альтернативу.
Спасибо за вопрос. Мы говорим о миграции данных с Parse на Scorocode. Фронт необходимо будет переписывать. Да, это не так удобно, как хотелось бы. Чтобы на уровне API быть совместимыми с Parse SDK, нужно по сути копировать его у себя, а у этого решения есть определённые юридические риски.
ОК.
Испанский хостинг, австрийский, австралийский, шведский…
Да можно все страны мира называть как неподходящие для хостинга.
Выделяются только США, Ирландия (Google), Германия (Хетцнер), Франция (OVH) да Нидерланды.
> Почему выбирать нас? Мы душевнее :) Но если серьезно, то мы как минимум предлагаем альтернативу Parse, а выбор – это ведь хорошо, не так ли?
Выбор — это всегда хорошо. Но выбор вашей платформы подразумевает переписывание фронтендов, а выбор других известных альтернатив Parse — нет.
Кроме того, Parse Server находится в open source и его развивает сообщество. В любой момент пользователь может уйти с альтернативного облачного решения на stand-alone, развернув свою инфраструктуру, с минимальными усилиями и изменениями в коде.
Если же пользователь выбрал вас, от уйти от вас уже не получится — ни с минимальными усилиями, ни с максимальными. Ни с какими. Пользователь будет зависеть от вас точно так же, как в свое время он зависел от Parse. Причем «за спиной» Parse стоял Facebook, что внушало определенную уверенность, пользователь был еще «не пуганный». Последующие же события существенно подорвали веру в BaaS вообще как в концепцию, и сейчас уже меньше желающих наступить на те же грабли.
В частности, поэтому многие из альтернативных решений Parse-хостинга дают пользователям куда больше свободы — например, Back4app дает прямой доступ к Mongo.
Стоит, наверное, упомянуть и то обстоятельство, что в случае, если переезжающий с Parse проект ориентирован главным образом на российского потребителя, то это как раз ваша целевая аудитория, но если ориентация на worldwide, то в нынешних политических условиях хостинг бэкенда в России — это, в общем-то, минус.
Ничего не понял. Что такое «backend»? У меня в продакшене инсталляция openstack'а. У него есть dashboard, который предоставляет веб-интерфейс. Сам dashboard ходит в API. API ходит в API, API ходит в API, API ходит в API, API пересылает запросы через rabbitmq в сервис на компьютах, компьют ходит в API, API ходит в API, API дёргает ABI, на выходе имеем сервис для клиента.
И где тут бэкэнд и куда тут ваше решение должно присоседиться?
Основная проблема с почтой mail.ru, что нормальные письма не то что не попадают в папку спам, они вообще до ящика не доходят. Это самое ужасное. Часто наши письма на mail.ru даже со ссылкой на восстановление пароля не доходят вообще на ящик. С другими почтовыми системами такой проблемы нет.
Т.е. вы фильтруйте, но пусть вся почта все равно поступает в папку «спам», а не не пропадает где-то в фильтрах.
У нас финансовый сервис, около 300к подписчиков по емейл во всем мире. С мейл.ру всегда проблемы, вот вообще всегда — письма даже вида ваш месячный баланс или восстановление пароля иногда пачками уходят в спам. Ваша прекрасная служба поддержки произносит один и тот-же чудесный ответ: улучшайте качество рассылки, даже однократные сигналы от пользователей могут отправить рассылку в спам.
С другими почтовыми сервисами проблем вообще нет. После 4 или 5 контакта с вашей ТП просто забили на это дело и попросили пользователей использовать ящики на нормальных сервисах.
Решение о блокировке писем принимается по совокупности факторов, одного нажатия кнопки «Это спам» недостаточно.
О факторах, которые могут повлиять на доставляемость писем, мы писали здесь: https://habrahabr.ru/company/mailru/blog/216535/
Общую информацию о правилах рассылок можно прочесть тут: https://help.mail.ru/mail-help/rules/info
Как ты собрался спасаться виртуалкой с впном, если у тебя останется всё тот же браузер, с тем же набором плагинов и еще какие-то штуки через канвас там получают, емнип.
В общем, вы меня пока не переубедили. Пока еще всё тлен.
Это высказывание так же справедливо, как и уже сказанное выше:
Поясните, пожалуйста? При смене User-Agent меняется хэш, что логично. В чём тлен?
Испанский хостинг, австрийский, австралийский, шведский…
Да можно все страны мира называть как неподходящие для хостинга.
Выделяются только США, Ирландия (Google), Германия (Хетцнер), Франция (OVH) да Нидерланды.
Выбор — это всегда хорошо. Но выбор вашей платформы подразумевает переписывание фронтендов, а выбор других известных альтернатив Parse — нет.
Кроме того, Parse Server находится в open source и его развивает сообщество. В любой момент пользователь может уйти с альтернативного облачного решения на stand-alone, развернув свою инфраструктуру, с минимальными усилиями и изменениями в коде.
Если же пользователь выбрал вас, от уйти от вас уже не получится — ни с минимальными усилиями, ни с максимальными. Ни с какими. Пользователь будет зависеть от вас точно так же, как в свое время он зависел от Parse. Причем «за спиной» Parse стоял Facebook, что внушало определенную уверенность, пользователь был еще «не пуганный». Последующие же события существенно подорвали веру в BaaS вообще как в концепцию, и сейчас уже меньше желающих наступить на те же грабли.
В частности, поэтому многие из альтернативных решений Parse-хостинга дают пользователям куда больше свободы — например, Back4app дает прямой доступ к Mongo.
Стоит, наверное, упомянуть и то обстоятельство, что в случае, если переезжающий с Parse проект ориентирован главным образом на российского потребителя, то это как раз ваша целевая аудитория, но если ориентация на worldwide, то в нынешних политических условиях хостинг бэкенда в России — это, в общем-то, минус.
И где тут бэкэнд и куда тут ваше решение должно присоседиться?
То есть фактически — это удобный конструктор структур данных и API с последующим хостингом.
Openstack используется для создания инфраструктурных облачных сервисов и облачных хранилищ. С его помощью у нас организовано хранение файлов.
Ваше решение более низкоуровневое, предназначено для создания системных облачных решений, наше — для решения прикладных задач.
Примером такой задачи может служить разработка мобильного приложения, которому необходимо хранить и обрабатывать данные на сервере.