While ive done some tests on blackbery systems running in turkey (operator),
canada (es) and the netherlands (es).  Messages sent from different
blackberry installs in all these countries to a listserv test list seems to
all have the correct time stamps (also correct in direct emails).   So im
beginning to wonder whether this has to do with the individual blackberry
enterprise server installations.  Once again the problem bb devices should
be investigated for the actual gateway they use to connect.


I also sadly see this thread turning into a big guy/little guy discussion.
Without commenting on whose right and whose just I have to remind you that
the internet was built on protocols and not really standards.  Protocol is
when 2 or more people decide to do something one way and just do it amongst
themselves, others can later join in if they like it or go build their own
protocol (call it NAFTA).  A standard is where everybody agrees on a
specific implementation (call it the WTO or UN).  While there are advantages
to both you have to be carefull for what you wish upon as one will take
years and years to finalize while the other is quick (and at times dirty)
but gets the job done and quite a few times that's all you need.   


Best,
Omer.


> -----Original Message-----
> From: LISTSERV site administrators' forum 
> [mailto:[log in to unmask]] On Behalf Of Eric Thomas
> Sent: Wednesday, August 24, 2005 6:47 PM
> To: [log in to unmask]
> Subject: Re: Lsoft and blackberry from blackberry
> 
> >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
>