Вы абсолютно правы, но сейчас даже нет необходимости сохранять и отправлять образцы — в сообщении об ошибке содержится ссылка, перейдя по которой Вы отправите в саппорт жалобу со всей необходимой информацией для анализа. Жаловаться стало удобнее :)
Ваше предположение, что проблема в том, что «письмо идет от отправителя не @gmail.com» не совсем верно. Ваше письмо не проходит проверку антиспама — а антиспам не работает по столь «прямолинейным» алгоритмам — оцениваются и заголовки, и содержание письма, и множество самых разных факторов. Чтобы разобраться с проблемой, Службе Поддержки необходимо увидеть образец Вашей рассылки.
Для удобства прямо в тексте ошибки указана ссылка, по которой нужно перейти чтоб пожаловаться на некорректное срабатывание антиспама. Полный текст ошибки выглядит так (разумеется коды будут уникальные, конкретно для Вашего случая):
Попробую внести ясность в дискуссию с «провинившейся» стороны, саппорта Почты@Mail.Ru.
Конечно, 48 часов здесь не при чем и при обновлении DNS-записей мы учитываем TTL в соответствие со стандартами. Имел место некорректный ответ сотрудника, и я приношу Вам свои извинения за него. Мы обязательно проведем «работу над ошибками».
Что касается Вашей проблемы — она заключалась в другом. При получении почты MX-сервер Mail.Ru не только определяет наличие PTR-записи как таковой, но эта запись не должна быть похожа на стандартные PTR для пулов динамических IP-адресов. К сожалению, имя Вашего домена попадало под один из таких шаблонов, разумеется ошибочно :(
Благодаря Вашему сообщению проблему нашли, конфигурации исправили, спасибо!
На данный момент проблемы быть не должно.
С уважением и искренними извинениями,
Кондратов Николай
руководитель Службы Поддержки Mail.Ru
Вы либо не читаете писем, либо — лукавите. Оба эти предположения меня сильно расстраивают :(
Вы написали на support@corp.mail.ru 28 сентября в 13:38 — и в 13:54 получили ответ. Ваше письмо касалось модерации приложения — и этот вопрос находится вне зоны компетенции Службы Поддержки проекта «Почта». Ваше письмо было передано в соответствующее подразделение и Вам ответили, что официальный ответ по проблеме Вы получите в течение нескольких дней.
Насколько мне известно, ответ по вопросу Вам уже отправлен. Надеюсь, на этот раз Вы его получили :)
Саппорт работает 7 дней в неделю по сменному графику, в будние дни это 2 смены по 6 часов (с 9 до 15 и с 15 до 21), в праздники и выходные — одна 8-ми часовая смена (это связано с меньшим потоком заявок в выходные)
Безусловно. Поэтому существует четкий регламент, в котором описываются ситуации когда «сильно много уже не хорошо». Например, существуют ограничения работы в две смены подряд — такое допускается только для сотрудников, доказавших на деле, что они справляются с подобным графиком без ущерба для производительности и качества.
Сообщите, пожалуйста, конкретные тикеты по которым Вы не получили ответ.
Что касается той информации, которую запрашивает саппорт — увы, это не прихоть. Действительно, в ряде случаев по коду ошибки невозможно понять истинную причину проблемы. В этом случае мы запрашиваем оригинал блокируемого письма. Даже если Вы отправляете письма скриптом или из консоли, можно отправить его на abuse@corp.mail.ru, сообщив об этом саппорту.
Механизм не очень удобный, мы знаем об этом, и в скором времени планируем кардинально поменять его.
Принимаем умных и красивых :) это шутка, конечно, на самом деле жестких критериев отбора нет, у нас успешно работают и «гуманитарии» и «технари». Важно желание работать и настрой на результат. Есть тест, который проводится перед собеседованием, и собственно собеседование. Зарплата зависит от количества смен, она различается для разных подразделений и линий. При желании (и возможности) работать не проблема зарабатывать от 15 тысяч в месяц.
Речь идет не о работе сверх положенного уровня, а о работе выше «минимального порога» (это 10 смен в месяц, в нашем случае). Выигрывают от работы «сверх» все, на самом деле — работник получает возможность больше заработать; для нас это означает, что сотрудник не выпадает из контекста проблем (не теряет квалификацию иными словами), чем больше смен у одного сотрудника, тем меньше отдельных людей нам нужно (а значит их проще контролировать, проще составлять расписание) — профитов очень много, могу перечислять еще, но думаю основная идея понятна :)
Вы написали 09.09 в 16:22, мы приняли багрепорт, Вам ответили в 16:50 что проблема принята и будет исправлена. По результатам исправления проблемы мы обязательно связываемся с написавшим (об этом мы Вам тоже писали в письме). Действительно, имела место техническая проблема, которая была после Вашего письма незамедлительна передана разработчикам для исправления. К сожалению, ускорить решение той или иной технической проблемы не всегда возможно со стороны техподдержки, прошу отнестись с пониманием к этому факту ;)
На данный момент у меня есть информация, что баг исправлен, если проблема повторится, пожалуйста, напишите мне в личку.
Выше я вкратце описывал процесс этапного обучения и аттестации. Подробный рассказ об этом, боюсь выпадет за формат комментария — спасибо за идею темы поста :) Обязательно расскажу об этом.
Если проблема не решается на первой линии, она решается на второй. Т.е. повторное письмо не будет проходить через первую линию, а сразу попадет в соответствующую очередь второй линии.
Что касается паролей, то идентификация пользователя происходит по множеству факторов, многие из которых поддаются формализации, например IP входов, даты и статусы писем и т.п. и не требуют «человеческого» доступа в ящик и к переписке. Конечно, не всю предоставленную информацию можно проверить таким образом, именно поэтому саппорт просит сообщать как можно больше деталей для восстановления пароля.
За много лет работы Mail.Ru техподдержка прошла длинный путь, были проблемы и были (к сожалению, иногда обоснованные) претензии к работе службы. Сейчас мы больше сфокусированы на качестве и на факте решения проблемы.
Чтобы перейти в конструктивное русло, было бы интересно получить от Вас номера тикетов и суть проблем, с которыми Вам приходилось обращаться в саппорт (можно в личку). Если проблемы были, я уверен — это позволит нам сделать соответствующие выводы.
Спасибо!
Если речь идет о массовых рассылках (легитимных, конечно ;) — то у нас есть документ, регламентирующий технические требования к ним — http://help.mail.ru/mail-help/rules/technical. При соблюдении его требований проблем быть не должно.
Не всегда Служба Поддержки работала без нареканий, были определенные проблемы, особенно если Вы писали давно. Однако мы стараемся идти по пути улучшения :)
Сейчас таких проблем быть не должно и Ваша заявка будет обязательно обработана.
Ваше предположение, что проблема в том, что «письмо идет от отправителя не @gmail.com» не совсем верно. Ваше письмо не проходит проверку антиспама — а антиспам не работает по столь «прямолинейным» алгоритмам — оцениваются и заголовки, и содержание письма, и множество самых разных факторов. Чтобы разобраться с проблемой, Службе Поддержки необходимо увидеть образец Вашей рассылки.
Для удобства прямо в тексте ошибки указана ссылка, по которой нужно перейти чтоб пожаловаться на некорректное срабатывание антиспама. Полный текст ошибки выглядит так (разумеется коды будут уникальные, конкретно для Вашего случая):
550 spam message discarded. Please visit
mail.ru/notspam/abuse?c=XaisCc8K4JDu_NHfPpZdr5kaLTUE1R6[...] or report
details to abuse@corp.mail.ru. Error code:
09ACA85D90E00A[...]. ID: 0000000C00000CCB1[...].
Вам нужно всего лишь перейти по ссылке, по результатам анализа Вашего образца с Вами обязательно свяжутся.
Попробую внести ясность в дискуссию с «провинившейся» стороны, саппорта Почты@Mail.Ru.
Конечно, 48 часов здесь не при чем и при обновлении DNS-записей мы учитываем TTL в соответствие со стандартами. Имел место некорректный ответ сотрудника, и я приношу Вам свои извинения за него. Мы обязательно проведем «работу над ошибками».
Что касается Вашей проблемы — она заключалась в другом. При получении почты MX-сервер Mail.Ru не только определяет наличие PTR-записи как таковой, но эта запись не должна быть похожа на стандартные PTR для пулов динамических IP-адресов. К сожалению, имя Вашего домена попадало под один из таких шаблонов, разумеется ошибочно :(
Благодаря Вашему сообщению проблему нашли, конфигурации исправили, спасибо!
На данный момент проблемы быть не должно.
С уважением и искренними извинениями,
Кондратов Николай
руководитель Службы Поддержки Mail.Ru
Вы написали на support@corp.mail.ru 28 сентября в 13:38 — и в 13:54 получили ответ. Ваше письмо касалось модерации приложения — и этот вопрос находится вне зоны компетенции Службы Поддержки проекта «Почта». Ваше письмо было передано в соответствующее подразделение и Вам ответили, что официальный ответ по проблеме Вы получите в течение нескольких дней.
Насколько мне известно, ответ по вопросу Вам уже отправлен. Надеюсь, на этот раз Вы его получили :)
Что касается той информации, которую запрашивает саппорт — увы, это не прихоть. Действительно, в ряде случаев по коду ошибки невозможно понять истинную причину проблемы. В этом случае мы запрашиваем оригинал блокируемого письма. Даже если Вы отправляете письма скриптом или из консоли, можно отправить его на abuse@corp.mail.ru, сообщив об этом саппорту.
Механизм не очень удобный, мы знаем об этом, и в скором времени планируем кардинально поменять его.
Вы написали 09.09 в 16:22, мы приняли багрепорт, Вам ответили в 16:50 что проблема принята и будет исправлена. По результатам исправления проблемы мы обязательно связываемся с написавшим (об этом мы Вам тоже писали в письме). Действительно, имела место техническая проблема, которая была после Вашего письма незамедлительна передана разработчикам для исправления. К сожалению, ускорить решение той или иной технической проблемы не всегда возможно со стороны техподдержки, прошу отнестись с пониманием к этому факту ;)
На данный момент у меня есть информация, что баг исправлен, если проблема повторится, пожалуйста, напишите мне в личку.
Что касается паролей, то идентификация пользователя происходит по множеству факторов, многие из которых поддаются формализации, например IP входов, даты и статусы писем и т.п. и не требуют «человеческого» доступа в ящик и к переписке. Конечно, не всю предоставленную информацию можно проверить таким образом, именно поэтому саппорт просит сообщать как можно больше деталей для восстановления пароля.
Чтобы перейти в конструктивное русло, было бы интересно получить от Вас номера тикетов и суть проблем, с которыми Вам приходилось обращаться в саппорт (можно в личку). Если проблемы были, я уверен — это позволит нам сделать соответствующие выводы.
Спасибо!
Сейчас таких проблем быть не должно и Ваша заявка будет обязательно обработана.