grahamd@otc.otca.oz.AU (Graham Dumpleton) (02/08/90)
We are running AMS on our system but since only a limited number of users have any sort of workstation running X only a few are actually using the messages program. Because of this I have set the AMS_UsersHandleFormatting to 'no', meaning that whenever anyone sends a message with formatting to someone in the local domain they are asked if they wish to send with formatting etc. Now I can make things better by using the $forceformat option in individuals .AMS_aliases files so that if they do send formatted mail to Andrew users then they don't get asked about formatting etc. The problem with this is that each person has their own list of who is currently using Andrew, meaning that if someone else starts using Andrew it has to be added to each individuals aliases file. My question is, can I have a system wide AMS aliases file which I can put $forceformat lines in for each user using Andrew, and then have this included in individuals aliases files using and include statement or for messages to check it directly. I have looked in various help files but didn't find anything which helped to answer this. Also we are having trouble getting people to use AMS, currently they use the MH mail system and a number of users are worried about the fact that once mail is read into AMS its name gets munged and its not easy to get it back out into MH. I know about cui and that it could be used as a replacement for MH on tty terminals but it is no where near as easier to use as MH or vmail which runs on top of MH. Is there a way which AMS can look at the same files as MH, not munge names and use its files for keeping track of which items have been read etc. Graham Dumpleton (grahamd@otc.otca.oz.au)
tom@ICASE.EDU (Tom Crockett) (02/08/90)
> *Excerpts from info-andrew: 8-Feb-90 System wide AMS alias file Graham* > *Dumpleton@uunet.u (1709)* > My question is, can I have a system wide AMS aliases file which I > can put $forceformat lines in for each user using Andrew, and then have > this included in individuals aliases files using and include statement > or for messages to check it directly. Our environment sounds a lot like yours. We would also be interested in a site-wide .AMS_aliases file which would be scanned along with that of individual users. _Tom Crockett_ *ICASE* Institute for Computer Applications in Science and Engineering M.S. 132C e-mail: tom@icase.edu NASA Langley Research Center phone: (804) 864-2182 Hampton, VA 23665-5225
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (02/08/90)
There's not currently a system-wide alias file, but I too have come to realize (since leaving the more homogeneous CMU environment) that it would be a very useful thing to have, for precisely the reason you mentioned. It should be pretty easy; at some point, I might even do it and send CMU a patch. As for the MH compatibility question -- there is a feature in AMS (the "alien tree" feature) that was designed for AMS/MH/Netnews interoperability, but it has not been heavily used, and probably can be counted on to be a little buggy. I'm not sure if it is documented at all, but I know a few people have tried it. Perhaps one of them can comment on whether it works, and how well. -- Nathaniel
Craig_Everhart@TRANSARC.COM (02/09/90)
Congratulations on getting AMS installed to the point where this is even an issue! About the $forceformat and global AMS-aliases thing. No, there's no current provision for a global .AMS_aliases file, or for any other global (per-recipient) information about whether a recipient is interested in accepting ATK-formatted messages. It's not a bad idea, though; certainly it's not a bad idea to have a centrally-located file describing the formatting preferences of addresses within a community. (Now, you could do it by having a global name that was always checked, or building an ``include'' file mechanism into the .AMS_aliases reader. If the former were done, so that all users always used the contents of the globally-named file, I'd recommend against using it to define name aliases, in favor of using it only for global $forceXXX information. There's already a /usr/lib/aliases to handle name aliases, and that's what sendmail will use, as well.) There are other problems with your current approach--for instance, if you send mail to two recipients, one of whom is listed as format-OK and one not listed (and thus in format-not-OK mode), the sender still has to decide whether both recipients get a formatted version or both get non-formatted mail. Did you know that if you use CUI or VUI to read mail, that formatting in messages is stripped out before the mail is displayed? You might experiment with setting AMS_UsersHandleFormatting to ``yes,'' and letting users use CUI or VUI to de-format messages before showing them on screens (or printing terminals, for that matter). Admittedly, CUI and VUI are kinda clumsy, and MH doesn't know a thing about ATK-formatted messages. Maybe it won't matter. There is some MH-compatibility stuff in AMS (the message server library) that was just getting a bit of polish last November. It allows AMS to use something of a native-MH set of messages, but it was originally designed more for public folders than for personal mail folders. I'm sure that Nathaniel will chime in here. Back to you, Nathaniel. (Cut here.) Craig Everhart
janssen@parc.xerox.com (Bill Janssen) (02/09/90)
For those of us who have users with GNU Emacs "rmail" bound to their
brains, here's an elisp function to display an ATK mail message from
rmail:
---- Enclosure ----
(defun rmail-show-message-as-andrew-object ()
"View andrew mail message from RMAIL"
(interactive)
(if (or (eq window-system 'x)
(getenv "DISPLAY"))
(let (from to date subject body body-begin msg-end)
(save-excursion
(save-restriction
(setq msg-end (rmail-msgend rmail-current-message))
(widen)
(goto-char (rmail-msgbeg rmail-current-message))
(forward-line 1)
(narrow-to-region
(if (= (following-char) ?0)
(progn (search-forward "\n\n" (rmail-msgend rmail-current-message)
'move)
(point))
(progn (search-forward "\n*** EOOH ***\n" (rmail-msgend
rmail-current-message)) (point)))
(rmail-msgend rmail-current-message))
(setq to (mail-fetch-field "to" t))
(setq from (mail-fetch-field "from" t))
(setq date (mail-fetch-field "date" t))
(setq subject (mail-fetch-field "subject" t))
(goto-char (rmail-msgbeg rmail-current-message))
(search-forward "\\begindata" msg-end 'move)
(if (= msg-end (point))
(setq header nil)
(progn
(forward-line 0)
(setq begin (point))
(forward-line 2)
(setq header (buffer-substring begin (point)))))
(if header
(setq body-begin (point))
(progn
(goto-char (rmail-msgbeg rmail-current-message))
(search-forward "\n\n" (rmail-msgend rmail-current-message) 'move)
(setq body-begin (point))
))
(setq body (buffer-substring body-begin msg-end))
)
(let ((buffer (get-buffer-create "*Display Mail As Andrew*")))
(set-buffer buffer)
(erase-buffer)
(insert-string (or header "\\begindata{text, 1}\n\\textdsversion{12}\n"))
(insert-string "\\template{messages}\n")
(insert-string (format "\\bold{Date:} %s\n\n" date))
(insert-string (format "\\bold{From:} %s\n\n" from))
(insert-string (format "\\bold{To:} %s\n\n" to))
(insert-string (format "\\bold{Subject:} %s\n\n\n" subject))
(insert-string body)
(insert-string "\\enddata{text,1}\n")
(write-file "/usr/tmp/mail-message-as-andrew")
(setq buffer-file-name nil)
(shell-command "ez -d /usr/tmp/mail-message-as-andrew; rm
/usr/tmp/mail-message-as-andrew")
)))
))
---- Enclosure ----nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (02/10/90)
Another thing that would be *really* useful in this regard would be for some MH hacker to modify MH so that it could properly display ATK-format mail. This would be remarkably easy -- the "unscribe" module of Andrew is very small and self-contained, and could be linked into MH and applied to any mail with an appropriate "Content-Type" header before displaying it. Any interested MH hackers out there? (Actually, this could apply to any non-Andrew mailer. It would probably add about 40K to the mailer, and would make it display ATK-format mail nicely.) The mode in AMS for MH/netnews compatibility is not-ready-for-prime-time. I keep intending to beat on it in my copious spare time, but frankly I'm having too much fun here at Bellcore (experimenting with extended models for email functionality) to spend a lot of time worrying about this sort of stuff. I repeat, however, my long-standing offer of advice and assistance to anyone who wants to work seriously on making these compatibility modes work well. (They're currently something like 90% solutions, but there are a few missing details.) I do wish I had found a few extra weeks to work on the compatibility before I left CMU, but it just didn't work out that way. -- Nathaniel