kwhite1 Absent Member.
Absent Member.
1154 views

Deferred Message Timeout

The Default is 4 days for a Deferred Message Timeout in GroupWise. My questions are: Is this an RFC standard? I have been asked to shorten, Have other GroupWise shops shortened the Deferred Message Timeout?

Thanks
Labels (2)
0 Likes
2 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Deferred Message Timeout

On 4/6/2012 7:30 AM, Kirk White wrote:
> The Default is 4 days for a Deferred Message Timeout in GroupWise. My
> questions are: Is this an RFC standard? I have been asked to shorten,
> Have other GroupWise shops shortened the Deferred Message Timeout?
> Thanks

It's mostly recommendations in RFC 2821
but they recommend 4-5 days

4.5.4.1. Sending Strategy

The general model for an SMTP client is one or more processes that
periodically attempt to transmit outgoing mail. In a typical system, the
program that composes a message has some method for requesting immediate
attention for a new piece of outgoing mail, while mail that cannot be
transmitted immediately MUST be queued and periodically retried by the
sender. A mail queue entry will include not only the message itself but
also the envelope information.

The sender MUST delay retrying a particular destination after one
attempt has failed. In general, the retry interval SHOULD be at least 30
minutes; however, more sophisticated and variable strategies will be
beneficial when the SMTP client can determine the reason for non-delivery.

Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. The
parameters to the retry algorithm MUST be configurable.

A client SHOULD keep a list of hosts it cannot reach and corresponding
connection timeouts, rather than just retrying queued mail items.

Experience suggests that failures are typically transient (the target
system or its connection has crashed), favoring a policy of two
connection attempts in the first hour the message is in the queue, and
then backing off to one every two or three hours.

The SMTP client can shorten the queuing delay in cooperation with the
SMTP server. For example, if mail is received from a particular address,
it is likely that mail queued for that host can now be sent. Application
of this principle may, in many cases, eliminate the requirement for an
explicit "send queues now" function such as ETRN [9].

The strategy may be further modified as a result of multiple addresses
per host (see below) to optimize delivery time vs. resource usage.

An SMTP client may have a large queue of messages for each unavailable
destination host. If all of these messages were retried in every retry
cycle, there would be excessive Internet overhead and the sending system
would be blocked for a long period. Note that an SMTP client can
generally determine that a delivery attempt has failed only after a
timeout of several minutes and even a one-minute timeout per connection
will result in a very large delay if retries are repeated for dozens, or
even hundreds, of queued messages to the same host.

At the same time, SMTP clients SHOULD use great care in caching negative
responses from servers. In an extreme case, if EHLO is issued multiple
times during the same SMTP connection, different answers may be returned
by the server. More significantly, 5yz responses to the MAIL command
MUST NOT be cached.

When a mail message is to be delivered to multiple recipients, and the
SMTP server to which a copy of the message is to be sent is the same for
multiple recipients, then only one copy of the message SHOULD be
transmitted. That is, the SMTP client SHOULD use the command sequence:
MAIL, RCPT, RCPT,... RCPT, DATA instead of the sequence: MAIL, RCPT,
DATA, ..., MAIL, RCPT, DATA. However, if there are very many addresses,
a limit on the number of RCPT commands per MAIL command MAY be imposed.
Implementation of this efficiency feature is strongly encouraged.

Similarly, to achieve timely delivery, the SMTP client MAY support
multiple concurrent outgoing mail transactions. However, some limit may
be appropriate to protect the host from devoting all its resources to mail.

===========

0 Likes
Knowledge Partner
Knowledge Partner

Re: Deferred Message Timeout

In article <4F7EC5C5.8D84.00CF.1@no-mx.forums.novell.com>, Kirk White
wrote:
> ..Have other GroupWise shops shortened the Deferred Message Timeout?
>

I have on some occasions, but never less than 2 days (though others
have argued for less). The debate sides are: how long do you want the
messages to try to go through before they give up and tell the user the
message has failed. Vs. How long might a target mail system be off
line for maintenance, upgrades, icestorms/hurricanes, etc....
Once upon a time (i.e. when those RFCs were first written) full time
internet connections weren't as common as they are now and it was a
common enough practice to be connected for just a few hours a day, and
it wasn't such a big deal if mail was done for a couple of days.

The other related thing I do is to adjust the "intervals to retry a
deferred message from the default (20,20,20,60) to 5,10,20,20,60,120 to
better reflect that many deferreds are due to either grey listing or
very transient outages along the path.



Andy Konecny
KonecnyConsulting.ca in Toronto
-----------------------------------------------------------------------
Andy's Profile: http://forums.novell.com/member.php?userid=75037


___
Andy of Konecny Consulting in Toronto
Knowledge Partner Profile
If you find a post helpful, click the Like button below. Thanks!
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.