
From: Mark Martinec <Mark.Martinec+ietf@ijs.si>
Organization: J. Stefan Institute
To: abuse-feedback-report@mipassoc.org
Date: Wed, 19 Dec 2007 17:38:20 +0100
User-Agent: KMail/1.9.7
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200712191738.20673.Mark.Martinec+ietf@ijs.si>
Subject: [feedback-report] Some comments on draft-shafranovich-feedback-report-03
Precedence: list

Reading the current draft brings up a couple of comments.
If some of these have been discussed and resolved in the past
please disregard, I haven't checked the full archive.

1.
There is a conflict between Section 4 item e:
  "Each feedback report MUST be related to only a SINGLE email message"
and Section 5.2, which requires that a "Original-Rcpt-To:" can only
appear once. What happens with multi-recipient messages (multiple
RCPT TO on mail reception)? Should 4e be disregarded and multiple
reports generated - one for each recipient, or should 5.2 be
disregarded and multiple "Original-Rcpt-To:" included, or should
only one (random?) recipient be reported and remaining recipients
not included in a report?

2.
There is a likely conflict between Section 4 item g:
  "If a part includes characters outside the 7bit set, the
   part MUST be encoded using one of the encodings in RFC 2045."
(if item g is supposed to covers also a third MIME part -item d),
and a requirement in the RFC 2046:
  "No encoding other than "7bit", "8bit", or "binary" is permitted
   for the body of a "message/rfc822" entity."

The reason for this restriction on "message/rfc822" is that
encodings must not be nested (e.g. QP-encoding of a message
which itself also contains QP-encoded mime parts is not
permitted). Allowing for nested encodings would make MIME
parsing much more difficult (recursive) and less robust,
so it is intentionally prohibited.

3.
Section 5.2 states that for a "Source-IP:" in case of an IPv6
address the format to be used is as defined in RFC 4291.
I believe it would be more appropriate to require the format
as defined by RFC 2821, syntax element "address-literal",
see section "4.1.3 Address Literals". After all, the information
on a message to be reported will most likely come from a MTA
(or MUA or some mail filter), and will refer to a mail message,
so avoiding an unnecessary requirement for a transformation
and reusing the format used for mail would be appropriate.

4.
Section 5.2 defines a "Received-Date:". I think it unnecessarily
reinvents the wheel, as the (sister) DSN format (RFC 3464)
already defines a field for such purpose, the: "Arrival-Date".

5.
The DSN format (RFC 3464) is closely related to this one,
so it might be useful to borrow some fields from section
"2.2 Per-Message DSN Fields", or just include the whole
section: Original-Envelope-Id, Reporting-MTA, DSN-Gateway,
and the already mentioned Arrival-Date. At least the
Reporting-MTA and Arrival-Date should be allowed.

  Mark