BL> Is this right? Are you *sure* there is no name in the TIC?

 PE> Having never read any docs on the issue, here is one I received
 PE> from Dave... Area ZONEDIFF Origin 3:632/348 From 3:711/808 File
 PE> Z3DIFF.L13 Desc FidoNet Zone 3 difference file for day 313
 PE> (08-Nov-1996) in LHA format CRC 19DCFAF8 Created by TICK v2.10
 PE> (C) Copyright Barry Geller - 1988,1989,1990,1991,1992 Size 1828
 PE> Date 3646102C Path 3:632/348 847428141 Tue Nov 8 4:42:21 1994
 PE> GMT Path 3:711/808 847369111 Thu Nov 07 12:18:31 1996 GMT
 PE> Seenby 3:632/348

... page of useless crap deleted...

 BL> It would make more sense if the Origin field was the fido
 BL> number and the From field was "Bob Lawrence".

 PE> No-one actually cares what alias you happen to use on your
 PE> system.

  No one but us humans...

  I've had a cognition. I don't know what TIC is, and I don't care.
All I need is a letter-drop system: a name/address, a password, a
holding directory, a way to update the FILES list online, and FREQ can
do the rest. The problem with file attach is that someone else pays
the bill. With a letter-drop, only the users pay.

  This is what I'll write now... I think I'll call it PST (for post)

                 At the send end (DOS or Windows)

    config: name, address, password, upload dir

1.  Type file name(s)... does a file search and puts file(s) in upload
2.  Type file description(s).
3.  Writes POST file to send with file(s).

              At the BBS end

    config: in/out/specialr directories, names/passwords list

1.  Look in inbound for POST/files, check for files and password.
2.  Move files to specialr, add name/desc to list, erase POST.
3.  Send reply message on error or confirm.
4.  Sort specialr list, update FILES list.

 BL> what happens if you want to give access to someone who is not
 BL> one of your points?

 PE> I use their address. No problem.

  I still think it needs a name. Typing FIDO addresses is too easy to
get wrong. I think you need both.

 BL> TIC is automatic, but there are many ways it can fail. You
 BL> don't give a stuff if it works or not, so there's no point in
 BL> sending you messages, but it would be nice to send back a
 BL> report to the sendee,

 PE> That's a good idea. At the moment, yatic writes to a log file,
 PE> but I only look at that when I decide to clean up my inbound
 PE> directory. 

  Automatic is best...

 PE> If you write a .PKT file containing a netmail from my system, I
 PE> can easily toss that after running TIC. If writing a .PKT
 PE> directly is too much hassle, I wrote a utility that does that. 

  Ahh! What a good idea! I never thought of a packet. I wanted the
return message as part of the mail, but it never occurred to me
that you could add it to the packet easily.

  Where can I get your utility? Does my packet have to have a packet
header, or just the message header? And what do I call it?

 BL> I'm hoping it will be quick enough to do online (1 second or
 BL> less). Can I just put a message in a directory and have it sent
 BL> off with the mail?

 PE> You can't do it online unless you modify binkley.

  Oh. Whatta disappointment! I was hoping to send confirmation
straight back.

  So...

  As it stands now, Binkley does its thing and answers the phone, puts
all the inbound in the inbound directory... checks what's waiting and
sends that back, and then... TIC gets to sort out what it has in the
inbound. There's no way to slip TIC in between? Bummer.

 PE> I'll post the code

  That answers one of my questions, anyway... saved.

  Jeesuz! All that? And it looks like you do need a packet header, so
all I need to know is... what do I call it? Won't "temp.pkt" get lost
in the syustem?

Regards,
Bob
 

 
___ Blue Wave/QWK v2.12
@EOT:

---