Path: utzoo!attcan!uunet!snorkelwacker!tut.cis.ohio-state.edu!ucbvax!TRANSARC.COM!Craig_Everhart From: Craig_Everhart@TRANSARC.COM Newsgroups: comp.soft-sys.andrew Subject: Re: Dear Saint Andrew... Message-ID: Date: 20 Jul 90 14:01:56 GMT References: <0adTPN8B0TlkM4PEF=@zany.EuroPARC.Xerox.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 86 > Excerpts from internet.info-andrew: 19-Jul-90 Re: Dear Saint Andrew... > Lennart Lovstrand@Xerox. (15952+1) > Yes, but that work as well with XNS which has addresses looking like > "User:Domain:Organization" (which can include spaces). Sending > something to "Jane Doe:Research:ACME@localhost" will cause AMS to choke > with a syntax error, and putting the local part in double quotes will > make sendmail spit it back with unknown recipient. Ideally, I would > just like be able to write "Jane Doe:Research:ACME" and have sendmail do > the validation. Having said that, I'll have to agree that it's very > nice to have the UA do the validation before posting the message, but > what if we can't agree on what a proper address looks like? Really > ideally, then, I would like to be able to "teach" AMS how to do address > validation for a number of different protocols -- and local versions of > the aliases database, etc. Maybe there already is a way of doing this > using the White Pages, but I haven't had time to figure that out yet. > (Buy, AMS is even more complex than sendmail! ;-) Quoting the local-part shouldn't cause your sendmail to choke; it should know how to strip the quotes. You're right on, though, that AMS expects to live in an RFC822 world, and any attempt to veer from that causes trouble. In this case, you're right that it's not doing a very good job of allowing you to express these non-RFC822 addresses, and there's no current fall-back from that. Wow, another address-validation request: don't even bother parsing the addresses, but just leave 'em alone. Or parse them in some broader syntax, and try to handle the ones you recognize. > Nope, it's the other way around. The "From" address may be specified by > the UA, and if not authentic, must be supplemented with a "Sender" by > the mail system, indicating the authenticated sender of the message. > See RFC822 section 4.4.1 and 4.4.2. It's still not nice to send From: lines that don't at least parse. You might want to add Reply-to: in case the From: is parseable but unreplyable, for example when your friend without a computer account wants to send a piece of mail. Old Tops-10 RdMail used to add such a Reply-to: field automatically, when From: was unreplyable. I enjoyed reading Nathaniel's blurb on ``social experiments'' and can echo most of his sentiments. Again, though, I now believe that one can write a socially-responsible MUA while allowing users to change the From: line (in some ill-specified ways). It's just a matter of work and taste. > Even if there are many ways something may go wrong in a distributed FS > environment, it seems to me that trying to make the applications > programs compensate to compensate for this would be to attack the > problem on the wrong level. I think Butler Lampson disagrees with this, in the advice-for-system-designers paper of about 1983; he claims that failures should be made visible end-to-end, so that after all lower-level recovery attempts have failed, the application, and eventually the user, will still have to cope with an underlying failure. TCP was a reliability improvement over UDP partly because it implemented a different abstraction. The AFS story is that it is a distributed file system programmed to the Unix system call interface, and indeed each call can separately fail. You could imagine another interface behind which many failures could be handled, and recovered, for you, but it's difficult to make incremental changes to the syscall interface to achieve that. > I'm confused. Do you by "seen" mean the same as "read"? Because I > thought each individual message was flagged when I read it, which would > allow me to have "gaps" of unseen messages in a folder. At least, so it > appears. Here's a difference between folders to which you have update access (like your personal ones) and folders to which you have only read access (like public bboards). If you have update access, sure, you own the has-this-message-been-examined bit in the .MS_MsgDir file, and those bits are set independently. If you don't have such access, the state of those bits isn't written back to that file, and the only record (from session to session) of which messages you've seen is the high-water-mark. > Right, although a "From " line doesn't imply anything about UUCP -- it's > just the convention for separating messages in the user's > /usr/spool/mail file. A ``From '' line is more than the separator for /usr/spool/mail/eeeee messages; it's the delivered copy's record of the message envelope. That function it shares with RFC822 Return-path:. Craig