[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: Non-ASCII Internet addresses? (Was: Comment on the draft MIME Part 1 document)
- To: "t.l.hansen" <hansen@xxxxxxxxxxxxxxx> (Non Receipt Notification Requested) (IPM Return Requested)
- Subject: re: Non-ASCII Internet addresses? (Was: Comment on the draft MIME Part 1 document)
- From: "David Herron" <david@xxxxxxx>
- Date: Thu, 29 Apr 93 16:23:48 PDT
- Cc: ietf-822@xxxxxxxxxxxxxxxxxx (Non Receipt Notification Requested) (IPM Return Requested), ojarnef@xxxxxxxxxxxxxxxxxxxx (Non Receipt Notification Requested) (IPM Return Requested)
- Conversion: Prohibited
- Conversion-with-loss: Prohibited
- Encoding: 23 TEXT , 4 TEXT
- In-reply-to: Your message of 29 Apr 1993 18:11 EDT.<>
- Sensitivity: Personal
>One note of warning about whatever encoding scheme is devised:
>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.
<- David Herron <email@example.com> (work) <firstname.lastname@example.org> (home)
<- Where su-b-tlety is taken to an art!