








                     Errors in RFC 1036


                       Geoff Collyer

                  Department of Statistics
                   University of Toronto





_I_n_t_r_o_d_u_c_t_i_o_n

     RFC 1036, the standard _d_u _j_o_u_r for the format of Usenet
(netnews)  messages  contains significant errors, enumerated
below.  References are made to RFC 850, the previous netnews
message format standard.

_H_e_a_d_e_r _o_r_d_e_r _i_n_s_i_g_n_i_f_i_c_a_n_t

     Between RFC 850 and RFC 1036, a sentence  stating  that
the order of message headers is insignificant has fallen out
of the standard.  This may be a reflection  of  the  reality
that  B  2.10  news did indeed care about the order of _F_r_o_m:
and _P_a_t_h:.

``_R_e:'' _i_s _o_n_l_y _t_h_r_e_e _c_h_a_r_a_c_t_e_r_s

     One  sees  the  contradiction  ``the  four   characters
"Re:"'' repeatedly; there should be a space after the colon.

_c_m_s_g _i_n_c_o_r_r_e_c_t_l_y _d_e_s_c_r_i_b_e_d

     Similary, RFC 1036 claims that  a  _S_u_b_j_e_c_t:  prefix  of
``cmsg''  will be interpreted as denoting a control message;
the correct prefix is ``cmsg '' (including a space).

_X_r_e_f _i_s _t_r_a_n_s_m_i_t_t_e_d

     RFC  1036  says  that  _X_r_e_f:  headers  should  not   be
transmitted,  yet they are stored on disk as part of message
headers, so they will be transmitted by both B and  C  news.
The standard appears to be too strict.

_c_a_n_c_e_l_s _s_h_o_u_l_d _p_r_o_p_a_g_a_t_e _a_l_w_a_y_s

     RFC 1036 says that _c_a_n_c_e_l control messages should  stop
propagating  if  the  receiving system is ``unable to cancel
the message as requested''.   It  is  not  clear  what  this
means,   given   that   modern   news   systems   hang  onto



                       March 26, 1991





                           - 2 -


cancellations for not-yet-seen articles in  hopes  of  being
able  to  cancel  them  in  the  future.   B 2.11 interprets
absence of the target article as ``unable to  cancel''.   It
would  improve  the  efficacy  and reliability of _c_a_n_c_e_ls to
propagate  them  anyway,  given  that  feed  anomalies   are
widespread.   There  have  been  verified instances in which
cancellations did not achieve anywhere near the  propagation
of  the original article.  In the interests of robustness, C
News interprets absence of the target  article  as  deferred
cancellation  rather  than failure to cancel, and propagates
the _c_a_n_c_e_l.

_c_a_n_c_e_l _v_a_l_i_d_a_t_i_o_n

     RFC 1036 requires that a _c_a_n_c_e_l message have a  _S_e_n_d_e_r:
or  _F_r_o_m:  header matching the message it is cancelling.  It
is not entirely clear from the text whether this restriction
is  supposed  to  be  enforced at the originating site or at
each receiving site, although the latter is implied.

     More seriously, it is not clear what ``matching'' means
in  this context, considering that a substantial fraction of
the information in such lines is typically in RFC  822  com-
ments.   There  is  an unfortunate tradition of news readers
generating header comments in varying ways.  There is also a
lot  of  obsolete  or misdesigned news software still opera-
tional, and some of it gratuitously alters the  header  com-
ments  (and  sometimes  even  the  non-comment  parts of the
headers!) in messages passing through.  While  theoretically
these  complications should affect the original and the can-
cellation identically, in practice this is not  consistently
so,  and  it  is  difficult  to generate a cancellation that
works dependably.  This is not just speculation;  there  are
verified cases of the originators of messages having consid-
erable difficulty cancelling them when it was  important  to
do so.

     The value of RFC 1036 authentication is  also  somewhat
questionable.   It  provides no useful security against mal-
ice, because news is so easy to forge.  While there is  some
value in preventing accidents, there is room for doubt as to
whether this is worth the interference with legitimate  can-
cellations.

     C News takes the position that the RFC 1036 approach to
authentication  is  impossible  to  implement in a practical
way, due to its vagueness and the prevalence  of  gratuitous
and  unpredictable header rewriting, and on balance the ina-
bility to cancel is worse than the largely-illusory security
provided.   C News therefore does not authenticate cancella-
tions.

     Doing  something  about  the  problem   is   difficult.
Specification  of  a  _p_r_e_c_i_s_e  algorithm for header matching



                       March 26, 1991





                           - 3 -


would help, but finding one that will  disregard  gratuitous
header mangling is hard.  A more appealing approach would be
to authenticate cancellations by  cryptographic  means,  but
there  are  severe  difficulties  in  key distribution on an
unreliable non-real-time network like Usenet, and  the  cost
of  checking cryptographic credentials is disturbingly high.
Ultimately, it may be necessary to abandon destructive  con-
trol messages entirely, or reserve them for rare emergencies
and route them through a trusted moderator for cryptographic
authentication.

_i_h_a_v_e/_s_e_n_d_m_e _n_o_t _d_o_c_u_m_e_n_t_e_d

     The description of  the  ihave/sendme  protocol  is  so
vague  as  to  be useless to an implementor.  See the C news
documentation for an adequate description of  the  protocol.
The   description  in  RFC  1036  also  contains  an  error:
_r_e_m_o_t_e_s_y_s is not optional; given that there may be  multiple
message-ids  preceding it, there would be no way (other than
ad-hocery) to tell if the final argument were  a  message-id
or a _r_e_m_o_t_e_s_y_s.

_C_a_s_e-_s_e_n_s_i_t_i_v_i_t_y _i_n _m_e_s_s_a_g_e-_i_d_s

     RFC 1036 says nothing  about  whether  message-ids  are
case-sensitive or not, thereby punting the issue to RFC 822.
The RFC 822 rules are horrendously complex and no news  sys-
tem  has ever implemented them correctly.  (B 2.10 considers
them fully case-sensitive, which is wrong.  B 2.11 considers
them  fully  case-insensitive,  which is also wrong.  C News
gets the normal case right, but correct handling of  certain
obscure  RFC  822 constructs would require a complex parsing
algorithm; fortunately, the cases where this matters  appear
to be extremely rare.) Simplification appears necessary.

_N_e_w _h_e_a_d_e_r_s

     The B news _S_u_p_e_r_s_e_d_e_s: header needs to be documented in
the next revision of the RFC, as does the C news generalisa-
tion, _A_l_s_o-_C_o_n_t_r_o_l: (see _r_e_l_a_y_n_e_w_s(8)).

``_K_e_y_w_o_r_d_s''

     Section 2 says that a header begins with a  ``keyword''
as  the  header name.  RFC 1036 never defines what a keyword
is, and RFC 822 does not use  the  term.   ``Keyword''  here
must be considered an informal term with no precise meaning,
imposing no additional restrictions on header syntax.

     In particular, things  like  ``>from: foo@bar'',  which
causes  B  News  to  choke,  appear to be legal RFC 822 (and
hence 1036) headers.  (Before quoting lexical rules, such as
the requirement for balancing brackets, please note that the
822 lexical rules are context-sensitive.)



                       March 26, 1991





                           - 4 -


     Theoretical  legality  notwithstanding,  such   bizarre
header  names  are  dubious  and  unwise practice.  RFC 1036
probably should be tightened up to exclude them.






















































                       March 26, 1991


