sendmailは、キューに入れる代わりにすぐに電子メールを転送できますか？
サーバーを通過する電子メールの一部は、外部アカウントに転送されます。
残念ながら、私のアップストリームSMTPサーバーはスパムに非常に敏感であり、正当なメッセージの一部をそのように拒否します。転送されたメールにこれが発生すると、発信者ではなく、（ポストマスターとして）バウンスが発生します。
これは、sendmailがメッセージをローカルでキューに入れ、リレーから切断してから、さらに転送するためであると理解しています。次のリレーがメッセージをスパムと誤認したなどの理由でそれ以上の転送が中断した場合、私のsendmailは断片を保持するために残されます。
転送が開始されるように構成できますかすぐに代わりに（転送先が決定されるとすぐに）？ステータス（成功または失敗）は、前のリレーに直接伝達できますまだ回線上にあります .. ..
Sendmailがそれを実行できない場合、他のMTAは実行できますか？ありがとう！
いいえ、広く普及している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実装は、この仕様で説明されているすべてのキューイング、再試行、および代替アドレス機能をサポートすることが期待されます。多くの状況と構成では、上記で説明した機能の少ないクライアントは、SMTPではなくメッセージ送信プロトコル（ RFC 4409 ）を使用する必要があります。
そしてもう少し：
つまり、メッセージ転送は、元のSMTP送信者と最終的なSMTP受信者の間の単一の接続で発生するか、中間システムを介した一連のホップで発生する可能性があります。いずれの場合も、サーバーがメールデータの最後に成功応答を発行すると、メッセージに対する責任の正式なハンドオフが発生します。プロトコルでは、サーバーがメッセージを配信するか、失敗を適切に報告する責任を受け入れる必要があります。そうしてください（セクション6.1、6.2、および7.8を参照）。
エサの答えは素晴らしいと思いますが、私はそれのいくつかに反対するつもりです。私はあなたが望むことは可能だと思いますis可能ですが、それは悪い考えであり、それはあなたを助けません。彼が言うように、RFC5321s2.1は次のように述べています。
サーバーがメールデータの最後に成功応答を発行すると、メッセージに対する責任の正式なハンドオフが発生します。プロトコルでは、サーバーがメッセージの配信またはその失敗を適切に報告する責任を受け入れる必要があります。
サーバーBがサーバーAからメッセージを受信し、それをサーバーCに配信する場合、Cからの受信の確認が完了するまで、BがAへの受信の確認を待機するのを妨げることはありません。 'を求めています。しかし、問題は、2つのサーバー間で250 OKがアトミックである（受信者がそれを受け入れて配信を担当するか、そうでないため送信者が引き続き責任を負う）のに対し、3つのサーバー間ではアトミックではないことです。 t。
クライアントAがメールを送信した後、250 OKを受信する前に、BがCにメールを配信しているときに、意図せずに切断された場合を考えてみます。Cは、Bからの受信を250 OKで確認します。 BはCがそれを持っていることを知っています。しかし、Aはそうではないので、Aは引き続き責任を負い、Bに再配信し続ける必要があります。AとBの間に体系的な通信の問題がある場合（たとえば、コンテンツを台無しにするのが彼らの仕事だと考える素敵なファイアウォールの1つ） SMTP会話の場合）、これにより、同じメッセージのコピーが非常に多数配信される可能性があります。
さらに、sendmailは、あなたが思っていることをすでに実行しています。Cへの配信に失敗した場合、Aに返金しようとします。これは通常、Aが悪意のある場合にのみ失敗し、エンベロープ内にあります-From （そのような通知を行う必要がある相手）またはメールサーバーをまったく実行していません。このような場合、メールmustはBのポストマスターに配信されます。これは、Bが配信に責任があるため（Aに250 OKと言ったが、Cからは配信されなかった）、Cに配信できないためです（ 5xxの永続的な失敗を試みて取得しました）、Aに戻すことができないため（Aがこれを不可能にしたため）、他に誰もそれを与えることができません。これが私が今朝得た例です：
Date: Tue, 8 Aug 2017 02:53:55 +0100
From: Mail Delivery Subsystem <[email protected]>
To: [email protected]
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 -----
<[email protected]>
(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; [email protected]
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: [email protected]
To: [email protected]
[...]
元の電子メールがaol.comアドレスから送信されたと主張していることに注意してください。では、どうすれば障害レポートを返送しようとしないのでしょうか。彼らは元のSMTPトランザクションに嘘をついたので：
Aug 8 02:53:51 lory sendmail[9457]: v781rmjA009457: from=<[email protected]>, size=14095, class=0, nrcpts=1, msgid=<[email protected]>, proto=SMTP, daemon=MTA-v6, relay=[37.114.157.178]
私の特定のドメイン（stphilipschurch.org.uk）にSPFをまだ設定していないのは私のせいですが、設定していないので、その嘘を受け入れるのを妨げるものは何もありません-そして、私は配達不能で立ち往生しています送信者が悪意があり、関心がないため（アゼルバイジャンのISP経由で接続されているため）、送信者に返すことができないメッセージ。
tl; dr：sendmailは、可能な場合、あなたが求めていることをすでに実行しています。あなたがやりたいことは、それができないときにそれを助けません、そして問題を引き起こします。それをしないでください。