Часть электронной почты, проходящей через мой сервер, пересылается на внешние учетные записи.
К сожалению, мой вышестоящий SMTP-сервер очень требователен к спаму и отклоняет некоторые легитимные сообщения как таковые. Когда это происходит с пересылаемой почтой, я получаю отказы (как почтмейстер), а не отправителей.
Я понимаю, что это связано с тем, что sendmail помещает сообщения в очередь локально, отключается от ретранслятора и только после этого пересылает их дальше. Если дальнейшая пересылка прерывается по какой-либо причине - например, из-за того, что следующий ретранслятор ошибочно идентифицирует сообщение как спам, - моя sendmail остается, чтобы держать части.
Можно ли настроить так, чтобы началась пересылка немедленно вместо этого (как только будет определен пункт назначения)? Статус - успех или неудача - может быть передан непосредственно предыдущему реле. все еще на связи...
Если sendmail не может этого сделать, могут ли другие MTA? Спасибо!
Нет, это невозможно, так как это не реализовано ни в одном широко распространенном программном обеспечении SMTP; вам нужно будет запрограммировать свой собственный SMTP-сервер, который поддерживает такое поведение, что будет вне области действия Serverfault. В этом ответе я объясню, почему все MTA реализовали протокол SMTP очень похоже, используя очередь, и как это лучший способ выполнить все требования протокола.
А агент по транспортировке почты MTA всегда либо отклоняет сообщение, либо принимает его и ставит в очередь в соответствии со своими настройками. Затем он ретранслируется или доставляется из очереди.
Это потому что
могут быть как постоянные, так и временные ошибки. Если MTA не может немедленно подключиться к следующему магазину, он попытается повторить попытку позже и отскакивает, только если задержка достигает установленного предела. Он также не может ждать ответа от другого MTA, прежде чем закрыть соединение, так как у него могут быть другие сообщения, которые нужно доставить первыми.
получателей может быть несколько. В то время как клиент может просто перечислить всех получателей сразу с помощью RCPT TO команд, сообщение может быть наконец доставлено на несколько других серверов, некоторые из которых могут быть доступны сейчас, а некоторые позже. Более того, MTA не может открыть все эти соединения сразу во время первоначального соединения и дождаться их ответов. Нет никакой практической причины использовать совершенно другой рабочий процесс для сообщений с одним получателем.
всегда должно быть ясно, какой MTA в настоящее время несет ответственность за доставку сообщения. (Это было объяснено примерами в ответе MadHatter.)
Именно так был разработан SMTP. Вместо синтаксических требований для команд подключения это приводит к очень похожему архитектуры; Отправить почту, Постфикс и даже MS Exchange имеет отдельные компоненты для отправки и получения почты.
Требование по-прежнему исходит из спецификации 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 является атомарным (либо получатель принял его и поэтому отвечает за доставку, либо нет, и поэтому отправитель остается ответственным), а между тремя - нет.
Рассмотрим случай, когда клиент A непреднамеренно отключен после того, как он отправил письмо, но до того, как он получил 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), но так как я этого не сделал, ничто не мешает мне принять эту ложь - и тогда я застрял с недоставленным сообщением, которое не может быть возвращено отправителю, поскольку отправитель злонамерен и незаинтересован (подключение через интернет-провайдера в Азербайджане) .
tl; доктор: sendmail уже делает то, о чем вы просите, когда может. То, что вы хотите сделать, не поможет, когда не может, и создаст проблемы. Не делай этого.