503 error while sending data to SMTP server

Question

Hi,

We have received 503 error while sending data to SMTP server as shown in the logs below:

....
<,BDAT 98304,
*,Tarpit for '0.00:00:05',
>,"250 2.6.0 CHUNK received OK, 98304 octets",
<,BDAT 98304,
*,,Message or connection acked with status Fail and response 451 4.4.0 SMTPSEND.SendingError; Error while sending message
*,Tarpit for '0.00:00:05',
>,451 4.7.0 Temporary server error. Please try again later. PRX5 ,
*,,InternetMessageId: <abc@abc123>
<,BDAT 83610 LAST,
*,Tarpit for '0.00:00:05' due to '503 5.5.1 Bad sequence of commands',
>,503 5.5.1 Bad sequence of commands,
<,RSET,
>,250 2.0.0 Resetting,

We wanted to know

1. If rebex received error then why it is trying to send more data.
   RFC ref: https://tools.ietf.org/html/rfc3030#section-2
   "A 250 response MUST be sent to each successful BDAT data block within
   a mail transaction. If a failure occurs after a BDAT command is
   received, the receiver-SMTP MUST accept and discard the associated
   message data before sending the appropriate 5XX or 4XX code. If a
   5XX or 4XX code is received by the sender-SMTP in response to a BDAT
   chunk, the transaction should be considered failed and the sender-
   SMTP MUST NOT send any additional BDAT segments. If the receiver-
   SMTP has declared support for command pipelining [PIPE], the receiver
   SMTP MUST be prepared to accept and discard additional BDAT chunks
   already in the pipeline after the failed BDAT."

2. If there are 4yz errors is their any retry mechanism Rebex provides.
   RFC Ref: https://tools.ietf.org/html/rfc5321#section-4.2.1
   4yz Transient Negative Completion reply

Comments

Hello, is this a client-side log or a server-side log?

---

the log is from SMTP server

Answer 1

1. Rebex SMTP does not send additional BDAT chunks once it receives an error response to one of them. However, a server-side log doesn't show how things look like from the client-side due to communication latency. In this case, the SMTP client used chunking and pipelining (RFC 2920) together, which means it was permitted to send multiple BDAT chunks without waiting for the server response to each of them. And it actually managed to send all the chunks before it received the error response by which the server rejected one of them.

2. Rebex SMTP doesn't provide any retry mechanism of its own. This is outside the scope of Rebex Secure Mail. A robust retry mechanism would have to operate reliably even if the application has terminated and restarted, which means some kind of permanent storage for outgoing messages would be needed, and it's not a responsibility of a SMTP client library to provide that.

---

Also, last but not least - it looks like your Rebex subscription has already expired. Please consider renewing it to enjoy continued Rebex support.