indra@ashirvad.amd.com (Indra Singhal) (11/20/90)
Office automation packages like Applix's Alis provide a feature that
tells the sender whether a mail message was viewed, filed or deleted by
the receipient and the time and date the action was taken. This has
become a requirement now that our company is moving towards automation
and a paperless office.
Not everyone uses Alis. If elm could send such a 'confirmation on open'
message back to the sender, perhaps, based on the presence of an
X-Confirm: header line, we could push elm as the corporate standard MUA.
How difficult would the implementation be? Would the development team
consider it for a future release? How useful would this feature be to
the rest of the user community?
Thank you.
--
iNDRA | indra@amd.com or {ames apple uunet}!amd!indra
| (Indra Singhal) (408) 749-5445; Advanced Micro Devices
| MS 167; Box 3453; 901, Thompson Pl., Sunnyvale, CA 94088syd@DSI.COM (Syd Weinstein) (11/20/90)
indra@ashirvad.amd.com (Indra Singhal) writes: >Office automation packages like Applix's Alis provide a feature that >tells the sender whether a mail message was viewed, filed or deleted by >the receipient and the time and date the action was taken. This has >become a requirement now that our company is moving towards automation >and a paperless office. >Not everyone uses Alis. If elm could send such a 'confirmation on open' >message back to the sender, perhaps, based on the presence of an >X-Confirm: header line, we could push elm as the corporate standard MUA. >How difficult would the implementation be? Would the development team >consider it for a future release? How useful would this feature be to >the rest of the user community? This is a sticky issue. I have had lots of requests for it, and have been one of the major stumbling blocks to its implimentation. Let me defend my position. Lets make a comparision versus Electronic Mail and Paper mail first. In paper mail, normal mail has no audit trail, ie, you get it and read it and no one knows wheither or when either happened. Normal electronic mail is just like this. In paper mail their is, in the US at least, a more expensive option called Return-Receipt-Requested, in which the post office has you pay a fee and affix a card to the item which is mailed back to you showing when it was delivered. For an additional fee it will also show where and to whom delivered. Electronic mail, using most full feature MTA's, such as MMDF, sendmail and smail support the idea of the 'Return-Recept-To:' header which will tell the sender that the letter was delivered, and when it was delivered. This is like the US Postal Services green post card. However, their is nothing to say I ever opened your piece of mail and read it, perhaps it was signed for and I just threw it out. I could let it sit for days or weeks and then read it. With the concept of the MUA automatically telling you when and what I did with your mail, you have implimented a 'computer watchdog' to keep an eye on me and 'reduce' my privacy rights. This is 'Big Brother'ism and it bothers me. (Personal opinion) One method of reducing this intrusion is to have the MUA (elm) ask for permission to send a response, such as in: 'You have just saved a message on which the sender has requested acknowledgement of the save Should I send an acknowledgement of the save for you?' Similar messages could be asked for read/etc. The exact header to use needs to be discussed between all the MUA's and the author really should file an RFC about it. However, using an X- header temporarly is not out of the question. Technically: Its not that difficult. What it entails is placing more flags on the Status: line to indicate what replies have already been sent. Preventing multiple replies is however a more difficult problem. Their are many ways the mailbox could be left without updating the Status: lines thus loosing the infomation that a reply was sent. Also if other MUA's rewrite the status lines using only flags they understand, then the flag info could be lost if the user uses a combination of MUA's. However, no one has yet to propose or file the RFC, nor has anyone really discussed the privacy issues besides myself and one or two people in personal correspondence with me. Am I alone? Note, at best, I would make it an elmrc and/or Configurable option, such that it could be disabled by a user or site. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
phil@wubios.wustl.edu (J. Philip Miller) (11/20/90)
In article <1990Nov19.182044.14572@DSI.COM> syd@DSI.COM writes: > >Electronic mail, using most full feature MTA's, such as MMDF, sendmail >and smail support the idea of the 'Return-Recept-To:' header which >will tell the sender that the letter was delivered, and when it was >delivered. This is like the US Postal Services green post card. > One of the differences in e-mail is that there is no requirement that the MTA on the recepient's system honor the Return-Recept-To: header. Thus unlike the USPS green card, if you send it out you cannot be guaranteed that it will be honored. I still think it is a good idea since frequently you will be using it with a correspondant that you communiate with frequently so you will know, up front that her/his system does or doesn't support it. >However, their is nothing to say I ever opened your piece of mail and >read it, perhaps it was signed for and I just threw it out. >I could let it sit for days or weeks and then read it. > but you can't say you did not receive it. It begins to localize the responsibility for non-response. This is why it is used for important commercial transactions. >With the concept of the MUA automatically telling you when and what I >did with your mail, you have implimented a 'computer watchdog' to keep >an eye on me and 'reduce' my privacy rights. This is 'Big Brother'ism >and it bothers me. (Personal opinion) > Well, we utilized the facility heavily in PROFS and RICE/MAIL on IBM CMS systems and I never heard anyone raise that issue. Perhaps requiring you to use a MUA that supported it, or requiring you to turn on the option might be objectionable, but it seems to me it is a lot like running finger on a network - it is true that there are privacy and security issues involved, but it is sure handy to have. At least let those users who want the facility the option of having it available. >One method of reducing this intrusion is to have the MUA (elm) ask >for permission to send a response, such as in: 'You have just saved >a message on which the sender has requested acknowledgement of the save >Should I send an acknowledgement of the save for you?' > I don't think 'save' is an important event, I leave lots of stuff in my mail spool. >Similar messages could be asked for read/etc. The exact header to use >needs to be discussed between all the MUA's and the author really should >file an RFC about it. However, using an X- header temporarly is not >out of the question. > then lets do it! >Technically: Its not that difficult. What it entails is placing more >flags on the Status: line to indicate what replies have already been sent. >Preventing multiple replies is however a more difficult problem. Their >are many ways the mailbox could be left without updating the Status: lines >thus loosing the infomation that a reply was sent. Also if other MUA's >rewrite the status lines using only flags they understand, then the >flag info could be lost if the user uses a combination of MUA's. > In my CMS experience, when things went wrong, the end result was duplicate acknowledgments. I think the technical issues that get raised really relate to the next level of complexity. If you have this facility, then the next thing the users will want to do is to log the return requests and the receipt of the acknowledgments so that they can display (and possibly resend) mail that has not been received. >However, no one has yet to propose or file the RFC, nor has anyone >really discussed the privacy issues besides myself and one or two >people in personal correspondence with me. > no RFC is needed. RFC 822 povides for the registration of new header types - although it has never been done [or at least had never been when we checked it several years ago with respect to this very issue], there is no reason why it can't be done. >Am I alone? > I hope so :-) >Note, at best, I would make it an elmrc and/or Configurable option, >such that it could be disabled by a user or site. > I find no problems whatsoever with that. -phil -- J. Philip Miller, Professor, Division of Biostatistics, Box 8067 Washington University Medical School, St. Louis MO 63110 phil@wubios.WUstl.edu - Internet (314) 362-3617 uunet!wuarchive!wubios!phil - UUCP (314)362-2693(FAX) C90562JM@WUVMD - bitnet
scs@lokkur.dexter.mi.us (Steve Simmons) (11/20/90)
syd@DSI.COM (Syd Weinstein) writes:
I was going to requote Syd in detail here, but that's too tedious.
Reread his post if my responses make no sense, it was less than 24
hours before this response.
Syds comments are correct within a limited sense. He compares email to
the USPS, wherein your receipt, reading, and action on a letter are
completely up to you. The worst that can happen is a certified letter
which you can either refuse or accept and either way the recipient
finds out.
If the proposed return receipts, etc, were mandated upon the recipient,
I would agree fully with Syd. But there is a way to deal this issue
without imposing privacy loss upon uninvolved 3rd parties.
In a corporate environment, one often wants to assign tasks to a
specific person. One would like to define the task, assign it, get
acknowledgement back, and then get confirmation upon completion of
task. If one has assigned or been assigned tasks, it would be very
nice to have a computer tell you what you're currently under the gun
for.
Yes, this is ranging far afield of simple email and into a corporate
management tool. That's what people want with return receipts, acks,
etc. The fact that this is surfacing in a discussion of email is
somewhat misleading -- email is only a piece of that management tool.
Email between private parties is quite a different thing from email in
a corporate environment, where there are lines of authority
acknowledged by both sender and recipient. In a corporate environment
one may quite validly wish to have automatic acks, forced replies, etc,
etc. [[If you don't like your employer doing such things with elm,
recall they could require you to use PROFS. Definately a fate worse
than death. Those who wish to discuss fascism, trust, etc, may feel
free to do so. Please put it in your header line so I can kill it.]]
We have been having serious discussions about just such a tool at work,
and one of the mechanisms under discussion is to extend elm by use of
Xheaders. One issue I continually harp on is making sure email to
folks outside of our corporate umbrella maintains exactly those privacy
considerations Syd mentions. We don't have anything like a finished
design, but it's clear it will require some sort of X-authoritydomain
header. This would be the 'authorization' field, saying what level of
authority the sender is working in. So if I send you a message with
Xauthoritydomain: Industrial Technology Institute (foo@iti.org)
Xaction-required: confirm read to sender, htruman
Xaction-required: reply by 11/25/90 to sender, dbcooper, htruman
in the headers, one of several things would happen:
(a) If you are under the ITI authority domain, you have no choice --
the ack goes out saying you read the message as soon as you look
at it. The ack goes to the sender and to `htruman'. You should
be informed this is happening. You should also be informed of
upcoming requirements, such as the 'reply by' action.
(b) If you are not under the domain, you will be asked if you want
to ack, if you want to postpone the ack, or if you want to
permanently ignore the ack. The ack goes out as described in (a).
I suppose there ought to be an auto-ignore setting for this, but
I'd kind of like to know who's trying to track me.
Note one hitch -- you *must* be using elm (or some other MUA which
handles the Xa* headers) or nothing happens in the way of response.
Elm would be site-configured to respect authority domains, probably
with a flat file that wouldn't require rebuilding elm to change
authority domains. We've talked about modifying the MTAs to do this,
and I've pretty much convinced them that's a bad idea.
The address on Xauthoritydomain is where acks are sent to. This is an
alias for a program which maintains the actions/requirements/acks
database. It's the only way to handle it across multiple hosts/sites.
The db keeps everything central, making sure only one ack is done,
etc. Some sort of cron-based reporter would handle simple passing on
of acks, etc, while the truly curious could interrogate it
interactively. If the recipient doesn't complete the reply by the
given date, a nag message is sent to the original person plus the others
on the 'reply by' list.
There's lots more stuff required to make this work right (which means I
disagree with Syd about the difficulty), but you get the general idea
of how it might be implemented seamlessly and reliably.
What's the odds on this being implemented at ITI? Pretty slim, IMHO.
ITI is very good about talking about such things, very poor at putting
any resources into them. I just wanted to get these ideas out and show
that there is a compromise which gives those desired and useful
features but respects Syds legitimate concerns.
--
"When your neighbour loses his job, it's a slowdown; when you lose your own
job, it's a recession; when an economist loses his job it's a depression."
-- "Six Ways To Define A Recession", The Economist, Nov. 3 1990.christo@bcarh149.BNR.CA (Mark Christopher) (11/23/90)
In article <1990Nov19.182044.14572@DSI.COM>, syd@DSI.COM (Syd Weinstein) writes: |>Electronic mail, using most full feature MTA's, such as MMDF, sendmail |>and smail support the idea of the 'Return-Recept-To:' header which |>will tell the sender that the letter was delivered, and when it was |>delivered. This is like the US Postal Services green post card. |> |>However, their is nothing to say I ever opened your piece of mail and |>read it, perhaps it was signed for and I just threw it out. |>I could let it sit for days or weeks and then read it. |> |>With the concept of the MUA automatically telling you when and what I |>did with your mail, you have implimented a 'computer watchdog' to keep |>an eye on me and 'reduce' my privacy rights. This is 'Big Brother'ism |>and it bothers me. (Personal opinion) I agree with both viewpoints that have been raised in this discussion thread. Syd's comments bring to mind a 'previous life', where a certain prof had the most annoying habit of putting the X-reply-to: in every message he sent. Ahh, but this was on an ibm, and the 'mail' was just delivered as a file to your reader (how quaint) and the reply message was actually generated by the MUA. I hated this 'big brother'ing with a raging head of a thousand suns so when I received messages, I checked if they were from him. If the messages were from him, I looked at them via 'rl' bypassing his beloved acknowledgement messages. (He did occasionally ask me why he didn't always get acks. I usually blamed it on a buggy mailer or something like rscs didn't guarantee delivery... :-) However, in a corporate environment, it is sometimes useful to know if a particular message has been read. However, simple acknowledgements just don't cut it in my opinion. I would find it far more useful to have a certified message (or confirmed-delivery message, whatever name you like) to be put in a special mailbox (or maybe just left in the spool file) and have the status flagged as sent but not acknowledged. And when the ack came it, the message would be flagged as having been seen at a certain time. Manually co-ordinating message ACKs is a waste of time and b o r i n g... -- Mark Christopher christo@bnr.ca Bell-Northern Research ..!uunet!bnrgate!bmerh471!christo Just adding my thoughts. There, now my brain is empty again.
s887212@minyos.xx.rmit.oz.au (Stephen Riehm [Romulis]) (11/24/90)
following on this thread.. I would like to describe some mail systems available on other machines... you can chose which if any are appropriate to this discussion. On our old Cyber 760 (now due for the great cyber space in the sky :-( ) the mail system was entirely internal.. this allowed for the following feature. When you sent mail to a person it was registered in the mailing system. After you had sent it you could ENQUIRE your outgoing mail.. and you would be given a list of mail not yet received at the other end. When the mail was read it disappeared from this list. It was a simple and effective scheme available to everyone. It also gave you the option of cancelling any mail that had not yet got to its destination. This sort of system COULD be implemented on the UNIX networks, however it would require Mandatory recognition of receipt from every machine. Obviously this is not ideal.. but it is a solution. As for this Big Brother Issue, this method is passive.. those that dont care about they're mail dont get bothered.. and those that do want to see if their URGENT mail has got through have a mechanism to use should they want it. Also.. depending on your viewpoint.. the mail belongs to both RECEIVED and SENDER. therefor both parties should have certain rights available to them.. I dont see a simple recognition of receipt as being 'BIG BROTHER'ish. Time stamps are not necessary either.. all you need to know is that the mail has or has not been read. Those who are familiar with the NOS NOS/VE etc systems as provided by CDC/Miden will recall that their mail system gives the user the option for automatic receipt of receipt (?!). This option may not be desired by all but it is an OPTION. In defense of the poor defenseless receiver, there is always the option of filtering your mail.. this would mean that you could bounce it back to the sender.. automatically saving it to a file etc etc. if the sender has asked for recognition of receipt they should get it as soon as the filter has finished saving this file for you.. INSTANT recognition.. perfect record.. and NO EFFORT on your behalf! ============================================================================ Romulis [Stephen Riehm] Royal Melbourne Institute of Technology, (124 Latrobe St., Melbourne.) s887212@minyos.xx.rmit.oz.au Australia. My 2c + 15% Tax + 7% inflation * 6 - the number you first thought of, Worth! ======================< Insert Usual Disclaimer >===========================
rudolf@curano.acadch.com (Rudolf Kuenzli) (11/30/90)
In article <1990Nov19.182044.14572@DSI.COM> syd@DSI.COM writes: >an eye on me and 'reduce' my privacy rights. This is 'Big Brother'ism >and it bothers me. (Personal opinion) Syd, I share your opinion entirely. Even when I got a registered letter from the post office, the sender would know if or when I did read the letter. If such feature is put into it must be configurable for receiver and site. What would happen when sending such mail to sites with other mailers? -- Rudolf the Magician In real life: Rudolf Kuenzli uucp: ...uunet!autodesk!adeskch!rudolf Internet: rudolf@curano.acadch.com ...chx400!adeskch!rudolf rudolf@adeskch.uu.ch