>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