Может ли sendmail пересылать электронную почту сразу, а не в очереди?
Часть почты, проходящей через мой сервер, пересылается на внешние учетные записи.
К сожалению, мой вышестоящий SMTP-сервер очень требователен к спаму и отклоняет некоторые легитимные сообщения как таковые. Когда это происходит с перенаправленной почтой, я получаю отскоки (как почтмейстер), а не отправители.
Я понимаю, что это потому, что sendmail ставит сообщения в очередь локально, отключается от ретранслятора и только затем продолжает их пересылку. Если дальнейшая пересылка прерывается по какой-либо причине - например, из-за того, что следующий ретранслятор ошибочно идентифицирует сообщение как спам - мой sendmail оставляется для хранения фрагментов.
Можно ли что-то настроить таким образом, чтобы пересылка начиналась немедленно (как только будет определен пункт назначения пересылки)? Статус - успех или неудача - может быть передан непосредственно на предыдущее реле, все еще находящееся на линии...
Если sendmail не может это сделать, могут ли другие MTA? Спасибо!
2 ответа
Нет, это невозможно, так как оно не реализовано ни с каким распространенным программным обеспечением SMTP; вам придется запрограммировать свой собственный SMTP-сервер, поддерживающий такого рода поведение, которое будет выходить за рамки Serverfault. В этом ответе я объясняю, почему все адаптеры MTA реализовали протокол SMTP очень схожим образом, используя очередь, и как это является наилучшим способом выполнения всех требований протокола.
Агент почтовой транспортировки MTA всегда либо отклоняет сообщение, либо принимает и ставит его в очередь на основе своих собственных настроек. Затем он ретранслируется или доставляется из очереди.
Это потому что
Могут быть как постоянные, так и временные ошибки. Если MTA не может подключиться к следующему переходу немедленно, он попытается позже и отскочит, только если задержка достигнет установленного предела. Также он не может дождаться ответа другого MTA перед закрытием соединения, так как он может иметь другие сообщения для доставки в первую очередь.
может быть несколько получателей. В то время как клиент может просто перечислить всех получателей одновременно с
RCPT TOкомандами, сообщение может быть наконец доставлено на несколько других серверов, некоторые из которых могут быть доступны сейчас, а некоторые позже. Кроме того, MTA не может открыть все эти соединения сразу во время начального соединения и ждать их ответов. Нет практической причины иметь совершенно другой рабочий процесс для сообщений с одним получателем.всегда должно быть ясно, какой MTA в настоящее время несет ответственность за доставку сообщения. (Это было объяснено примерами в ответе MadHatter.)
Вот так был разработан SMTP. Вместо синтаксического требования к командам соединения это приводит к очень похожим архитектурам; Sendmail, Postfix и даже MS Exchange имеют отдельные компоненты для отправки и получения почты.
- Компонент SMTP-сервера получает почту и добавляет ее в очередь.
- Затем отдельный SMTP-клиент пытается отправить его дальше другим MTA, или, если получатель является локальным, сообщение может быть сохранено в файл или передано агенту доставки почты MDA, например, Procmail.
Требование по-прежнему исходит из спецификации SMTP; RFC 5321 2.1 по базовой структуре модели SMTP:
Ожидается, что реализации SMTP с полной поддержкой, включая ретрансляторы, используемые этими менее активными, и их места назначения, будут поддерживать все функции организации очередей, повторных попыток и альтернативных адресов, описанные в этой спецификации. Во многих ситуациях и конфигурациях рассмотренные выше клиенты с меньшей способностью ДОЛЖНЫ использовать протокол передачи сообщений ( RFC 4409), а не SMTP.
И немного дальше:
Другими словами, передача сообщения может происходить в одном соединении между исходным SMTP-отправителем и конечным SMTP-получателем или может происходить в серии переходов через промежуточные системы. В любом случае, после того как сервер отправил ответ об успешном завершении в конце почтовых данных, происходит официальная передача ответственности за сообщение: протокол требует, чтобы сервер ДОЛЖЕН был принять на себя ответственность либо за доставку сообщения, либо за надлежащее сообщение о сбое. сделать это (см. разделы 6.1, 6.2 и 7.8).
Я думаю, что ответ Эсы превосходен, но я собираюсь не согласиться с некоторыми из них. Я думаю, что то, что вы хотите , возможно, но это плохая идея, и она вам не поможет. По его словам, RFC5321 s2.1 отмечает, что
после того как сервер отправил ответ об успешном завершении в конце почтовых данных, происходит официальная передача ответственности за сообщение: протокол требует, чтобы сервер ДОЛЖЕН был принять на себя ответственность либо за доставку сообщения, либо за надлежащее сообщение об отказе сделать это.
В том случае, если сервер B получает сообщение от сервера A и доставляет его на сервер C, я не вижу, чтобы это препятствовало тому, чтобы B ожидал подтверждения получения до A, пока не получило подтверждение получения от C - что вы и делаете просишь. Но проблема в том, что между двумя серверами 250 OK является атомарным (либо получатель принял его, и поэтому отвечает за доставку, либо нет, поэтому отправитель остается ответственным), а между тремя - нет.
Рассмотрим случай, когда клиент А непреднамеренно отключается после отправки письма, но до того, как 250 OK, в то время как B доставляет его на C. C затем подтверждает получение от B своим 250 OK, так что B знает, что у C это есть. Но A этого не делает, поэтому A по-прежнему должен нести ответственность и продолжать передачу к B. Если есть некоторая систематическая проблема связи между A и B (например, один из тех прекрасных брандмауэров, которые считают, что их работа - связываться с содержимым SMTP-разговоров), это может привести к доставке очень большого количества копий одного и того же сообщения.
Более того, sendmail уже делает то, что, по вашему мнению, не делает: в случае неудачной доставки в C он попытается вернуть обратно деньги A. Обычно это происходит только в том случае, когда A является вредоносным, и либо лежит в конверте-From. (кому такое уведомление должно быть сделано) или вообще не запускает почтовый сервер. В таких случаях почта должна быть доставлена почтмейстеру B, так как B отвечает за доставку 250 OK к A, но не получил его от C), не может доставить C (он попробовал и получил постоянный сбой 5xx) и не может передать обратно A (потому что A сделал это невозможным), так что никто больше не может передать его. Вот пример, который я получил этим утром:
Date: Tue, 8 Aug 2017 02:53:55 +0100
From: Mail Delivery Subsystem <MAILER-DAEMON@lory.teaparty.net>
To: mailman-bounces@teaparty.net
Subject: Returned mail: see transcript for details
Parts/Attachments:
1 Shown 17 lines Text
2 Shown 407 bytes Message, "Delivery Status"
3 Shown 15 KB Message
3.1 10 KB Application
----------------------------------------
The original message was received at Tue, 8 Aug 2017 02:53:53 +0100
from localhost [IPv6:::1]
----- The following addresses had permanent fatal errors -----
<redacted@googlemail.com>
(reason: 550-5.7.1 Unauthenticated email from aol.com is not accepted due to domain's)
----- Transcript of session follows -----
... while talking to gmail-smtp-in.l.google.com.:
>>> DATA
<<< 550-5.7.1 Unauthenticated email from aol.com is not accepted due to domain's
<<< 550-5.7.1 DMARC policy. Please contact the administrator of aol.com domain if
<<< 550-5.7.1 this was a legitimate mail. Please visit
<<< 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about the
<<< 550 5.7.1 DMARC initiative. 53si155585wrc.260 - gsmtp
554 5.0.0 Service unavailable
[ Part 2: "Delivery Status" ]
Reporting-MTA: dns; lory.teaparty.net
Received-From-MTA: DNS; localhost
Arrival-Date: Tue, 8 Aug 2017 02:53:53 +0100
Final-Recipient: RFC822; redacted@googlemail.com
Action: failed
Status: 5.7.1
Remote-MTA: DNS; gmail-smtp-in.l.google.com
Diagnostic-Code: SMTP; 550-5.7.1 Unauthenticated email from aol.com is not accepted due to domain's
Last-Attempt-Date: Tue, 8 Aug 2017 02:53:55 +0100
[ Part 3: "Included Message" ]
Date: Tue, 08 Aug 2017 01:53:46 -0000
From: rmusic80proof@aol.com
To: redacted@stphilipschurch.org.uk
[...]
Обратите внимание на то, как оригинальное электронное письмо направлено с адреса aol.com. Как же тогда я не пытаюсь доставить им отчет об ошибках? Потому что они лгали в своей первоначальной SMTP-транзакции:
Aug 8 02:53:51 lory sendmail[9457]: v781rmjA009457: from=<rmusic80proof@stphilipschurch.org.uk>, size=14095, class=0, nrcpts=1, msgid=<150215722683.22237.12283849532100059916@37.114.157.178>, proto=SMTP, daemon=MTA-v6, relay=[37.114.157.178]
Я виноват, что я еще не настроил SPF для этого конкретного домена (stphilipschurch.org.uk), но так как у меня нет, ничто не мешает мне принять эту ложь - и затем я застреваю с недоставленным сообщением, которое не может быть возвращено отправителю, поскольку отправитель злонамеренный и незаинтересованный (будучи подключенным через интернет-провайдера в Азербайджане),
ТЛ; dr: sendmail уже делает то, что вы просите, когда это возможно. То, что вы хотите сделать, не поможет, если не поможет, и создаст проблемы. Не делай этого.