jpp@slxsys.specialix.co.uk (John Pettitt) (06/09/89)
Is the `Return-view-to:' header legal ? If so what should a user agent do with it ? > X-Mailer: SCO Office Portfolio (version 1.0) > To: jpp > Subject: test > Return-receipt-to: jpp > Return-view-to: jpp > From: jpp While I'm on the subject what whould I do with return receipt tickets from dead `non-domain' mailers (like sco op) ? John Pettitt postmaster@specialix.co.uk -- John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR {backbone}!ukc!slxsys!jpp jpp@slxinc.uucp jpp@slxsys.specialix.co.uk Tel: +44-1-941-2564 Fax: +44-1-941-4098 Telex: 918110 SPECIX G >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
dheller@cory.Berkeley.EDU (Dan Heller) (06/12/89)
In article <3990@slxsys.specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: > Is the `Return-view-to:' header legal ? If so what should a user > agent do with it ? a User Agent? Don't you mean the Transport Agent? User agents don't deal with things like retrun-reciept-to, etc... MTAs to. but nevertheless, this is something I haven't heard of before, so I won't venture a guess as to what to do with it. However, I might shed some light on the origin of the problem. > > X-Mailer: SCO Office Portfolio (version 1.0) This comes frokm sco's funky little Office Automation package they developed. Mail was written without domains in mind or the foresight of a networking community. That is, this mailer does not handle mailing outside of sco very well. If it successfully delivers mail out of sco, the headers are outrageous -- it only allows one address on the To: header and it has all the names, address, domains, hostnames, pathes and sometimes even comment all scrunched together with a wild assortment of bangs and at's and the like interspersed between them. I once got a header: To: island!michaelb@island.sun.argv.uucp!jamescb.sco.maui@heller.dan.com when it was supposed to be addressed to: To: sun!island!maui!argv (dan heller), jamescb@sco.com, michaelb The good side of this is that sco does has a growing community of mush users within the company. Dan Heller <island!argv@sun.com>
jpp@slxsys.specialix.co.uk (John Pettitt) (06/13/89)
From article <14552@pasteur.Berkeley.EDU>, by dheller@cory.Berkeley.EDU (Dan Heller): > In article <3990@slxsys.specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: >> Is the `Return-view-to:' header legal ? If so what should a user >> agent do with it ? > a User Agent? Don't you mean the Transport Agent? User agents don't deal > with things like retrun-reciept-to, etc... MTAs to. but nevertheless, this > is something I haven't heard of before, so I won't venture a guess as to what > to do with it. However, I might shed some light on the origin of the problem. > >> > X-Mailer: SCO Office Portfolio (version 1.0) > This comes frokm sco's funky little Office Automation package they developed. > The good side of this is that sco does has a growing community of mush > users within the company. > Dan Heller <island!argv@sun.com> The Return-view-to: is by definition a user agent problem. The idea is it sends a receipt when the user reads (views) the mail, not on final transport stage. The reason for my original posting is that we have just installed SCO OP for our non-technical users and they are sending mail using the OP mailer (which for all it's faults is not bad for non technical users). One of the `features' of the op mailer is that is can generate `view' receipts and track which ones you have had back so far. My problem is that the technical users all use mush (what else ? :-) and now I have to hack support for view receipts into mush. I would like to do a good job of it, I.E. conform to any standards that may be applicable and be compatible with the rest of the world. So the orgiginal question remains: What should a mail user agent do with `Return-view-to:' ? John Pettitt postmaster@specialix.co.uk -- John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR {backbone}!ukc!slxsys!jpp jpp@slxinc.uucp jpp@slxsys.specialix.co.uk Tel: +44-1-941-2564 Fax: +44-1-941-4098 Telex: 918110 SPECIX G >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
dheller@cory.Berkeley.EDU (Dan Heller) (06/14/89)
Note, I added comp.mail.mush and comp.unix.xenix to the newsgroups list ... In article jpp@slxsys.specialix.co.uk (John Pettitt) writes: > From article by dheller@cory.Berkeley.EDU (Dan Heller): > > In article jpp@specialix.co.uk (John Pettitt) writes: > >> Is the `Return-view-to:' header legal ? If so what should a user > >> agent do with it ? > > a User Agent? Don't you mean the Transport Agent? User agents don't deal > > with things like retrun-reciept-to, etc... MTAs do. but nevertheless, this > > is something I haven't heard of before, so I won't venture a guess as to what > > to do with it. However, I might shed some light on the origin of the problem. > >> > X-Mailer: SCO Office Portfolio (version 1.0) > > This comes from sco's funky little Office Automation package they developed. > > The good side of this is that sco does has a growing community of mush > > users within the company. > > Dan Heller <island!argv@sun.com> > > The Return-view-to: is by definition a user agent problem. The idea is it > sends a receipt when the user reads (views) the mail, not on final transport > stage. The reason for my original posting is that we have just installed SCO > OP for our non-technical users and they are sending mail using the OP > mailer (which for all it's faults is not bad for non technical users). > One of the `features' of the op mailer is that is can generate `view' receipts > and track which ones you have had back so far. My problem is that the > technical users all use mush (what else ? :-) and now I have to hack > support for view receipts into mush. > I would like to do a good job of it, I.E. conform to any standards that > may be applicable and be compatible with the rest of the world. So the > orgiginal question remains: > What should a mail user agent do with `Return-view-to:' ? > > John Pettitt > postmaster@specialix.co.uk As you've described it, this is a very potentially buggy thing to do: the UA should not be involved. However, let's address the issue anyway... What should the UA do with Return-View-To: headers? The same as what the MTA does with Return-Receipt-To: headers -- mail back to the person or address listed on the header. This means one of two things has to happen -- either the address on the header has to be complete and guranateed to work as it is sent by the originator of the message, or the MTAs in the path have to know about and modify this header en route. The latter, of course, is impossible since there is no specification for this in the RFC. It also implies the same problems that Return-Path: and From: headers have --that the address might be invalid due to bad or inconsistent MTAs (see previous discussion about rewriting From: lines in comp.mail.misc). Therefore, this new option must be restricted to a local (LAN) environment. It's somewhat easier to implement this way, but many problems still exist. As for the header and it's content, just have the user's login name only listed: Return-View-To: argv When the UA decides to reply to the user, it simply replies to the address listed -- the MTA will resolve the login name (via aliases file or whatever). Seems simple enough ... but this won't work anyway. Consider the following arguments. If the UA is responsible for this, then consider what happens when the user reads a message: a reply is now automatically sent, the message is flagged for having read the message and for having been replied to, but the user e(x)its out of the mail program not updating anything. There is no way to save the fact that the message has been read or replied to. Ok, let's hypothetically solve that problem by forcing updates for such situations. 'x' will now update -only- those messages that have been replied to. What happens if the folder is read-only? The forced updated cannot happen. Let's say that the user hasn't read the message, but instead has saved it in another folder or a filename or has printed it on the printer. Should these actions be considered as having 'read' the message? It's a hazy area here, but I would argue "no" because it is not unlike another hop in the path of the delivery of the message. The printer does not imply that the user has read the message, nor does saving it to a plain file. If you save it to a folder, you could save the extra information that the message has been return-view-to'ed, but what if you read the message *after* having saved it. The message has been viewed and the originator replied to, but what happens when the user reads the message in that other folder the message was previously saved to? As far as that folder is concerned, it hasn't been read yet. Should it generate another reply? How would it know not to? The more I think about this, the more I conjure up cases which break this system -- it is poor design to try to have the UA do it. But, in spite of all that and if you really want to do it in mush, then you want to add a new flag (VIEWED) in mush.h as it will be a new flag added to the m_flags field of the "msg" data structure. Go into display_msg() and when the message is read (is_read() is called), you can kludge a reply_to_hdr value set to Return-Receipt-To and call reply_to() on that message and generate an automatic reply indicating that the message has been viewed. Dan Heller <island!argv@sun.com>
frank@ladc.bull.com (Frank Mayhar) (06/15/89)
Here's an idea: Have the UA inform the MTA that Message-ID such-and-such,
located in file x, needs a Return-view-to processed. The MTA then looks in
the indicated file for that message-id, and if it's there, it generates
the return and marks the message accordingly.
So the UA simply informs the MTA when a particular message has been read
(and contains a return-view-to header), and the MTA actually does the work.
What are the problems with this? Any?
--
Frank Mayhar ..!uunet!ladcgw!frank (frank@ladc.bull.com)
Bull HN Los Angeles Development Center
5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241jpp@slxsys.specialix.co.uk (John Pettitt) (06/16/89)
From article <438@ladcgw.ladc.bull.com>, by frank@ladc.bull.com (Frank Mayhar): > Here's an idea: Have the UA inform the MTA that Message-ID such-and-such, > located in file x, needs a Return-view-to processed. The MTA then looks in > the indicated file for that message-id, and if it's there, it generates > the return and marks the message accordingly. > > So the UA simply informs the MTA when a particular message has been read > (and contains a return-view-to header), and the MTA actually does the work. > What are the problems with this? Any? I like the idea of this, it does seem to be a step in the right direction hever there are some big holes in it to be resolved. 1) How to communicate thi sfrom the MUA to the MTA in a know manner. 2) How to track multiple views of the same file I.E. the save it then read it then read the saved version problem. The original question came about because SCO OP mailer has view receipts, however I would be very interested to hear what the X.400 standards have in the way or receipts. > -- > Frank Mayhar ..!uunet!ladcgw!frank (frank@ladc.bull.com) > Bull HN Los Angeles Development Center > 5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241 -- John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR {backbone}!ukc!slxsys!jpp jpp%slxinc@uunet.uu.net jpp@specialix.co.uk Tel: +44-1-941-2564 Fax: +44-1-941-4098 Telex: 918110 SPECIX G >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<