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