>I don't disagree with you entirely Paul.  However, LSOFT is adding to the
>bad Date and time header by incorrectly replacing the time stamp sith 6
>zero's 00:00:00 (...) So in theory yes blackberry needs to fix their
>timestamp but also LSOFT needs to stop making an assumption and creating a
>hard error to the timestamp.

You are right that the CORRECT behaviour would be for LISTSERV to discard
the date field provided by the Blackberry, because it is invalid. The reason
LISTSERV does not do that is pressure from customers who want LISTSERV to
try and "repair" broken date fields as much as possible, since discarding
them means that valuable information is lost. These customers' rationale is
that, because L-Soft is smaller than the company that cannot be bothered to
follow Internet standards, it is L-Soft that needs to change. And, to some
extent, we agree, not because we agree from an academic standpoint, but
because we accept that the Internet is no longer ruled by a body of
academics who make standards, but by the big companies that dominate the
marketplace. If we do not adjust, people will just take their business
elsewhere. Either way, the big company will win and succeed in changing the
de facto standard, because they have that much power.

Anyway, the reason LISTSERV replaces the time stamp with 00:00:00 is that it
has customer-requested heuristics to attempt to process incorrect date
fields from dozens of different known sources, and these heuristics do not
handle Blackberry's particular type of invalid headers. The nature of this
type of code is that there is no guarantee that results will be correct. It
is impossible to handle every possible deviation from the standard, which is
why it is so important for everyone to use the standard format, but I
digress.

The reason "most" mail servers are more tolerant is a combination of chance
(their "repair" code, if any, does not happen to err in the particular case
of the Blackberry) and lesser requirements. LISTSERV guarantees that every
outgoing date field is compliant, so it must somehow convert invalid date
fields into something that is valid. Most mail servers have no such
requirement and can simply pass incorrect date fields along. Most mail
servers, in fact, do not have a need to even look at the date field at all.

One thing I would hate to do is to code "If message comes from blackberry
then parse as follows instead of the standard," because I can tell you from
experience that it is only a matter of time until Blackberry fix their
software. All it will take is an even bigger company not seeing any reasons
to add hacks to their code because a smaller company cannot be bothered to
follow the standard. When that happens, I really don't want to be in the
position of not accepting a valid date field because we applied a hack back
when blackberries had incorrect dates.

Another thing I would hate to do is to code "if field contains GMT +0000
then ignore the GMT" until we have established that this is the only
deviation that we need to handle in order to solve the blackberry problem.
What we have heard so far is that different blackberry units code the date
differently, and it would be very helpful to know what the deviations are
exactly. The only reliable way to get to the bottom of that problem is to
get in touch with Blackberry, which has been our first reaction. If they do
not want to speak with us, we will have to move on and make assumptions, but
frankly it should be in their interest to cooperate. L-Soft may not be a
$14bn company, but over 100 million people use LISTSERV. If I were RIMM, I'd
want to incite these people to get a blackberry, not give them a reason not
to.

This process may not solve your problem instantly, but ultimately it is for
the better good of L-Soft customers as a whole. We are not talking about a
local, one-site change, but about a change to the product stream that is
going to be released to all L-Soft customers, whether or not they even have
a blackberry. As such, it must be generally useful - solve the problem in
the general case, regardless of what time zone or country the blackberry is
in. We have occasionally developed one-customer changes by the hour, but
they have either not been released to other customers, or been disabled
unless a special configuration option is activated. Either way, the
standards are much higher for a change whose ambition is to deal with
incorrect blackberry headers worldwide, than if the goal is just to adjust
to the format generated by one particular blackberry unit (or group of
units). Finally, any change to the product stream that is a deviation from
Internet standards is subject to additional review to make sure that we do
not break things for any of the Good Guys who do follow Internet standards.

  Eric