Peter Sylvester +49 228 303245 <GRZ027@DBNGMD21>
Wed, 08 Apr 87 11:08 CET
|
1: We do not have an RFC822 network.
On most systems any user can create any straem of bytes and
transfer that to LISTSERV or any other server.
Once people really accept that fact they will no longer complain
about "What kind of funny header is this and that?" but rather
try to make their systems more tolerant.
2: There is no good way to decide what piece of mail should be
considered as RFC822 mail and what not.
There are two possibilities:
a) Take everything and try to make an incoming bytes stream
to RFC822 without looking to other "external" indicators
as FORMS, CLASS etc.
b) Use certain indicators that say either: This is supposed
to be RFC822 (then you simply REJECT files if they are not),
CLASS M FORMS MAIL (FILENAME?)
or when it says "this is not RFC822" that you don't touch
the contents and NEVER use MAIL for delivery.
REDIST?
A NETDATA DATA SET to be distributed is NOT RFC822 at all.
3: There is one exception in the network which is "almost" RFC822
IBM NOTE. This thing should be considered special and modified.
4: Some people at native MVS systems have a tendency to create
these funny headers where not even a colon ends the FROM etc.
The question is in this case: How far should the error propagate?
When MAILER and LISTSERV continue changing the "CLASS" and
FILENAME FILETYPE to "the defacto mail standard :-)" or whatever
they should screen that stuff. If LISTSERV just distributes the
data as is to recipients in the net (as with "REDIST")...
A lot of heuristics is necessary to make garbage to something
usable, espcially when the usable stuff looks like garbage. :-)
5: The implementation stategy should be that in any case a
NEW HEADER is constructed, and as much elements from the old
header should be copied into that new header (maybe modified).
The remaining stuff should simply left as a beginning of the
body (I prefer no loss of information).
Peter
|
|
|