ml> sure... why not? well, since you seem to want to go there... tell
 ml> me/us this, why, when using netmail, did i not have the problems
 ml> that i have with email? the inputs to both are exactly the same...

 ml> ie1: netmail updates of rules files using file attaches result in
 ml> 8.3 format filenames in the database (which are correct!) but via
 ml> email, something screws up and uses longfilenames derived from who
 ml> knows where??

 TL> I don't have a rule file to play with....however:

if you don't then you aren't following along, aren't on the same page, and
surely aren't testing the problem that i've been trying (my damnest!) to
explain to you :(

 ml> ie2: netmail updates handle -------- dividers with no problems but
 ml> email updates choke like they've swallowed a chickenbone...

 TL> I just submitted a MOD UPD message to the robot via netmail.  I
 TL> followed your style of inserting a line that contained a series of
 TL> ------  

[*sigh*] none of my DESC's have three or more dashes in them... never have,
actually... it is =only= the RULes files that do ;)

[trim]

 TL> And so your statement that you can use a ---------- in netmail is
 TL> simply inaccurate.

and your test wasn't a test of what i've been telling you about and
describing all this time...

also, that test isn't an accurate representation of the dashed lines that i
have used... =all= of the ones that i've used have had a =leading space=
(!!!) which immediately takes them out of the realm of being a tearline...
especially since tearlines start in column 1 and not column 2...

 1. netmail attaches of the RULes files were never 
    truncated at a line with three or more dashes...

 2. netmail attaches of the RULes files never had
    their filenames pulled from the ether and stored
    as longfilenames...

 TL> Ad now I have another problem....the MARKTEST echo is in the
 TL> database.  Should I leavve it there for six months so that it will
 TL> automatically expire, or should I manually delete it and thus
 TL> compromise the database because it has been touched by human hands?

ROTFL! just submit a MOD DEL ;)  but the first question is why are you
testing on a live database?? ;) O:)

and that brings up another (and actually the very first)
"problem" i attempted to describe to you years back... i/you
can't send a MOD DEL to remove an entry and then follow up with a MOD ADD
to "replace" the old (and bad) entry... what happens is that the
new info goes into the old entry and that's not right... i was trying this,
way back then, in an attempt to remove and purge the invalid longfilenames
that were mistakenly put in for my RULes file's names...

oh well :( :( :( 

 ml> FWIW: these are the two major problems i've tried discussing with
 ml> you and getting worked out... sadly, though, you seem to always
 ml> insist that it is my end that has the problem... i guess it is
 ml> easier to try to shovel the blame elsewhere, eh?

 TL> Your instance that you can do what you can't and that the echolist
 TL> needs to work the way you want it to work is getting real old.

you're putting words into my mouth, thom... i've never insisted that the
echolost work the way that =i= want it to... and i surely have never
insisted that it _needs_ to, either... quite a long way away from those...

 TL> Once again....the Echolist looks for a line containing a line with
 TL> at least thre --- to signify the end of the message.

i have no problem with that as far as the MOD UPD and MOD ADD stuff goes...

 TL> I'm at a loss to explain the problem with the rules file...

then what are we having this discussion for? my complaints about the dashes
have -=*ALWAYS*=- been about the _RULes_ and nothing else! :(

 TL> but if you can't explain the MOD UPD problem correctly, perhaps 
 TL> you're not having a problem? 

perhaps if folk would keep up and follow along with what is being said
and/or written, problems, "arguments", and misunderstandings like
these would never happen...

)\/(ark