A friend of mine was worried that the use of the =????= encoding of headers
would break UUCP mailers.
To my knowledge there is no "standard" for UUCP mailers. All I can say for
sure is that the implementation of UUCP I use is not bothered by these
headers. However, I have had to interoperate with all sorts of UUCP mailers
with all sorts of restrictions, and as a result I have implemented an
ever-increasing amount of special stuff to deal with them. I currently can
strip headers of comments, personal names, or both. As far as I know there is
no specific relationship to any particular characters involved here -- = and ?
are just as bad as anything else.
Is there any reason for this worry?
Probably so, but I think the set of guaranteed safe characters is the empty
set. On the other hand, it is a question for UUCP gateways to resolve. If they
have to strip personal names from headers to get things to work, well, that's
what will be done, and in fact in some cases must be done already.
(His solution: Use / - I know that this breaks some UUCP mailers if used
in the ADDRESS.........but not in Freeform text, I think....)
You are of course referring to the paranoid UUCP systems that think / means
that the address is a path, and try checking the filesystem to see if such
a file exists and is accessible. This is definitely a problem, and one which
is the UUCP community's problem, not ours. I don't propose to change RFC1148
to fix this...
I do have a problem with using / as our introductory character, however.
Specifically, I already see personal names that begin and end with this
character. This arises fairly naturally out of situations where a combination
of source routes and RFC1148 local-parts are used. RFC822 says that if you
have a source routed address enclosed in <>'s you have to have a personal
name phrase in front of it (this requirement was relaxed in RFC1123, but a
lot of mailers have not relaxed it yet). Many mailers, when faced with a
<> style address with no leading personal name phrase will use the local-part
of the address to build this missing phrase. Since / is often a leading
character in a local part it now becomes the leading character in the
phrase as well.
Of course the / can be combined with various other characters to make up
something that is unlikely to occur in a RFC1148 style local-part. But
this gets increasinly messy and I for one prefer the solution we have now.
Does anyone else have a more definitive statement about what UUCP
implementations will gripe about question marks?
Ned