Возможно ли оптимизировать период отправки дайджестов для тысяч сообществ? Каждый понедельник Discourse отправляет несколько тысяч писем за 1–2 секунды, что приводит к проблемам со спамом на нашем собственном почтовом сервере.
Как сбросить значение «last_digest_time» для каждого аккаунта и синхронизировать его с остальными тысячами аккаунтов?
Цель — получать 100–200 дайджестов в день вместо 5 тысяч по понедельникам. Мы используем Discourse уже 4 года, возможно, проблема связана с обновлением, которое мы часто выполняем до последней версии.
Также, возможно, есть подсказка, как получить доступ к базе данных PostgreSQL в образе Docker и где именно в БД нужно обновлять записи.
Какие у вас есть идеи? Сервер просто отправляет письма в те места, где их сразу помещают в спам. Я бы поступил так же, если бы кто-то прислал мне 2 тысячи писем за 1 секунду.
Если вы размещаете собственный SMTP-сервер, вы сталкиваетесь с типичными связанными с этим проблемами. Компании, занимающиеся доставкой почты, такие как Mailgun и SendGrid, используют множество методов для обеспечения доверия к своим серверам и их восприятия как надежных сетями получателей. Именно поэтому в документации рекомендуется использовать один из этих продуктов вместо самостоятельного хостинга.
Точно — хотя вы отправляете такие сообщения всплесками, авторитетные сторонние службы отправки почты могут надежно доставлять сотни тысяч писем в сторонние почтовые ящики каждый час.
К сожалению, мы не можем оказать помощь, если вы настаиваете на запуске собственного почтового сервера. Если вы решите не следовать рекомендациям, вы принимаете на себя дополнительную сложность, которую это создает.
Со SMTP всё в порядке, включая DMARC, SPF и DKIM. Я использую собственный SMTP с 2005 года. В то время не было этих бесполезных сервисов «деньгоделательных машин». Давайте представим, что завтра кто-то попытается взимать плату за воздух…
Итак, вернёмся к проблеме. Я знаю, что самый лёгкий путь для старшего тестировщика — перенаправить меня куда-то или предложить что-то платное. Не мог бы кто-нибудь помочь с исправлением критической ошибки в Discourse? Я всё ещё не согласен с тем, что Discourse должен отправлять 10 000 писем в секунду. Должен быть сервис ротации или что-то подобное, которое нормализует «last_digest_timestamp» между аккаунтами.
Я не работаю в CDCK и не имею финансовой заинтересованности в том, чтобы направлять вас к каким-либо сторонним сервисам.
Если вы не хотите следовать рекомендациям и документации — это ваше право. В таком случае вы выходите из сферы бесплатной поддержки, которую мы предоставляем здесь сообществу, и ваш единственный вариант — обратиться к консультанту через Marketplace.
Это не проблема Discourse. Дело в том, что IP-адрес вашего почтового сервера не считается надежным. Мы не можем помочь вам это исправить, а вы отказываетесь рассматривать существующие для этого варианты.
Да, я работаю с сообществами, которые отправляют в десять раз больший объём писем; многие из тех, кто управляет крупными сообществами, работают на таком же или ещё более масштабном уровне.
Ваши потребности в отправке электронной почты, по-видимому, теперь превышают вашу экспертизу в работе с протоколом для надёжной доставки больших объёмов писем. Именно для этого существуют сервисы транзакционной рассылки. Здесь никто не рекламирует «крупную почтовую инфраструктуру» — речь просто о сложности доставки писем в большом объёме.
Вы можете настроить свой почтовый сервер так, чтобы он удерживал письма и распределял их отправку. Это действительно проблема вашего почтового сервера, а не Discourse. Я управлял почтовыми серверами с начала 1990-х годов примерно до 2005 года, когда спам сделал это слишком сложным. Сейчас это гораздо сложнее.
У меня есть некоторые ограничения по частоте. Если вы даже этого не делаете, типичные SMTP-серверы имеют для вас заранее настроенные параметры. Сегодня почтовые серверы умнее и легко могут обнаружить вашу задержку между письмами.
Да, потому что они используют сервис, о котором вы упоминали ранее. Вы всё ещё не понимаете разницы между этими сервисами и личным SMTP-сервисом. Они используют огромный пул IP-адресов и имитируют разных отправителей. Это хорошая техника для компаний, занимающихся «жёстким» спамом. Конечно, они платят за этот сервис.
Я не вижу причин, почему люди должны использовать эти «машины для зарабатывания денег» для Discourse, если Discourse не отправляет спам. Ой… извините… из-за бага он может отправить 100 тысяч писем в понедельник за 1 секунду, потому что @Stephensays утверждает, что это ПРАВИЛЬНОЕ поведение.
Ладно, я не вижу смысла общаться с людьми, у которых на голове корона . Да, Discourse — это круто, и большое спасибо за ваш вклад.
Я надеюсь, что простые люди без найдут здесь какие-то идеи.
Согласно ответам команды Discourse выше, они не видят никаких проблем в работе Discourse. Я решил эту проблему не совсем чистым способом, напрямую изменив базу данных. Вот моё решение:
cd /var/discourse
./launcher enter app
rails c
Topic.exec_sql("UPDATE users SET last_emailed_at = now() + interval '30' second * id WHERE last_emailed_at > ('2020-03-14'::date) AND last_emailed_at < ('2020-03-17'::date)")
Пожалуйста, обновите диапазон last_emailed_at в SQL-запросе. У меня было 4 тыс. записей last_emailed_at за один день — 16 марта. Таким образом, теперь все пользователи оптимизированы с интервалом в 30 секунд на протяжении 3 дней.
Discourse не предназначен для использования с личным SMTP-сервисом. Извините, что это не было объяснено чётко; он, безусловно, может работать, но для сообщества с регулярной почтовой активностью это не лучшая идея. Это ограничение, обусловленное текущим состоянием электронной почты, и мы все реагируем на него по мере возможности.
. Да, Discourse — это круто, и большое спасибо за ваш вклад.