home *** CD-ROM | disk | FTP | other *** search
/ synchro.net / synchro.net.tar / synchro.net / main / BBS / qwke.txt < prev    next >
Encoding:
Text File  |  2000-02-16  |  17.1 KB  |  460 lines

  1.                            QWKE Specifications 1.02
  2.       (also known as EQWK - pronounced Quicky, and E-quick respectively)
  3.  
  4.  
  5.                       Copyright 1994-1997, Peter Rocca
  6.                              Fidonet 1:2401/305
  7.                        Email: support@multiboard.com
  8.                          http://www.multiboard.com/
  9.                                (519) 660-3574
  10.  
  11.  
  12.  This documentation may be freely used to enhance/create 1st, 2nd or 3rd
  13.  party applications or utilities without any legal obligation to the author.
  14.  Please do not extend or further the QWKE without contacting Pete Rocca, in
  15.  order to keep the standard from becoming a 'non-standard'. - Thank you.
  16.  
  17.  
  18.  QWKE Specifications
  19.  ───────────────────
  20.  
  21.  All files and formats match the QWK 1.0 standards.  If you are not familiar
  22.  with them, I would suggest getting QWKLAY??.ZIP by Patrick Y. Lee. (it is
  23.  freqable from my system)
  24.  
  25.  The only differences to the standard QWK format lay in four files.
  26.  
  27.          CONTROL.DAT  - conference area names are no longer limited
  28.                         to 13 characters, they are limited to 255
  29.                         characters now.
  30.  
  31.          DOOR.ID      - contains additional CONTROLTYPE names.
  32.  
  33.          TOREADER.EXT - a file created by the door that contains
  34.                         additional information for the reader.
  35.  
  36.          TODOOR.EXT   - a file created by the reader that contains
  37.                         additional information for the door.
  38.  
  39.  In addition, certain kludge lines should be imported to messages when
  40.  downloading, if their length exceeds 25 characters.
  41.  
  42.    These kludges are...
  43.  
  44.                            To:
  45.                            From:
  46.                            Subject:
  47.  
  48.    ...they should be at the top of the message, and terminated by
  49.    either a carriage return, or the 'π' QWK terminator.  At the end
  50.    of the last imported kludge, there should be a blank line, however
  51.    you should program to handle if one is not present.  Additional
  52.    kludge names can be created, but your reader/door should at least
  53.    handle these three.
  54.  
  55.    Also, the kludge lines To/Subject should be imported into the message
  56.    fields when posting the messages. (uploading)  The From kludge can
  57.    be accepted, but remember to check the security of it (ie make sure
  58.    that the name is allowed, ie alias base, etc)  Also, regarding the
  59.    To: kludge... keep in mind that UUCP software likes the To: line
  60.    left in the first line of a message, therefore it should not be
  61.    removed from the message if this message is destined to be sent
  62.    through an UUCP gateway.
  63.  
  64.    A sample message with kludge lines might look like:
  65.  
  66.      1       10        20   25
  67.      |---+----|----+----|----|
  68.   TO:PETER ROCCAZISKINZIDONING
  69. FROM:BOB WILIKERS
  70. SUBJ:This is a test of the sys                       <--- HEADER
  71.      --------------------------------------------------------------------
  72.      To: PETER ROCCAZISKINZIDONINGLY                 <--- MESSAGE TEXT
  73.      Subject: This is a test of the system, as you can see!
  74.      <blank line>
  75.      The real message starts here now, but it was short, so
  76.      see you later.
  77.  
  78.    As you can see, only the To/Subject lines were imported, since the
  79.    From line did not exceed the 25 character limit.
  80.  
  81.    One command question is NETMAIL? How do you do it?  A standard that
  82.    I would suggest is the "Subject line method" which is simply an "at"
  83.    symbol, followed by the full netmail address.  For example to send
  84.    mail to Pete Rocca at 1:2401/305.200, the message header would look
  85.    like this:
  86.  
  87.    To: PETE ROCCA
  88.    Fm: JOE USER
  89.    Sb: @1:2401/305.200
  90.  
  91.    How about internet mail?
  92.  
  93.    Well, internet mail going out a fido gateway would simply be a netmail
  94.    message with a To: <address> on the first line. It is upto the mail
  95.    door not to import a "To:" kludge when sending internet netmail mail.
  96.    For example (Fido->Internet)
  97.  
  98.    To: UUCP
  99.    Fm: JOE USER
  100.    Sb: @1:1/31
  101.    ------------------------------------
  102.    To: support@mbcc.com
  103.    Subject: Hello there
  104.  
  105.    A regular internet message would simply be a regular message, but with
  106.    a "To" kludge to avoid the 25 character limit in the To field.
  107.    For example (regular Internet)
  108.  
  109.    To: INTERNET                         <--- this gets replaced on import
  110.    Fm: JOE USER
  111.    Sb: Hello there
  112.    ------------------------------------
  113.    To: support@mbcc.com
  114.  
  115.    Of course, as a door or reader author, you can make this completely
  116.    transparent to the user.
  117.  
  118.  
  119. ══════════════════════════════════════════════════════════════════════════════
  120.  
  121.  File: TOREADER.EXT
  122.  ──────────────────
  123.  
  124.   Desc: This file is simply an ASCII text file that is included
  125.         in the QWK packet, and contains information used by the
  126.         QWK reader. (created by the mail door)
  127.  
  128.  Each line has an identifier, followed by the relevant information
  129.  for the extended information. (Arguments in < > are required,
  130.  and ones in [ ] are optional)
  131.  
  132.    ALIAS     <users' alias name>
  133.    AREA      <conference#> <settings>
  134.    BULL      <filename> <description>
  135.    ATTACH    <filename> <conference#> <message#>
  136.    FILE      <filename> [description]
  137.    KEYWORD   <keyword>
  138.    FILTER    <filter>
  139.    TWIT      <twit>
  140.  
  141. ──────────────────────────────────────────────────────────────────────────────
  142.  
  143. Identifier: ALIAS <users' alias name>
  144.  
  145.    This simply passes the users' alias name to the door in order to be
  146.    able to present it to the user when entering mail in 'alias' areas.
  147.  
  148.    An example would be: ALIAS Rawhide
  149.  
  150. ──────────────────────────────────────────────────────────────────────────────
  151.  
  152. Identifier: AREA <conference#> <settings>
  153.  
  154.    This presents a list of selected areas (or all areas optionally), and
  155.    what the flag settings for each area are.  The <conference#> is the
  156.    number of the area that is selected and the <settings> contains the
  157.    flags for that area.
  158.  
  159.    The possible flags are:
  160.  
  161.        a   for all messages
  162.        p   for personal messages
  163.        g   for general messages (personal and those addressed to 'ALL')
  164.  
  165.    In addition, some mail doors can add the following flags: (this
  166.    information is set by the mail door itself, and overrides and standard
  167.    BBS settings)
  168.  
  169.        w   if this area should include mail written by themselves
  170.        k   if this area should be included in keyword searches
  171.        f   if this area should be included in filter exclude searches
  172.        F   if this area is forced to be read
  173.        B   if this area is blocked from getting replies
  174.  
  175.    In further addition, area information should be given - this information
  176.    is gathered from the BBS records.
  177.  
  178.        P   if the area is private mail only
  179.        O   if the area is public mail only
  180.        X   if either private or public mail is allowed
  181.        R   if the area is read-only (no posting at all allowed)
  182.        Z   if the area doesn't allow replies (no continuation of thread)
  183.  
  184.        L   if the area is a local message area
  185.        N   if the area is a netmail area
  186.        E   if the area is an echomail area
  187.        I   if the area is an internet area
  188.        U   if the area is an newsgroup area
  189.  
  190.        H   if the area is an handles only message area
  191.        A   if the area allows messages 'from' any name (pick-an-alias)
  192.        &   if the area allows file attaches
  193.            (does not override CONTROLTYPE=ALLOWATTACH)
  194.  
  195.    Again the door should enforce security to messages with private
  196.    flags and/or different names to ensure that they are allowed.
  197.  
  198.    For example, if a user had 4 areas selected, it might look like this:
  199.  
  200.    AREA 23 awOU
  201.    AREA 31 aFPLA
  202.    AREA 44 pkPN&
  203.    AREA 172 gwkfPI
  204.  
  205.    ...please note that the flags ARE case sensitive & and any unknown
  206.    flags should be ignored.
  207.  
  208. ──────────────────────────────────────────────────────────────────────────────
  209.  
  210. Identifier: BULL <filename> <description>
  211.  
  212.    This is a way of describing the bulletins a little better than
  213.    the file name BLT-x.y method.  The actual files should still be
  214.    in the BLT-x.y format to ensure backward compatibility, but by
  215.    describing the filenames here, you can have something like
  216.    looks like:
  217.  
  218.         Bulletins
  219.           - System Stats
  220.           - Top Users
  221.           - Contest galore!
  222.  
  223.    Instead of:
  224.  
  225.         Bulletins
  226.           - BLT-1.4
  227.           - BLT-3.2
  228.           - BLT-6.1
  229.  
  230.    In this example, the TOREADER.EXT file would have three lines
  231.    added to create these descriptions:
  232.  
  233.    BULL BLT-1.4 System Stats
  234.    BULL BLT-3.2 Top Users
  235.    BULL BLT-6.1 Contest galore!
  236.  
  237. ──────────────────────────────────────────────────────────────────────────────
  238.  
  239. Identifier: ATTACH <filename> <conference#> <message#>
  240.  
  241.    This is a method used to identify which messages have files attached
  242.    that were downloaded with the packet.  It is upto the mail door
  243.    to decide whether or not to send attached files, this is simply a
  244.    method for the reader to acknowledge such files.
  245.  
  246.    For an example:  Say that message number 782 in conference 12 had
  247.    the file TEST.ZIP attached to it, and the mail door included this
  248.    TEST.ZIP file in the BOARDID.QWK archive.  The TOREADER.EXT file
  249.    would have the follow entry to let the mail reader know about this
  250.    file.
  251.  
  252.    ATTACH TEST.ZIP 12 782
  253.  
  254. ──────────────────────────────────────────────────────────────────────────────
  255.  
  256. Identifier: FILE <filename> [description]
  257.  
  258.    This is a method used to identify which files in the QWK archive
  259.    are file requests from the bulletin board.  It is upto the mail door
  260.    to decide whether or not to send these requested files, and this
  261.    is simply a method for the reader to acknowledge such files.
  262.  
  263.    For an example:  Say that the file GOODGAME.ARJ was requested and
  264.    added to the BOARDID.QWK archive.  When the mail reader expanded it,
  265.    it would not know which files had been requested by the user, nor
  266.    what the description of those files were.  Place using the FILE
  267.    identifier, the reader can easily present a nice listing of requested
  268.    files, rather than having to guess at the file names, and having
  269.    no idea of the description (although the description is optional).
  270.    In the GOODGAME.ARJ example, the mail door should add the following
  271.    line to the TOREADER.EXT file.
  272.  
  273.    FILE GOODGAME.ARJ This is a great new SVGA action game!
  274.  
  275.    or
  276.  
  277.    FILE GOODGAME.ARJ
  278.  
  279. ──────────────────────────────────────────────────────────────────────────────
  280.  
  281. Identifier: KEYWORD <data>
  282. Identifier: FILTER  <data>
  283. Identifier: TWIT    <data>
  284.  
  285.    These identifiers are for mail doors that can process keywords,
  286.    filters and twit listings. It is used only to inform the mail
  287.    reader of the settings used, in order to make offline configuration
  288.    much easier for the user.  For example, if the TOREADER.EXT file
  289.    had the following lines...
  290.  
  291.    KEYWORD olms
  292.    KEYWORD qwk
  293.    FILTER hacking
  294.    TWIT Death Wizard
  295.  
  296.    ...then the mail reader could present a list of these settings
  297.    and allow changes to be made to them, and create the proper
  298.    TODOOR.EXT lines to alter the configuration.
  299.  
  300. ══════════════════════════════════════════════════════════════════════════════
  301.  
  302.  File: TODOOR.EXT
  303.  ────────────────
  304.  
  305.   Desc: This file is simply an ASCII text file that is included
  306.         in the QWK packet, and contains information used by the
  307.         QWK mail door. (created by the mail reader) It must be
  308.         read back and processed by the door.
  309.  
  310.  Each line has an identifier, followed by the relevant information
  311.  for the extended information. (Arguments in < > are required,
  312.  and ones in [ ] are optional)
  313.  
  314.    AREA      <conference#> <settings>
  315.    RESET     <conference#> [#ofmessages]
  316.    ATTACH    <filename> <reply#>
  317.    FILE      <filename> [description]
  318.    REQUEST   <filename>
  319.    REQUEST   <conference#> <message#>
  320.    KEYWORD   [-]<keyword>
  321.    FILTER    [-]<filter>
  322.    TWIT      [-]<twit>
  323.  
  324. ──────────────────────────────────────────────────────────────────────────────
  325.  
  326. Identifier: AREA <conference#> <settings>
  327.  
  328.    This presents a list of CHANGES areas, and what the flag settings
  329.    for each area changed are. The <conference#> is the number of the area
  330.    that is to be changed and the <settings> contains the flags for that area.
  331.  
  332.    The possible flags are:
  333.  
  334.        D   drop area
  335.        a   for all messages
  336.        p   for personal messages
  337.        g   for general messages (personal and those addressed to 'ALL')
  338.  
  339.    In addition, some mail doors can add the following flags:
  340.  
  341.        w   if this area should include mail written by themselves
  342.        k   if this area should be included in keyword searches
  343.        f   if this area should be included in filter exclude searches
  344.  
  345.    For example, if a user had changed 2 areas, it might look like this:
  346.  
  347.    AREA 23 D
  348.    AREA 44 gf
  349.  
  350. ──────────────────────────────────────────────────────────────────────────────
  351.  
  352. Identifier: RESET <conference#> [#ofmessages]
  353.  
  354.    This presents a list of pointer changes to be made.  The pointers should
  355.    be changed for the <conference#> given.  If the [#ofmessages] is blank
  356.    then the pointer should be set back to the start of the message base,
  357.    otherwise it should be set back [#ofmessages] back from the end of
  358.    the message base.
  359.  
  360.    For example, if a user had modified 2 areas, it might look like this:
  361.  
  362.    RESET 23 100
  363.    RESET 44
  364.  
  365. ──────────────────────────────────────────────────────────────────────────────
  366.  
  367. Identifier: ATTACH <filename> <reply#>
  368.  
  369.    This is a method of creating messages that have files attached
  370.    to them.  The mail reader should pack the <filename> into the
  371.    BOARDID.REP file, and add this line in the TODOOR.EXT file,
  372.    which is also included in the BOARDID.REP file.
  373.  
  374.    The <reply#> is the number of the message in the reply packet.
  375.    For example, if the third message in the reply packet had the
  376.    file ATTACHME.ZIP attached to it:  The BOARDID.REP file should
  377.    contain the file ATTACHME.ZIP, BOARDID.MSG and the TODOOR.EXT
  378.    file.  The TODOOR.EXT file would contain the line...
  379.  
  380.    ATTACH ATTACHME.ZIP 3
  381.  
  382.    ...within it. NOTE! that it is upto the mail door whether or not
  383.    it will allow files to be attached to messages.  This is governed
  384.    by the mail door inserting the line CONTROLTYPE=ALLOWATTACH in
  385.    the DOOR.ID file.
  386.  
  387. ──────────────────────────────────────────────────────────────────────────────
  388.  
  389. Identifier: FILE <filename> [description]
  390.  
  391.    This is a method of uploading files in your mail packet.  These
  392.    are general public files, and should be processed for credit on
  393.    the bulletin board.
  394.  
  395.    For example, if you included a file called GOODGAME.ZIP in your
  396.    BOARDID.REP file for credit on the BBS, the mail reader should
  397.    insert the line...
  398.  
  399.    FILE GOODGAME.ZIP This is a great new game!
  400.  
  401.    ... in the TODOOR.EXT file.  It is upto the mail door whether
  402.    or not it accepts files to be uploaded with the mail packets.
  403.    This can be detected by the CONTROLTYPE=ALLOWFILES line
  404.    being added to the DOOR.ID file in the downloaded packet.
  405.  
  406. ──────────────────────────────────────────────────────────────────────────────
  407.  
  408. Identifier: REQUEST <filename>
  409. Identifier: REQUEST <conference#> <message#>
  410.  
  411.    These are file requests, either for files on the board, or files that
  412.    are attached to messages.
  413.  
  414.    "REQUEST bob.zip", would request the file BOB.ZIP from the BBS's file
  415.    collection, whereas "REQUEST 12 333", would request the files attached
  416.    to message #333 in conference #12.  It is upto the door to provide
  417.    security as to what can be requested.
  418.  
  419. ──────────────────────────────────────────────────────────────────────────────
  420.  
  421. Identifier: KEYWORD [-]<data>
  422. Identifier: FILTER  [-]<data>
  423. Identifier: TWIT    [-]<data>
  424.  
  425.    These identifiers are for changes made to the keywords, filters
  426.    and twit listings. It is used only to process CHANGES therefore
  427.    if the setting "KEYWORD bob" was given, it does not mean it is
  428.    the only keyword in the list, rather added to the list of keywords.
  429.    To remove an entry, precede it with a minus sign (-), so an example
  430.    to remove a keyword "bob" from the list of keywords would be
  431.    "KEYWORD -bob"
  432.  
  433. ══════════════════════════════════════════════════════════════════════════════
  434.  
  435.  Additional CONTROLTYPE= settings (DOOR.ID file)
  436.  ───────────────────────────────────────────────
  437.  
  438.     CONTROLTYPE=MAXKEYWORDS <#>  -> max keywords the door can handle
  439.     CONTROLTYPE=MAXFILTERS <#>   -> max filters the door can handle
  440.     CONTROLTYPE=MAXTWITS <#>     -> max twits the door can handle
  441.     CONTROLTYPE=ALLOWATTACH      -> if the door allows file attachments
  442.     CONTROLTYPE=ALLOWFILES       -> if the door allows files to be uploaded
  443.     CONTROLTYPE=ALLOWREQUESTS    -> if the door allows files to be requested
  444.     CONTROLTYPE=MAXREQUESTS      -> max number of daily file requests
  445.  
  446. ══════════════════════════════════════════════════════════════════════════════
  447.  
  448.  
  449.  History
  450.  ───────
  451.  
  452.  Rev 1.02, 10/17/95 : Fixed a few typos
  453.  Rev 1.01, 12/04/94 : Added information on netmail and internet mail
  454.  Rev 1.00, 10/12/94 : Released official standard
  455.  
  456.  
  457.                             - End Documentation -
  458.  
  459.  
  460.