От новичка: сегодня у нас произошла ситуация, когда вся наша почтовая рассылка была фактически заблокирована, и пользователи не могли регистрироваться, восстанавливать пароли или входить в систему через email. Это произошло потому, что еженедельная рассылка началась сразу после миграции с устаревшего форума, и в очереди sidekiq скопилось более 300 000 писем. В результате никто, кто пытался войти через email, зарегистрироваться или восстановить пароль, не получил ни одного письма и оказался в безвыходном положении (как говорят, был в полной заднице).
Обратите внимание, что использование бесплатного Gmail для отправки любых писем из Discourse не поддерживается. Это связано с условиями предоставления услуг Google. Использование Gmail таким образом граничит с #неподдерживаемой-установкой.
Трудно понять, как может иметь смысл реализация этой просьбы о добавлении функции: если бы вы использовали поддерживаемый механизм отправки электронной почты, данный инцидент не мог бы произойти.
Это не так.
У нас есть домен Google, и бесплатная почта поддерживалась в течение многих лет и поддерживается сейчас.
Проявите немного снисходительности после того, как вы управляете форумом уже 20 лет… Мы не только что вылупились из яйца вчера, @Stephen
Это абсолютно так: сообщества, которые игнорируют наше руководство по электронной почте, постоянно сталкиваются с этой проблемой.
Google не разрешает отправлять транзакционные письма с аккаунтов Gmail, и мы видели, как сообщества навсегда теряли свои аккаунты при попытке сделать это. Платные аккаунты G Suite также имеют жёсткие лимиты на количество транзакционных писем в день. Вы не первый, кто оказался в такой ситуации, и мы не можем помочь вам обойти условия, установленные Google, с помощью технических решений.
Я только что вошёл в нашу учётную запись GSuite и проверил Условия использования: то, что вы говорите, не соответствует действительности:
@Stephen, вы слишком поспешны в своих выводах. Я не просил функцию для «обхода Условий использования Google», поэтому прошу воздерживаться от искажения моих сообщений.
Вы слишком поспешны в своих выводах и ложно обвиняете людей, @Steven. Возможно, стоит дать возможность ответить на мои запросы тем, кто не так поспешен?
Здесь есть некоторое противоречие в ваших словах:
Gmail не является G-Suite. Платные аккаунты G-Suite имеют следующие ограничения:
| Тип ограничения | Ограничение |
|---|---|
| Сообщения в день | |
| Дневной лимит отправки* | 2 000 (500 для пробных аккаунтов) |
Бесплатные аккаунты Gmail всегда имеют лимит в 500 писем.
Это Условия использования Google, они не имеют отношения к вышеупомянутому. Определённо есть разница между «это работало до сих пор» и тем, что вам разрешено это делать. За последние семь лет мы видели, как пользователи пытались это сделать, но это никогда не заканчивалось успешно:
Дополнительная информация по теме
New setup - errors when trying to send emails through gmail - #2 by pfaffman
Office 365 SMTP settings - #2 by codinghorror
https://meta.discourse.org/t/setup-smtp-in-discourse/79173/2
Anyone using gmail for SMTP? - #8 by sam
Gmail SMTP Relay Setup not working - #2 by justin
Can I use gmail smtp? - #2 by fefrei
POP3 polling error - #4 by pfaffman
Sidekiq queue too large - Google email provider problems - #2 by codinghorror
Существует руководство по настройке электронной почты со списком рекомендуемых провайдеров. Вы не обязаны ему следовать, но мы не можем помочь вам использовать Gmail или GSuite способами, для которых они не предназначались.
Да, я знал всё это ещё до того, как написал пост, @Steven.
На мой взгляд, вам действительно стоит воздержаться от недооценки знаний человека, который находится в сети ещё до появления браузера Mosaic, и быть осторожнее в формулировках ответов. Не отбивайте у людей радость от Discourse и технологий в целом, делая обвинительные заявления в их адрес.
Сначала вы заявили, что «бесплатного Gmail не существует» (что я знал как неверное утверждение) и обвинили меня в каких-то злонамеренных действиях, а затем, видимо, провели собственное расследование и выяснили, что в GSuite лимит составляет 2 500 писем в день, что я знал уже давно, так как управляю этим аккаунтом GSuite уже много лет.
Вам следовало бы извиниться, когда вы так поспешно нажимаете на курок, начинаете обвинять людей в плохих поступках и ошибаетесь в деталях.
На самом деле совсем не весело публиковать простой запрос на новую функцию и вынужденно отвечать на такую негативную энергию.
Это предполагает, что вы используете Gmail, а не GSuite, что нарушает правила. Многие люди, особенно те, кто не знаком с системным администрированием, пытаются использовать Gmail, что является нарушением условий использования. Сообщать об этом — хорошая идея, это не грубо и не злонамеренно.
Однако вы используете GSuite, что вполне допустимо. Из вашего первоначального сообщения это было невозможно понять. Именно поэтому кажется, что с вами поступают несправедливо.
Но GSuite на самом деле не подходит для форума с большим трафиком, как вы описываете. Вы просите новую функцию, чтобы Discourse каким-то образом работал с почтовым сервисом, ограничивающим вас 2500 сообщениями в день.
Это возможно, но будет непросто — создать плагин для этого. Я предполагаю, что это займет несколько дней работы у человека, знакомого с разработкой Discourse.
Решение — использовать почтовый сервис, который сможет доставлять нужный вам объем писем.
Чтобы продолжить, отмечу, что эта тема дублирующая. Запрос на поддержку нескольких SMTP-сервисов уже поднимался ранее:
Здесь случай немного отличается, но проблема возникла из-за некорректной конфигурации дайджеста. На Unix.com зарегистрировано 138 062 пользователя, и лимит в 2000 писем в день, даже для критически важных задач, таких как сброс пароля, позволит взаимодействовать лишь 1,8% пользователей ежедневно.
edit: исправлено с 2500 на 2000, чтобы отразить фактический лимит
Именно поэтому, @pfaffman, всем участникам онлайн-обсуждений лучше не быть слишком поспешными в высказывании обвинительных заявлений в адрес других касательно технологий и/или их мотивов. Обычно мы должны задавать вопросы, прежде чем нажимать на курок и начинать стрелять, LOL.
Да, я написал GMAIL вместо GSUITE, но когда я создавал этот домен десятилетия назад, GSUITE ещё не существовал, и всё называлось просто GMAIL. Более того, я не стал уточнять детали, потому что мое предложение по функционалу НЕ ИМЕЕТ НИКАКОГО ОТНОШЕНИЯ К GMAIL. Это совершенно отдельная тема для обсуждения.
Если бы я хотел (или вы хотели), мы могли бы зайти на любой сервер, как многие здесь могут сделать, и ввести apt install postfix или apt install sendmail, и менее чем за 15 минут мы могли бы запустить свой собственный SMTP-ретранслятор.
Пожалуйста, давайте не будем менять тему обсуждения с переноса большого трафика из процесса дайджестов на обсуждение GMail против GSuite против «Бла-Бла». apt install postfix — это тривиально.
Вопрос заключается в надежности. Это основы, уровень 101.
Запуск критически важной почты на том же SMTP-ретрансляторе, что и дайджесты, — это не тот подход, который мне хотелось бы использовать, поэтому я и подал эту заявку на добавление функции.
Давайте, пожалуйста, держимся темы того, что я запрашиваю, поскольку я действительно знаю, о чем говорю, когда речь идет о создании критически важных приложений.
Вот это снова:
Я не хочу, чтобы моя критически важная почта находилась на том же SMTP-ретрансляторе, что и почта для дайджестов, и я считаю, что это хорошая идея, делающая систему более надежной.
Давайте уйдем от совершенно побочного обсуждения о GMAIL, GSuite или MonkeyMail… бла-бла. Мне жаль, что я вообще об этом упомянул, потому что почтовый сервер не имеет отношения к моему предложению по функционалу.
Замедлитесь. Будьте добры к другим… Если кто-то что-то публикует, и вы чего-то не понимаете или чувствуете себя растерянным, спросите; не стреляйте в людей, @Steven.
Я могу настроить SMTP-ретранслятор за 10 минут. Мы все можем. apt install postfix — готово… Если я захочу использовать GSuite, postfix или donkey kong mail, это мое дело, а не других. Как я уже сказал…
Главный пункт … (снова)
Надежнее иметь критически важную почту на отдельном сервере, чем на канале для дайджестов. Это просто основы для очень загруженного сервера.
Команда apt install postfix создает SMTP-ретранслятор. Я запрашиваю функцию, которая позволит размещать критически важную почту (сброс пароля, регистрационные письма, вход по электронной почте) на отдельном канале от дайджестов по соображениям надежности и производительности.
Это не суть вопроса. Это второстепенно.
Кстати: на самом деле у нас когда-то было более 500 тысяч пользователей, но я их «почистил» ![]()
Я говорю о том, чтобы критически важную электронную почту mission critical email отправлять по отдельному каналу (SMTP-релею), отличному от канала для дайджестов.
Разве не очевидно, что эта простая идея, и легко понять, почему два канала лучше?
Это обсуждение сильно ушло от первоначальной идеи моего запроса на новую функцию.
Извините, что вообще написал и спросил… ![]()
По моему мнению, обсуждение после моего первоначального поста сильно ушло от темы.
Не стоит недооценивать никого из тех, кто пытается вам помочь. Никто не настроен против вас.
Это мой последний пост по этой теме.
Касательно GSuite (что вообще не является сутью моего предложения по новой функции):
- Максимальное количество сообщений, которое пользователь может отправить за 24 часа, составляет 10 000. Однако это число может варьироваться в зависимости от количества лицензий пользователей в вашем аккаунте G Suite.
- Зарегистрированный пользователь G Suite не может пересылать сообщения более чем 10 000 уникальным получателям за 24 часа.
Ссылка: Route outgoing SMTP relay messages through Google | Set up & manage services | Google Workspace Help
Однако для меня это полностью оффтоп, так как даже если бы GSuite разрешала отправку более 1000 миллионов писем в день через SMTP-релей, я всё равно хотел бы иметь отдельный канал SMTP-релея для критически важных писем и для письма с дайджестом.
В этом и заключается суть.
Спасибо. Пожалуйста, учтите это в будущем обновлении. Я считаю, что добавить это относительно несложно.
Это предложение по новой функции не касается личности и также не касается преимуществ или деталей провайдеров электронной почты.
Мое предложение по новой функции касается надежности и того, чтобы критически важные письма не попадали в канал дайджеста.
Всё, на этом всё… ![]()
Разработчики Discourse имеют работающие почтовые системы. Они не станут добавлять функцию для тех, кто хочет использовать несколько ненадежных почтовых систем. Если вы хотите, вы можете разработать плагин. Это будет сложно в разработке и проблематично в поддержке.
Установить Postfix может быть легко, но запустить функционирующий почтовый сервер сейчас гораздо сложнее, чем тогда, когда я портировал Sendmail и uucp на Linux. Если бы запуск почтового сервера был простым, у вас уже был бы работающий сервер, и вы бы не хотели иметь два.
Я так не считаю, но, возможно, вы знаете о разработке плагинов для Discourse гораздо больше, чем я.
Один простой обходной путь — просто «отключить» сводные письма по всему сайту, если они вызывают столько проблем. Возможно, лучшие предложения уже были озвучены; я могу лишь порекомендовать использовать почтового провайдера, который не накладывает никаких ограничений, например, Mailgun. Так все останутся довольны (если только у вас нет ограничений, вынуждающих использовать конкретного провайдера по каким-то причинам).
Я согласен: в первоначальном сообщении от @neounix много противоречий, а в последующих ответах детали постоянно меняются.
В выделении выше — мой акцент. Ограничения для бесплатных аккаунтов уже описаны в других местах этой темы. Даже у «бесплатных» аккаунтов G Suite, перешедших из старого поколения, есть эти ограничения. Если у вас платный аккаунт G Suite, то приведённый выше комментарий вводит в заблуждение и объясняет мой ответ.
Опять же, вы не уточняете, какой именно сервис вы используете. Если это устаревший Google Apps на бесплатном тарифе, то вы ограничены 500 получателями в день на пользователя, так же как и в бесплатном продукте Gmail. Если вы используете платный аккаунт G Suite, вам следует воспользоваться сервисом SMTP-релея Google: лимит там составляет 10 тысяч в день на пользователя — лучше, но всё равно недостаточно, особенно с учётом более 130 000 пользователей, которым нужно запросить сброс пароля. Хорошо, что вы сократили число пользователей при миграции, хотя не уверен, насколько это существенно.
Понимаю ваше разочарование: ваше тестирование не выявило рассылки дайджестов, которые оказались в очереди. Это привело к периоду фактической недоступности для всех, кто пытался сбросить пароль и восстановить доступ к своим аккаунтам.
Несколько раз выше вы упоминали, что я приписываю вам слова, которых вы не говорили, но, насколько я вижу, мои ответы соответствуют предоставленной вами информации. Извините, если вы не согласны, но перечитав посты, я всё ещё не понимаю, какой именно продукт вы используете.
Кстати, меня зовут @Stephen, а не @Steven — вы тегаете и уведомляете совершенно другого пользователя.
Если так, то не стесняйтесь профинансировать это, опубликовав сообщение в Marketplace с указанием бюджета. Также выше есть несколько отличных предложений
по сокращению объёма электронной почты — рекомендую воспользоваться ими.
На данный момент мы просто полностью отключили дайджесты; вот обновлённая предыстория:
У нас также есть тестовый сервер, и поскольку Discourse по умолчанию включает еженедельные дайджесты (с окном в 365 дней) сразу после установки ( out-of-the-box), на этом тестовом сервере на прошлой неделе тоже запустился дайджест (чего мы не ожидали), LOL
Итак, не зная, что это произойдёт (или может произойти), я попытался сделать резервную копию на тестовом сервере, но система отказалась её выполнять, выдав ошибку. Я забыл точный текст сообщения об ошибке в консоли администратора, но помню, что там была подсказка, указывающая на очередь почты.
С этой подсказкой я посмотрел в sidekiq — и действительно, в очереди находилось более 300 тысяч сообщений дайджестов из-за конфигурации по умолчанию: «включено» и «за последние 365 дней».
Так что я очистил очередь почты через командную строку, снова зашёл в панель администратора резервного копирования, и резервное копирование прошло успешно.
Поскольку почтовая система Discourse построена на sidekiq, именно этим, вероятно, объясняется, почему настройка разных каналов (разных почтовых серверов) для критически важных писем и дайджестов может оказаться непростой задачей. Я вижу, что это не так просто, как я изначально думал (просто настроить два почтовых сервера в окружениях).
А вот самая забавная часть… LOL
Сначала я подумал, что было бы хорошей идеей отключить дайджесты по умолчанию OOTB вместо того, чтобы включать их с окном входа в 365 дней; но потом вспомнил, что ошибка была исключительно моей, и что это не самая удачная идея для публикации на meta, LOL.
При установке Discourse все перенесённые пользователи (с нашего старого форума vB3) по умолчанию получили значение last_seen_at примерно 50 лет назад.
Я зашёл в базу данных и вручную изменил всем пользователям дату последнего посещения на 10 дней назад! LOL. На тот момент я ничего не знал о конфигурации дайджестов и думал, что это ошибка миграции, из-за которой у всех пользователей дата последнего посещения была 50 лет назад. Ха-ха… Я ошибался. Для этого есть веская причина.
Discourse запустил масштабный процесс еженедельного дайджеста, который перегрузил sidekiq на обоих наших серверах: и на рабочем, и на тестовом; потому что я сделал хак с изменением БД «последнее посещение 10 дней назад» на тестовом сервере и экспортировал эти изменения на рабочий сервер. Именно эта ошибка и вызвала данную проблему.
Поскольку большинство людей не заходят в postgres и не делают таких вещей, как:
UPDATE users SET last_seen_at "сегодня минус 10 дней"
… при миграции с устаревшей системы с большим количеством пользователей…
у них не возникнет подобных проблем с огромным количеством дайджестов.
LOL
Приношу извинения за то, что создал всё это напряжение из-за своего хака UPDATE в таблице users.
Тем не менее, я считаю разумным размещать критически важные письма и дайджесты на двух разных почтовых серверах, но, глядя на sidekiq, пока неясно, существует ли простой способ это сделать, так как у меня пока нет опыта работы с sidekiq.
Однако я могу посоветовать тем, кто занимается миграцией: если вы переносите форум на Discourse (что отличная идея), оставьте значение last_seen_at в таблице users по умолчанию ![]()
Обычно я рекомендую размещать Mailhog между тестовым окружением и внешним миром. В таких сценариях он работает отлично.
Я добавлю DISCOURSE_DISABLE _DIGEST _EMAILS на свои тестовые экземпляры. Но с отключением рассылок для не-сотрудников это не является большой проблемой.