CURRENT MEETING REPORT
Minutes for the Electronic mail read
receipts Working Group (receipt)
Most of the meeting was devoted to reviewing
the current receipts draft and reaching closure on the various
open issues left over from the last meeting.
The most important issue considered by the
group was that of where receipts should be sent. The obvious choices
are to return the receipt to either the envelope originator address
appearing in the Return-Path or to the address appearing in the
Disposition-Notification-To (DNT) heading field.
The group hit upon the clever solution of
defining the receipt recipient in the DNT header. However, if
the Return-Path is specified and different from DNT field, the
MUA should *not* send a receipt without user confirmation. This
protects users from receipt requests sent to a list in order to
get a roster, because the list exploder will change the envelope
originator address but not the DNT field.
A question was raised regarding section
3.3.5 in the draft, which states that if a Message-ID is present
in the original, it SHOULD be returned in the receipt. The group
decided to change the SHOULD to MUST.
Section 3.2.1 in the draft states that the
Reporting-UA field is required. The group decided that the Reporting-UA
field should be optional.
The group decided to get rid of all of the
various -type subfields.
The various disposition types to include
in the base document were considered. The group decided on three
positive ones (user manually confirmed, user automatically confirmed,
robot confirmed) and four negative ones (terminated, expired,
denied, obsoleted). The document editor (Roger Fajman) was tasked
with coming up with good names for the positive ones.
The group considered the question of recommended
behavior for list servers. There are several valid scenarios:
Keith Moore agreed to come up with language
for the Security Considerations section that outlines the possibilities
and their implications.
The question was raised of what to say about
signed receipts. This is already covered in RFC1892.
Finally, the group agreed to the following