} Sorry if I misunderstood. I've noticed that whenever I send commands to
} uqwk, and have another mail message after the uqwk command message, the
} result seems to be completely unpredictable. Sometimes the message gets
} an enormous amount of garbage at the end, which sounded like what you
} described. All I've been able to do is to remember that if I write a
} new mail message after a command message to uqwk, remember to go in and
} edit the reply packet afterwards, to move the uqwk commands to the end.
Yes, this IS a quirk of uqwk -- and the procedure you describe
is what you must do!
In short, ALWAYS be sure the uqwk commands are LAST.
} Um, I'm afraid that I do see his point here. I have used uqwk for about
} two years now, and have never experienced this problem. Granted, lines
} beginning with From get a > in front, but that is a minor problem.
If there is a > in front of the From, then you will NOT have the problem.
The problem occurs when a sender does not put > in front of From when
there is a blank line just before the From.
} far as I recall, you suggested that he should check for the @ character
} in the line, which would break any message from a local user. That
} would be just as big a problem as the one you have, if not for you
} personally.
I dont now recall what algorithm I suggested, as it was near two years
ago now... but I'm still convinced that I had worked out a satisfactory
check to avoid the problem. But Steve the uqwk author simply said he was
not going to make any changes; period.
} The question is, what are the standards about the format of mail spool
} files? And which software has not followed those standards? The mail
} transport software on your site, or uqwk? After all, *something* is
} different between your and my system, and that is not uqwk.
Are you SURE that you have not received any mail with a blank line
followed by a From at the start of the next line? Perhaps he HAS
changed uqwk and your system has the new version? :)
} Anyway, I don't understand what this has to do with the messages growing
} so large? The messages are plit up where they should not be, but
} doesn't that only result in two messages half the original size? Mind
} that I, as I said, have never experienced this problem.
What happens when the messages gets split is that the second part does
not have a valid set of header lines, and so the pointer which would
tell Yarn (or other decoder of uqwk/soup packages) how big the next
message is can be some random pointer size, being whatever the first two
bytes of the ascii text of the first line of the broken section contains.
This can, apparently, appear to be very very large. And Yarn 'import'
will read that 'size pointer' and put that many bytes into the message.
--
**********************
Jim Cooper w2jc@ritz.mordor.com
**********************
A conclusion is simply the place where someone got tired of thinking.
*******************************************************************
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.1
mQBtAzDw62gAAAEDAMBhMNlTzNRcSWHTnQPFQfchKF2X7W0uQGhQOGcKi3GEtg6u
vub9/ur+IHLxtRDrCHs0krKQ2n0586JEmCn9W95vM0KAxPKXmusJZGacNakHPyWn
Rdbs9z6kKeVm8ZbFoQAFEbQiSi5FLiBDb29wZXIgPHcyamNAcml0ei5tb3Jkb3Iu
Y29tPg==
=TqvR
-----END PGP PUBLIC KEY BLOCK-----