Periodic SMTP 451 4.4.2 errors
barkley bees
errors for particular external recipients. The strange thing is that it will
appear in the logs every so often but at other times mails can be
successfully sent these particular recipients. I can do a telnet SMTP to
their mail host no problem (220). Any ideas? Thank you.
"451_4.4.2_Bad_connection_(io_timeout)"
Rich Matheisen [MVP]
Are you being grey listed? Is your retry interval short enough so you
aren't repeatedly grey listed on every retry?
--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:h.p...@getronics.com
Or to these, either: mailto:h.p...@pinkroccade.com mailto:melvin.mcp...@getronics.com mailto:melvin.mcp...@pinkroccade.com
barkley bees
an industry standard for SMTP timeout? Any real problem with setting the
timeout to 120 or 240 seconds (max smtp sessions aside).
"Rich Matheisen [MVP]" <rich...@rmcons.com.NOSPAM.COM> wrote in message
news:755iq31c6dbiqt86b...@4ax.com...
barkley bees
------------------------------------------------------------------
4.5.3.2 Timeouts
An SMTP client MUST provide a timeout mechanism. It MUST use per-
command timeouts rather than somehow trying to time the entire mail
transaction. Timeouts SHOULD be easily reconfigurable, preferably
without recompiling the SMTP code. To implement this, a timer is set
for each SMTP command and for each buffer of the data transfer. The
latter means that the overall timeout is inherently proportional to
the size of the message.
Based on extensive experience with busy mail-relay hosts, the minimum
per-command timeout values SHOULD be as follows:
Initial 220 Message: 5 minutes
An SMTP client process needs to distinguish between a failed TCP
connection and a delay in receiving the initial 220 greeting
message. Many SMTP servers accept a TCP connection but delay
delivery of the 220 message until their system load permits more
mail to be processed.
MAIL Command: 5 minutes
RCPT Command: 5 minutes
A longer timeout is required if processing of mailing lists and
aliases is not deferred until after the message was accepted.
DATA Initiation: 2 minutes
This is while awaiting the "354 Start Input" reply to a DATA
command.
Data Block: 3 minutes
This is while awaiting the completion of each TCP SEND call
transmitting a chunk of data.
DATA Termination: 10 minutes.
This is while awaiting the "250 OK" reply. When the receiver gets
the final period terminating the message data, it typically
performs processing to deliver the message to a user mailbox. A
spurious timeout at this point would be very wasteful and would
typically result in delivery of multiple copies of the message,
since it has been successfully sent and the server has accepted
responsibility for delivery. See section 6.1 for additional
discussion.
An SMTP server SHOULD have a timeout of at least 5 minutes while it
is awaiting the next command from the sender.
------------------------------------------------------------------
Sorry for the e-redundancy.
"barkley bees" <bark...@nomail.com> wrote in message
news:eBMs0mSa...@TK2MSFTNGP03.phx.gbl...
Rich Matheisen [MVP]
>Our SMTP timeout is set to 60 seconds so perhaps this is too short.
You mean you only wait 60 seconds for an answer to HELO\EHLO, or for
an answer to RCPT TO, MAIL FROM, DATA, etc?
If the answer is "yes" then, yeah, 60 seconds is way too short.
>Is there
>an industry standard for SMTP timeout?
RFC821.
>Any real problem with setting the
>timeout to 120 or 240 seconds (max smtp sessions aside).
No. It was set to 600 (I think) when you installed the system.
But I wasn't asking about how long you wait for an answer, I was
asking how long after you get a retryable error you retry the
operation.