451... reply: read error from mail.ourdomain.com

As of late outside senders are having their emails to us returned with the error below. What’s weird is that it’s sparatic. I’ve confirmed my ISP supports reverse DNS lookup. Thanks in advance for any insight!

451… reply: read error from mail.ourdomain.com.

… Deferred: Connection reset by mail.ourdomain.com.

Message could not be delivered for 3 hours

Message will be deleted from queue

Final-Recipient: RFC822;

Action: failed

Status: 4.4.7

Remote-MTA: DNS;

Diagnostic-Code: SMTP; 451 … reply: read error from xxx@ourdomain.com

Subject: 451… reply: read error from mail.ourdomain.com

perhaps return receipts and or delivery confirmations sent to an MTA having problems delivering to it’s users, ie it’s slow and it’s letting you know?

in your text what is the Reporting-MTA? is it one on your machines, your ISPs or the receipients? because it’s the one that sent the temporary failure message.

from rfc2852;

4.1. Server behavior upon receipt of the extended MAIL FROM command

Upon receipt of an extended MAIL FROM command containing a valid BY parameter, a SMTP server and associated MTA must handle the message in accord with the following subsections, Sections 4.1.1-4.1.5.
Delivery status notifications generated in response to processing a message with a Deliver By request should include both the optional Arrival-Date DSN field as well as the new Deliver-By-Date DSN field described in Section 5 of this memo.

A by-time Note that a message’s by-time does not extend the MTA’s
normal message retention period: an MTA MAY return a message as
undeliverable before the deliver-by-time has been reached.

4.1.1. Successful delivery

If the message is delivered before deliver-by-time, no special action need be taken. If the SMTP server or MTA also supports the Delivery Status Notification SMTP service extension [5] and a NOTIFY parameter including “SUCCESS” was specified, a “delivered” DSN with appropriate status must be returned as per [5].

4.1.2. Unsuccessful delivery; deliver-by-time not yet reached

If deliver-by-time has not yet passed and the message has proved undeliverable for temporary reasons, then the SMTP server or MTA should continue delivery or relay attempts as per the site’s message handling policy. If the MTA’s message retention period is less than by-time, the MTA MAY return the message as undeliverable before deliver-by-time has been reached. However, the message MUST still be handled in accord with Sections 4.1.1-4.1.5.

If deliver-by-time has not yet passed and the message cannot be delivered for permanent reasons, then the SMTP server or MTA MUST return a “failed” DSN with an appropriate status for each recipient address with either no NOTIFY parameter specified or for which the NOTIFY parameter includes “FAILURE”.

4.1.3. Time has expired; deliver-by-time reached or passed

If the message is not delivered or relayed before deliver-by-time and a by-mode of “R” was specified, no further delivery attempts may be made for the message. The server or MTA MUST issue a “failed” DSN with status 5.4.7, “delivery time expired”, for each recipient address with either no NOTIFY parameter specified or for which the NOTIFY parameter includes “FAILURE”.

If the message is not delivered or relayed before deliver-by-time and a by-mode of “N” was specified, the server or MTA should continue attempts to deliver or relay the message using the site’s message handling policy. In addition, the server or MTA MUST issue a “delayed” DSN with status 4.4.7, “delivery time expired”, for each recipient address with either no NOTIFY parameter specified or for which the NOTIFY parameter includes “DELAY”.