<< Most unix mail systems prohibit the following set of characters in mail
<< names
<< `;&|^<>()
<< Some prevent even more characters.
<< These characters are all special to the shell and could potentially be
<< used to create a security hole.
< Any such mail systems which do so are *broken*. Instead of passing mail
< addresses through shell command lines (which is where this bug arises)
< they should most definitely be passed only through a secure path. One
< secure path may well be writing a function which quote's (*properly*) the
< string for safe pasage through the shell. But this will depend on
< knowledge of the particular shell which might well change over time.
<
< Yes it is way convenient to pass addresses through command lines like
< this. That is not the point. Proper and correct processing of e-mail is
< the point. If that means you cannot do certain things, then so be it.
Actually, it is NOT the mail commands which are typically broken, but
instead the transport commands which are used underneath the mail commands.
And those cannot necessarily be controlled by the mail system. So the mail
systems instead must prevent the characters from being passed on.
Do I like it? Not at all! And none of the mail systems I have written use
the shell to pass things on. But I still must live in the world of reality,
so I must also work within the constraints of the systems, and hence cannot
take the luxury of calling those mailers broken.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony