NB>>> IIRC, one puts UUCP as the To: and then puts the actual
 NB>>> addy on the first line.  Was/is there any special
 NB>>> punctuation before or around the addy?

 ML>> nope... just a leading TO: and a blank line after the
 ML>> addresses... one TO: name{at}address per line...

 NB> Oh, ok.  So one could send to multiple recipients, hunh?
 NB> Don't think I ever tried that.

yup, exactly right... each line would have "TO: recipient" sans quotes...

[trim]

 ML>> using my gateway works with /any/ fidonet system that's
 ML>> operational and has a valid routing path to it...

 NB>>> Of course the other problem with that* BBS is that he
 NB>>> doesn't have any offline mail door so anything HAS to be
 NB>>> done online there... :(

 ML>> i know that feeling... i had to remove the offline mail
 ML>> doors on my system because they were (and still are)
 ML>> incompatible with the version of the BBS software that i'm
 ML>> running...

 NB> Oh.  That explains why offline wasn't working when I finally
 NB> did* manage to get online to your bbs!

you should have gotten something on that screen to the effect that the
offline mail doors had been removed until further notice or some such...

 NB> Ummmm.... then how
 NB> does getting email thru your gate work?  I'm guessing that if
 NB> I use the net/node numbers from chowda that it will arrive
 NB> there in my netmail, and thus in my packet to deal with
 NB> offline (and in BW)?  But to do it on your bbs, I'd need to
 NB> do it all online?

yes, currently all affairs are done online on my system... its not the best
or the fastest but it is reliable and accurate ;)

 NB> Any likelihood that you'll be able to get offline mail doors
 NB> working with your bbs software eventually?

yeah... if i sit down and write one... there's no offline mail doors that
will work with this version of the bbs software that i'm running... at
least not that i'm aware of... this version was released after most of the
offline mail door authors left this scene and its updated configs are just
enough different that those old doors really screw things up... and there's
also the situation of new message areas being added to the system...
they're /inserted/ into the area configs so as to have an alphabetical
listing... this means that the area numbers can and will change... many of
those old doors are based on the area number or position in the datafiles
rather than the area name... if they were based on the areaname, there'd be
no problems with moving areas around...

FWIW: i've probably got all the code needed... its just a matter of putting
it all together... the worst problem is that its been a few years since
i've done any real coding... yeah, a few bbs utils here and there but
nothing like a mail door... if i were to really sit down and do it, i'd
also want to do it /right/ for fidonet... that would mean that the offline
readers would likely not work with the new door, either... as far as
fidonet goes, the *best* way to do the offline stuff is to become a point
and pull the mail just like any other node and to use the same type of
reader/editors that most sysops use... like the one i'm using now... all
its ops are completely outside the bbs... i've three or four that i use all
the time and they all access the message bases directly without any
interface with the bbs at all ;)  there was a point package designed for
this way back but i cannot remember what it was called... it was a
competitor with BW, QWK, OPX and SOUP... heck, it might have been OPX but i
doubt it... in any case, it had a mailer function that tapped the boss
node's mailer and pulled the mail bundles just like another node would
do... then it unarchived the messages and you read and replied to them...
when done, it would create a bundle of replies to upload back to the boss
node's mailer... it didn't matter if the message areas changed or not
because it all operated outside the bbs... the mail was tossed and scanned
just like any other fido node's... it just makes sense OB-)

)\/(ark