CURRENT MEETING REPORT Minutes of the Receipt Notifications for Internet Mail Working Group (receipt) Reported by Claudio Allocchio, INFN, Institute for Nuclear Physics, Italy Agenda 1) Choose secretary: Claudio Allocchio 2) General/Broad Issues a) which address to take to send MDNs to b) how to handle lists/ forwarders c) MDN types d) where should MDNs be from e) automatic/manually generated MDNs f) Original recipient is specified ONLY by sending UA? g) one and only one MDN h) mark a message that a MDN has already been sent out? i) security consideration j) taxonomy/terminology document k) postprocessing of MDNs by user 3) Next Steps a) new version of the draft documents b) update charter General/Broad Issues a) Which address to take to send MDNs to? Roger: It could be dangerous to send the receipt to the address which is shown on the message. Should it be sent to the envelope? Where else? Do we use Return-path: ? The envelope is not part of the message. We should stick with bodypart (822 header)? Keith: So many mail servers can cause a major point of loop. The address should be the one that the list processor never changes, just as with the list maintainer. If we can use the envelope return address here, it is easier. It could be the envelope address, because it is usually NOT changed by the mail systems. Ned: The only thing mailing list change is the envelope MAIL FROM address. It is done to prevent loops. It prevents users from specifying the list address there, but the list server removes it and puts the list maintainer there. This saves from the danger of a user faking the address were receipts should be sent. If the receipt automatically generates a receipt request, then we could have a "receipts flood". If the receipt does NOT require a receipt, then we do not have the problem. Thus receipts should not request a receipt. This must be stated in the documents. A notification itself in general should NOT generate a request for receipt. Conclusion: Put suggestions that UA should not generate receipts notifications in a series of cases. Conclusion: Send the receipt to the envelope return-path, even if this is different behaviour from the X.400 case. b) How to handle lists/forwarders The main concerns here are loops and the possible danger of disclosure of mailing lists members getting the MDNs back to the originator of the message. This topic is related with the previous one. Many LAN mail system do not have a specific slot to place the address where the receipt should go. This can cause a lot of problems. There is also the problem of gateways. In X.400, the receipt is sent to the P2 sender/from, not to the envelope. It is different stuff. For the distribution list we could have the request to have the receipt sent back, and for other cases there is the need to strip away the receipt notification request. This is controversial. There are cases where a distribution list could need the receipt. There are many alternates: o The mailing list drops the receipt request, forwards the message to the list, and informs the sender it has dropped the request. o The mailing list simply drops the receipt request, forwards the message to the list, and does nothing else. o The mail list server forwards the receipt request, collects the receipts for a determined period of time (one week?) and sends back ONE global receipt (problems: it could never converge) o The list processor is transparent, and sends along receipt requests. The sender gets all receipts back. It can be dangerous. We could say that receipts are working fine in an end user to end user environment. However, mailing lists in the middle can create troubles. Summary proposal: Let the specification allow dropping receipt request, or let the request pass by and have the sender have all receipts back directly. We need to distinguish between mailing lists which act at UA level, rewriting the P2 header, and other cases, where there is not re-writing of the P2 header (user-to-user delivery, including cases of manually specified addresses). The problem needs further discussion to find convenient solutions. We should write down text for possible cases that can happen and drop them to the list. This will help to classify the problem, and then attack it with solutions: Case 1) Just use an expander and make no changes to the mail itself. This is like sending from one user to many recipients directly. Case 2) Real mailing list: P2 header is changed and rewritten at UA level. A new envelope is then generated. c) MDN Types There are different types of receipts: receipts can be automatically generated, or can be confirmed by the recipient user. The requesting UA (the one generating the receipt request) should be enabled to ask or negotiate for ONLY certain types of receipts, such as ̉do not send back automatically generated receipts, send back human confirmed ones." It is also a question of implementation. Thus, shall we have a "receipt request negotiation process" to state "I do not care for this kind of notification, do not send it back to me"? The problem is are we able to do it with Internet mail? Probably not. It is a modeling question, but very difficult to implement. Shall we define the types at all? Is it too complex? We cannot really evaluate the complexity of the possible types. Conclusion: It is clear that different people expect different kinds of services from the "receipt." We thus need to specify exactly WHAT the service can do. We have two major types: o automatically generated o humanly generated Thus the UA could or filter one of the two out, of just do ask do not seemed me this kind of receipt. Further discussion on the list to collect other possible ideas. d) Where should MDNs be from? Which address the receipts should come from? The from: in the 822 header should state the person name, the MAIL FROM in P1 SMTP what should it be the ? notification- generator@domains? Users could be very confused of the SMTP from is something strange. Further discussion on the list to define exactly this point. o Automatic/manually generated MDNs, Flag the cases of auto generated/manually generated receipts? yes the MUST be flagged. general agreement. f) Original recipient is specified ONLY by sending UA? Is it worth to handle the case of multiple receipts notifications coming back? If we cross a gateway, a list etc. in many cases the receipts could not come back. It could be useless. Can a gateway take the ORCPT parameter and put it inside the P2 header, to be used for this problem? The documents should state there is only ONE original address and no more. g) One and Only One MDN What does it mean? We just pack a "message history" into a receipt? It is a question. We need some language to specify the behaviour. Action: send to the list some text to specify it. h) Mark A Message That A MDN Has Already Been Sent Out? Should we define such a behaviour? The UA has to add a header to the message to mark this fact. Is it an additional header? Conclusion: yes, even if its a local matter. We do not mandate how to do it, we just give a suggestion (a reserved header field) if you want to do it. We recommend the reserved header solution if you want to implement it. Receipt-sent: yes/no (as an example) i) Security Consideration The draft does not currently include any dedicated security considerations sections. We should search for a general solution for all delivery notifications. In addition, we probably need a new group for this point. j) Taxonomy/Terminology Document (for receipt specifications) Do we need a document like that? When people think of receipt there are too many different "interpretations." There are several types of receipts. and there is DELIVERY (but there is no guarantee of the receiver reading the message). There are the READING receipts. DELIVERY has to deal with NOTARY, and has already been fully specified. There could be a receipt "signed" by a user, (read receipt) and one "signed" by a system (delivery receipt). We need to clarify what a receipt is, adding the exact level of definition and security. We need to again clarify that DELIVERY notifications are already done. It is NOTARY work. We are not re-doing it again. If we define a terminology document it could be fine. We do not need to again re-do the specifications. Does it need to be a resulting project of this Working Group? It could be an "outside" document. Keith: We have a very modest scope, and we do not want to deal with all the problems relating to this case. A document could be written anyway and then be submitted to the Working Group for approval. We are looking at the receipt AFTER the delivery notification pass is over. It was suggested that the Working Group discuss the document on the receipt list, but that we do not include it in the charter. We should first show the document to an Area Director, and it will then be decided where it should be placed so others may access it. However, a first draft must be completed k) Postprocessing Of MDNs By User (including review before the receipt is released and sent) The acknowledging person should authorize the receipt. The user should be able to SEE the text going out. The user should be able to add comments to the receipt. It should be able to add a Cc address to the receipts. The user should also be able to DENY the receipt sending. Also, it should follow a regularly defined format, and not be considered a real message. The comment should be an 822 comment: field, etc. The aim is to add confidence to the significance of the receipt, but we must be careful not to add additional meanings such as "I understood the message." 4) Next Steps a) A new version of the draft documents By the end of Jan 1996 there will be the next version of the documents. We do not need all issues solved by that date, but the new document will at least include all issues. b) charter 5) Some Changes Urs will add 2 new milestones o revised draft by end of January 1996 o review meeting at next IETF in Los Angeles