0 votes
by (420 points)


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,
>,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

Applies to: Rebex Secure Mail
by (144k points)
Hello, is this a client-side log or a server-side log?
by (420 points)
the log is from SMTP server

1 Answer

0 votes
by (144k points)

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.