>  ml>> ie: dorinfo1.def dorinf22.def dorin134.def

 >  MvanL> Which is all pointless unless the door is programmed to read the mos
 >  MvanL> recent created *.def file or accept a node number as a command
 >  MvanL> line option.

 > haha... good thing you're not a real programmer, then O:)

RA should drop support for exitinfo and strictly adhere to door.sys standards 
then, because their programmers couldn't fathom the limiting issues with 
their chosen implementation.

 > what's wrong with passing the dropfile name on the command line and letting
 > door parse that filename to determine the node number? believe it or not, it
 > works for many doors out there ;)

What's wrong with passing the node number as an option to the door ? hence 
rendering node number dropfile naming conventions irrelevant. Believe it or 
not it works for many doors out there.

 >  MvanL> A "/node=65535" sounds pretty limitless to me.

 > furrfu, damn good thing you're not a real programmer ;) it is arbitrary
 > limi  > like that that have caused all kinds of problems over the years...

It's not an arbitrary limit. It's an example command line option.

 > for instance... 1. some popular offline mail readers have a 200
 > =line= limit...

 > 2. some FTN mail tossers can't process FTN messages larger than
 > 16K... fewer can handle 32K... what's the problem? the specs state
 > that the message body of a packed message is unbounded...
 > that means that you read until you hit the next null character
 > not just read 16K... that's laziness, amoung other things ;)

Which are all issues for the relevant applications and users of those 
applications, and are non existent problems for me.

Firstly, I definitely would seriously reconsider using any mail readers 
limited to a crappy 200 line message.

Secondly because Squish can be configured to split large packet sizes I have 
no problem sending or receiving messages for any practical purpose.

--- SBBSecho 2.12-Win32