Can a work-around be found for this problem? Depending on how Emailer was coded, it may be possible to increase Emailer's truncation limit by editing the application binary. Finding the right number to change could be done by brute force, assuming it's that simple, but that would take more time than I can spare. One or other of the original Emailer authors would be in a better position to fix this problem, if a fix is indeed possible.
Comments on this subject would be most welcome.
Sorry for the late reply. I was on vacation last week and I'm only now catching up on my backlog of messages. I'm surprised no one has mentioned this already, but there are two likely problems with your suggested solutions.
1) It's unlikely that "finding the right number to change" would fix the problem, since it's unclear how Emailer allocated the memory buffer it uses to store the text received from the server. If the memory buffer can't be enlarged, we can't tell Emailer to download more than 1000 characters at a time since doing so would cause Emailer (and possibly the whole operating system or classic environment) to crash.
2) As far as I know, none of the Emailer authors that we have contacted have ever admitted to possessing the Emailer source code, or otherwise agreed to provide technical assistance in developing fixes or updates to Emailer.
However, I am suspicious that after all this time, this problem has only appeared recently. And for that matter, has only been reported by you so far. I suspect that if you investigate, you will discover that the messages are originating from either a new entry in the email application market, or a specific version of an existing niche player. A few polite questions -- with citations to the RFC's you uncovered -- to the developers might clear up the problem.
___________________________________________________________________________ To unsubscribe send a mail message with a SUBJECT line of "unsubscribe" to <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
