Почему не всем сотрудникам приходят расчетные листки при массовой рассылке из 1С через Gmail?

← На главную

Ситуация, когда массовая рассылка расчетных листков из 1С «теряет» часть адресатов, является классической проблемой при интеграции учетных систем с публичными почтовыми сервисами. Особенно остро это проявляется при использовании 1С на операционных системах семейства Linux (Ubuntu) и почтового сервера Google (Gmail/Google Workspace). Разберем пошагово, почему это происходит, как диагностировать скрытые ошибки и какие стратегии помогут гарантировать доставку каждого листка.

Выясним причину: почему письма исчезают без ошибок в 1С?

Проанализируем типичное поведение системы: бухгалтер запускает рассылку на 80 и более сотрудников. В Журнале регистрации 1С все записи выглядят успешными («Почта отправлена»), однако часть сотрудников утверждает, что ничего не получила. Техподдержка Google при этом заявляет, что со стороны сервера ошибок нет.

Корень проблемы заключается в алгоритмах защиты Google SMTP Relay от DoS-атак и спама. Когда 1С (особенно на мощном сервере Ubuntu) начинает генерировать и отправлять десятки писем за доли секунды, защитные механизмы Google воспринимают это как подозрительный всплеск активности. Происходит так называемый «silent drop» — сервер может принять соединение, но не поставить письмо в очередь на дальнейшую отправку, либо разорвать сессию без внятного уведомления клиента, если превышена частота запросов в секунду.

Настройка диагностики: где искать истинные логи?

Стандартный ЖурналРегистрации в 1С фиксирует только факт передачи команды почтовому клиенту. Для детального анализа на сервере Ubuntu нам потребуется настроить Технологический журнал (ТЖ). Только там можно увидеть протокол общения SMTP-клиента 1С с сервером Google.

Создадим файл конфигурации logcfg.xml в каталоге /opt/1cv8/conf/ (или в соответствующем каталоге вашей версии платформы) со следующим содержанием:


<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
  <log location="/var/log/1c/logs/mail" history="72">
    <event>
      <eq property="Name" value="MAIL"/>
    </event>
    <property name="All"/>
  </log>
</config>

После активации ТЖ проанализируем файлы логов. В них мы сможем увидеть ответы сервера Google, такие как 421 4.7.0 Try again later или 450 4.2.1 The user you are trying to contact is receiving mail at a rate that prevents additional messages from being delivered. Если вы видите подобные записи, значит, проблема точно на стороне лимитов интенсивности отправки.

Решение №1: Реализация паузы и пакетной отправки

Рассмотрим самый простой архитектурный способ решения — искусственное замедление процесса. Google требует «прогретых» соединений или хотя бы разумных интервалов. Если используется типовая рассылка, попробуем разбить список сотрудников на группы по 10–15 человек с интервалом в несколько минут.

Однако более эффективно будет внедрить программную задержку, если вы используете собственную обработку. Рассмотрим пример кода на встроенном языке 1С:


Профиль = Новый ИнтернетПочтовыйПрофиль;
// Настройки профиля (сервер, порт, логин, пароль)
// ...

Почта = Новый ИнтернетПочта;
Почта.Подключиться(Профиль);

Счетчик = 0;
Для Каждого Получатель Из СписокСотрудников Цикл
    Письмо = Новый ИнтернетПочтовоеСообщение;
    // Формирование письма и вложение расчетного листка
    // ...
    
    Почта.Послать(Письмо);
    Счетчик = Счетчик + 1;
    
    // Делаем паузу каждые 5 писем на 2 секунды, чтобы не злить фильтры Google
    Если Счетчик % 5 = 0 Тогда
        Приостановить(2); 
    КонецЕсли;
КонецЦикла;

Почта.Отключиться();

Решение №2: Контроль доставки через скрытую копию (BCC)

Проанализируем ситуацию: как бухгалтеру понять, что письмо действительно ушло, не опрашивая 80 человек? Проверенным методом является использование технического почтового ящика в скрытой копии.

Создаем отдельный почтовый ящик (например, archive_zp@vash-domen.ru).
В настройках рассылки или в коде формирования письма добавляем этот адрес в поле СкрытыеКопии (BCC).
При массовой отправке каждое письмо, успешно принятое сервером Google, придет и на этот технический ящик.

Если в ЖурналеРегистрации 1С стоит статус «Успешно», но на техническом ящике письма нет — значит, Google отклонил его на этапе приема. Это дает четкий инструмент контроля для расчетчиков.

Решение №3: Использование локального релея (Postfix) на Ubuntu

Для системных администраторов, работающих с 1С на Linux, это наиболее профессиональное решение. Проблема 1С в том, что она пытается быть почтовым клиентом, но делает это синхронно. Если соединение с Google обрывается, 1С не умеет «досылать» письма позже.

Разберем схему с использованием Postfix в качестве локального ретранслятора:

На сервере с Ubuntu устанавливается и настраивается postfix.
1С настраивается на отправку почты на localhost (без шифрования и авторизации, так как это внутренний трафик).
1С мгновенно отдает все 80-100 писем локальному сервису Postfix. Для 1С задача завершена успешно за 1-2 секунды.
Postfix, являясь полноценным почтовым сервером (MTA), ставит письма в очередь и сам взаимодействует с Google.
Если Google отвечает «подождите», Postfix автоматически сделает повторную попытку через время, соблюдая все таймауты и лимиты.

Это полностью снимает нагрузку с 1С и гарантирует доставку писем даже при временных проблемах со связью или лимитами сервера Google.

Особенности 1С на Linux и OpenSSL

Важно помнить, что 1С на Ubuntu использует системные библиотеки OpenSSL для работы с шифрованным соединением (TLS/SSL). Убедитесь, что ваша версия платформы (в данном случае 8.3.18) корректно работает с актуальными требованиями безопасности Google. Иногда помогает принудительное указание версии протокола в настройках профиля ИнтернетПочтовыйПрофиль, если используются современные дистрибутивы Ubuntu с жесткими политиками TLS.

Рассмотрим ситуацию с таймаутами. В настройках почтового профиля 1С по умолчанию стоит таймаут 30 секунд. При массовой рассылке на медленных каналах или при задержках со стороны Google этого может быть недостаточно. Рекомендуется увеличить Таймаут в объекте ИнтернетПочтовыйПрофиль до 60 или 120 секунд, чтобы дать системе дождаться ответа от сервера после передачи тяжелого вложения (PDF-листка).

Таким образом, комбинируя программные паузы, использование локального почтового релея и внедрение системы контроля через скрытые копии, мы можем превратить нестабильную рассылку в надежный инструмент, работающий без участия программиста каждый месяц.