jwz@lucid.com (Jamie Zawinski) (07/20/90)
I think it's totally wrong to disallow the editing of the From field. RFC822 says that From: is "the person(s) who wished this message to be sent" and if From: differs from the authenticated sending agent, then there must be a Sender: field which contains the authenticated agent. My interpretation of this is that editing the Sender: field shouldn't be allowed, but From: should. Also, the standard says that the From: field can contain multiple addresses, in the case of multiple authors. If forged mail is your concern, then just make sure that, if the From: field doesn't contain the mailbox of the logged-in user, that a correct Sender: field is added. The CMU CS mailer does this... When I had an andrew account at CMU, the main reason that I hated not being able to edit the From: field was that the Powers That Be decided that my middle name should be in the passwd file, but I didn't want it in the From: line. Sure, this is trivial, but it really annoyed me that I couldn't change it. If you're still not buying it, then how about making it a site-configuration parameter so that sites which don't have the user-maturity problems of a university don't have to live with this restriction? -- Jamie
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/20/90)
Excerpts from internet.info-andrew: 19-Jul-90 From and Sender fields Jamie Zawinski@ucbvax.be (1220) > When I had an andrew account at CMU, the main reason that I hated not > being able to edit the From: field was that the Powers That Be decided > that my middle name should be in the passwd file, but I didn't want it > in the From: line. Sure, this is trivial, but it really annoyed me that > I couldn't change it. OK, I wasn't one of the "Powers That Be" who made decisions about middle names and the like, but I was one of the people who made it impossible for you to edit the From field. Lets consider what you're asking for, precisely. I don't remember your middle name or login id, but say AMS was generating From: Jamie Lee Zawinski <jamie+@andrew.cmu.edu> What you're requesting is the ability to, yourself, change it to: From: Jamie Zawinski <jamie+@andrew.cmu.edu> Sounds reasonable. Technically, I'd interpret this to mean you have the freedom to at least change the RFC822 "route-phrase" to whatever you want. Now, does this change imply that a Sender field should be added? Probably not, if you don't change the actual mail routing -- most mailers show people the From field if both it and a Sender field exist, so you won't change what people actually SEE, and those in the know can still trace the mail from this From: line. So you don't really need to add a Sender unless the <jamie+@andrew.cmu.edu> part is chnaged, probably. However, the fact that most mailers show people the From: line is actually the heart of the problem. I'd contend that this means that user-supplied From: fields are A bad thing, because you can now produce anti-social efects that are likely to confuse many people, e.g. with From: Herb Simon <jamie+@andrew.cmu.edu> or, if you go further and force us to add a Sender field, you can confuse naive recipients who won't look at the Sender field even more: From: Herb Simon <simon@andrew.cmu.edu> (For those who don't know, Simon is CMU's Nobel Laureate, and that's NOT his real address.) The point is, if you can fool with your From: field, you can effectively lie about who you are to the majority of (relatively naive) people who might read your mail. To understand why we cared about things like this and thought our way through to this kind of policy, you should go back in time five years. We were about to give all of CMU's undergraduates access to the Internet, the first time anything like that had been done, to our knowledge. (Previously, network access was generally effectively restricted to researchers, grad students, and other "reasonable people" -- I don't know of any internet sites where this wasn't the case either by policy or by the practical reality of the number of available machines.) We were, to be blunt, scared stiff. DARPA was said to be watching closely, ready to pull the plug on CMU's Internet connection at a moment's notice. In consequence, CMU's CS mail gurus were watching the Andrew folks closely, ready to pull the plug on our connection to them, which is what gatewayed us to Internet, to protect their OWN Internet access. We thought long and hard about questions like, "how can we encourage more responsible use of the network?" We even talked to some psychologists & social scientists about this question. The result of all that effort was several features that hard-core UNIX users sometimes find annoying -- for example, the requirement of a Subject line, the absence of a BCC feature, the fact that you can't alter your From line, and so on. An important point to make is that IT WORKED. There have been a small handful of abuses, but much lower that what I've heard about at other sites where the number of students is much smaller. Even more notably, the bboard system at CMU is for the most part remarkable civilized (there are designated places on it where civilization is not expected, which helps) compared to other bboard systems, most probably because all posts have real (even authenticated!) names attached. Adding a few carefully considered restrictions to the system really seems to have paid off in the overall communication environment we created. (For a list of relevant restrictions & features, see the message "Social Experiments" in the standard AMS demo that comes on the Andrew tape.) I don't think these restrictions are all that hard to live with. The only case in which not being able to write your own From field really matters is where AMS is somehow generating an incorrect one, and for that you can always use Reply-To: -- indeed, that's what that headers is for. > If you're still not buying it, then how about making it a > site-configuration parameter so that sites which don't have the > user-maturity problems of a university don't have to live with this > restriction? ... or the other, similar restrictions alluded to above, I imagine. I wouldn't argue hard against such an option, but I wouldn't argue for it either -- I'm skeptical that just because people are computer professionals they're never going to be anti-social. -- Nathaniel