Здесь есть несоответствие между заголовками сообщения, данными DNS и результатом тестирования.
1. "DKIM record not found" не подтверждается. Селектор DKIM в сообщении тот же, что опубликован в DNS.
2. No connectable MX не подтверждается.
Или сервис тестирования имел проблемы с подключением к вашем серверу, или записи DNS уже после тестирования исправили. Нужно смотреть заголовки реального сообщения, помеченного как спам. Не сервисом тестирования, а реальным спам фильтром Яндекса, Gmail, и т.п..
Вы пишите что на сервере стоит плагин acymailing. Если Вы его используете по назначению, то шлете "newsletter". Так вот этот "newsletter" и его список рассылки и нужно смотреть: подписывались ли на него получатели? Есть ли у них возможность отписаться в один шаг? Желательно ли для них содержимое "newsletter"? Не отмечают ли они письмо как спам? Нет ли в "newsletter" ссылок, на которые срабатывает спам фильтр, основанный на доменных черных списках?
И Вас есть уверенность, что на Gmail Вы отправляете письма посредством IPv4? Если на отправляющем сервере настроен IPv6, то в Gmail почта пойдет посредством IPv6. А для IPv6 у вас нет DNS записей.
1. добавить в /etc/mail/trusted-users (ну или где у вас этот файл) пользователя www-data
2. проверить, что в sendmail.mc / sendmail.cf установлены опции:
FEATURE(`use_ct_file')
define(`confCT_FILE', `/etc/mail/trusted-users')
3. исправить и сгенерить, если нужно, sendmail.cf
4. добавить FEATURE(use_ct_file) в файл submit.mc, сгенерить новый submit.cf
5. перезапустить sendmail
Если предположить, что в программе нет явных ошибок - зацикливаний, переходов на неожиданные ветки алгоритма, вызовов неожиданных методов и т.п., то величина лага 200 мс более характерна не для операций, связанных с процессором и памятью, а для дисковых операций. Откуда могут быть дисковые операции при проходе по массиву и формировании еще одного? Это может быть при операциях, связанных со свопом. При этом обращаться к нему может не обязательно сам скрипт. А, например, даже сборщик мусора. У вас 2Г памяти помечено как свободная, и занят 1Г свопа. Вся потенциально свободная память у вас в "buff/cache". Память отдана явно php-fpm или mysql? Тогда у вас реально мало свободной памяти, и идет активный своп. Или buff/cache это просто дисковый кэш, который сама система выбирает? Я бы начал расследование с исключения ситуации, что возникает своп. Объем памяти позволяет его вообще не использовать. Можно на лету уменьшить параметр swappiness, новое значение будет действовать до перезагрузки или его очередного изменения. Текущий занятый своп это не уменьшит, но количество новых операций свопа будет существенно снижено.
echo 1 > /proc/sys/vm/swappiness
Если не будет эффекта, можно вернуться к старому значению:
echo 60 > /proc/sys/vm/swappiness
И вот еще я обратил внимание, что у вас гигабайт свопа занят, притом что свободной памяти много. Даже очень много. Что у вас выдает команда sysctl vm.swappiness ?
А вы можете как-то измерить, или хотя бы прикинуть, сколько в этот момент других параллельных процессов php-fpm выполняется? Нет ли у вас в этот момент чего-нибудь интересного в логах php-fpm? Каталог типа /var/log/php-fpm.
Hint, а Вы же прямо на продуктиве эксперименты делаете, так? И он у вас нагруженный, судя по всему, так? А на ненагруженном тестовом сервере ситуация повторяется?
Алексей,
Как верно заметил wisgest, так положено, чтобы проверялся Return-Path. Однако что там на самом деле проверяется, мы не знаем. Так же и пользователь может увидеть разное в "ОТ": "от имени", "on behalf of", или просто "От".
Если в /etc/sysconfig/iptables вы видите только одну строку, то, получается, у вас это единственное правило iptables. Значит, должно быть достаточно одной строки в firewall.sh. Выполнение второй команды вообще должно ошибку выдать, поэтому ее вероятно и нет в /etc/sysconfig/iptables.
Могу сказать что метод проверки рекомендован самим Яндексом. Но их же собственные IP адреса не проходят проверку. Здесь вполне уместно было бы обратиться в Яндекс.
Андрей, IgorNoskov, Крон, который запускается ровно раз в минуту, также как и крон, который запускается раз в 30 секунд, нужно дорабатывать. Потому что кроном гарантируется запуск задачи в определенное время с точностью до минут. Однако секунды могут быть любые в рамках этой минуты. Особенно это заметно если задания стартуют часто и их много. Чтобы нужная программа гарантировано заработала скажем ровно в 11 минут и 0 секунд, ее нужно запустить по крону в 10 минут, проспать скажем 1-2 с., затем спать в цикле и ждать пока наступит 0 с, затем выполнять что надо. Таким же образом делается запуск в 30 с или любое другое количество с.
1. "DKIM record not found" не подтверждается. Селектор DKIM в сообщении тот же, что опубликован в DNS.
2. No connectable MX не подтверждается.
Или сервис тестирования имел проблемы с подключением к вашем серверу, или записи DNS уже после тестирования исправили. Нужно смотреть заголовки реального сообщения, помеченного как спам. Не сервисом тестирования, а реальным спам фильтром Яндекса, Gmail, и т.п..