functionally a very minor issue, but toward the squashing of future bugs =
and making the code more bulletproof, I'd like to suggest a
change to the handling of the first line of smtp message files.  This =
suggestion also applies to other places where strtok() is
used.

SMTPSubmitPackedFile() (in SMTPSvr.cpp) in v1.16 (indirectly) uses =
strtok() to extract the individual fields of the first line of
message information.  Philosophically, this is a bug.  strtok() is =
intended to be used to extract tokens from a string, not to
separate delimited fields in a string.  (The difference is that text =
tokens can be separated by multiple occurrences of delimiters;
with delimited fields packed in a string, each delimiter is =
significant). =20

This does not currently cause adverse effects because all of the fields =
that xmail puts into that line are always non-null; however,
if possibly-null fields are added to that line in future versions (or if =
someone adds a possibly-null field in their own mods to
xmail), the existing code fails.  As an example, I have to work around =
this because I add the (possibly-empty) result of any reverse
DNS that is performed (SMTP-RDNSCheck) to the message file so that it =
can be added to the Received: header of messages.  (This
information is commonly seen in Received: headers, but none of the xmail =
Received: formats include it).  In other places the extant
behavior might be desirable so that the inadvertent appearance of two =
adjacent tabs in a .tab file, for example, is handled without
error.

Of course, I realize that the fixing of bugs takes precedence over =
making the code textbook-accurate, but please consider making a
distinction between handling these two very different types of =
delimiters in the code.



-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]

Reply via email to