Моя система отправляет электронную почту с php с помощью sendmail. Я понимаю, что есть десятки вопросов по обмену стеками о задержках отправки электронной почты из sendmail / php. Я прочитал их все, но все еще не могу решить свою проблему.
У меня есть производственный сервер и сервер разработки. Производство находится в центре обработки данных и использует «умный хост» для ретрансляции своей электронной почты, прямая отправка электронной почты блокируется межсетевым экраном. Разработка находится в нашем офисе и отправляет электронные письма напрямую. Они также используют разные DNS-серверы. Помимо этого, эти серверы настолько похожи, насколько я мог их сделать. Моя система должна отправлять много (около 10 000) электронных писем за раз. Мой сервер разработки может отправлять все электронные письма менее чем за час. Производственная система занимает более 24 часов. Электронные письма имеют размер 2-5 КБ.
На моем производственном сервере:
Я определил, что переход с php на sendmail происходит быстро. Sendmail медленно отправляет электронные письма в некоторые домены. Крупные почтовые службы (Gmail, AOL, Yahoo) работают быстро. Я попытался отправить 1000 писем только на адреса AOL, и все они были отправлены в течение пары минут, поэтому я знаю, что реле способно быстро отправлять электронные письма. Моя проблема в том, что большинство адресов электронной почты в моем списке адресов относятся к небольшим доменам, и большинство из них работают медленно. Это наводит меня на мысль, что медленный шаг связан с DNS. Вот выдержка из моего файла почтового журнала (значения в {фигурных скобках} заменены в целях конфиденциальности).
Mar 28 11:21:47 {servernamereplaced} sendmail[26242]: v2SILe8w026242: to={usernamereplaced@domain1replaced.net}, ctladdr={customfromaddress@notmydomain.com} (48/48), delay=00:00:07, xdelay=00:00:00, mailer=relay, pri=32561, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (v2SILlIu026244 Message accepted for delivery)
Mar 28 11:22:08 {servernamereplaced} sendmail[26247]: v2SILmT8026247: to={usernamereplaced@domain2replaced.net}, ctladdr={customfromaddress@notmydomain.com} (48/48), delay=00:00:20, xdelay=00:00:10, mailer=relay, pri=32550, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (v2SILwOh026248 Message accepted for delivery).
Вы можете видеть, что по ним есть большие задержки. Однако когда я бегу host -t mx domain1replaced.net Я получаю результат очень быстро (меньше полсекунды и ровно столько, сколько gmail.com или aol.com).
Я видел некоторые ответы, в которых упоминались значения тайм-аута в sendmail.cf, однако я недостаточно знаю об этом файле, чтобы заниматься самостоятельно. Кроме того, значения задержки не все одинаковы или кратны одному и тому же числу. Кажется, что они довольно разбросаны между 5 и 30 секундами. Меня поразило то, что мой сервер разработки отправляет их так быстро, но я не могу заставить свой рабочий сервер делать то же самое. Что я могу сделать, чтобы ускорить работу моего рабочего сервера?
Приступим к анализу журнала sendmail, особенно delay и xdelay. Из Вот:
задержка: Общая задержка сообщения: разница во времени между приемом и окончательной доставкой или возвратом). Формат: delay = HH: MM :: SS для задержки менее одного дня и delay = days + HH: MM :: SS в противном случае.
xdelay: Общее время, которое потребовалось для передачи сообщения во время окончательной доставки. Это отличается от delay = equate тем, что xdelay = equate учитывает только время фактической окончательной доставки.
Чтобы лучше подчеркнуть разницу между задержкой / xdelay (взято из Вот):
Это отличается от delay = тем, что delay = показывает общее количество времени, которое заняло сообщение, вычисленное с момента, когда сообщение было первоначально получено или поставлено в очередь (это могло быть несколько дней назад), до тех пор, пока оно в конечном итоге не было доставлено. В случае почты SMTP xdelay = вычисление начинается, когда sendmail пытается подключиться к удаленному хосту.
В ваших журналах отображается следующая задержка / xdelay:
delay=00:00:07, xdelay=00:00:00: это сообщение ждало 7 секунд в очереди sendmail еще до того, как передача smtp была обработана. Это признак перегруженности сервера, а не проблем с подключением / DNS: в конце концов, фактический перенос был выполнен почти мгновенно;
delay=00:00:20, xdelay=00:00:10: на этот раз сообщение застряло в очереди sendmail на 10 секунд, а сам инструмент передачи еще на 10 секунд. Исходя из репутации вашего сервера, это может быть очень разумным значением: многие почтовые серверы задерживают HELO / EHLO на 5-30 секунд из-за неизвестных нейтральных отправителей.
Итак, почему тестовая машина намного быстрее вашей производственной? Вот несколько возможностей:
fsync() интенсивная работа. Ваши серверы разработки и производства? действительно то же самое, аппаратное и программное? А как насчет аппаратного и программного стека smarthost?Проблема может быть не в том, что вы выполняете DNS-запросы локально, а в удаленных концах. Когда ваш SMTP-сервер A отправляет на SMTP-сервер B, сервер B (может) выполнять запрос PTR на IP-адресе A, а затем прямой запрос на возвращенное имя, чтобы убедиться, что они совпадают. Если какой-либо из этих DNS-запросов выполняется медленно, это может объяснить ваши наблюдения.
Я предполагаю, что если вы отправите еще одно электронное письмо на адрес, который раньше был медленным, он все равно будет медленным во второй раз. Если это так, я бы попробовал использовать telnet на вашем почтовом сервере для подключения к удаленному почтовому серверу и отправить тестовое электронное письмо таким образом. Я отсеял несколько проблем, связанных с задержкой, в прошлом с помощью этого метода. Иногда это может помочь точно определить, какой шаг в процессе коммуникации задерживает ситуацию.
Достойная рецензия на рассылку по telnet:
https://weblogs.asp.net/owscott/Troubleshooting-email_2C00_-the-Telnet-way
Отправка электронной почты на 100 доменов всегда будет медленнее, чем отправка электронной почты 100 пользователям в одном домене из-за повторного использования соединения (postfix ведет журнал количества использованных соединений). Для подогрева IP-адресов и оптимизации скорости отправки для каждого домена требуется много работы. . Если вы добавите tls в микс, вы также потеряете параметры повторного использования соединения, поскольку каждое электронное письмо создает соединение (сборки tcp + tls плюс ограничения скорости получателя)
если у вас нет или вы хотите потратить время на создание репутации и ограничение скорости настройки, вам следует оценить сторонние варианты.