[feedback-report] Comments on draft (and spam reporting in general)

[William Leibzon]

First I'd like to note that I think standard spam reporting format is a 
good idea (in fact there was supposed ASRG group working on that - 
whatever happened to it and why discussions are being done on separate 
mail list and not there), but I'd have thought it be better if it format 
was XML as it gives more options on what and how to report and 
extendability for the future then simple mime text fields.

In any case I'm going to comment on current draft first:

1. Discussion is needed on combining reporting of more then one email
    In particular what needs to be decided is:
  a. If multiple instances are regarding the same message to multiple
     users, should it be done as separate reports or not? (probably yes)
  b. What if those multiple instances are to the same user - multiple
     reports or some way of mentioning that more then one was received?
  c. Reporting agent may also want to combine multiple reports for separate
     independent instances together, should it be allowed, encouraged,
     prohibited?

2. The report includes Reported-Domain and Reported-URI but its possible
    (in fact likely) that reporting maybe for particular email address
    rather then domain or URI. I actually think that having separate
    fields (and adding yet another one) is not the best idea and its
    better to have something like "Reported-Field:" which would have
    a tag "type" that can be "URI", "email" or "domain" and then data, i.e.
      Reported-Field: type="email"; abuser at hulligans.org
       (apologies if hulligans real domain, I've not checked)
      Reported-Field: type=URI ; http://www.bankofamerica-phisher.com

    Note: I don't particular like "-Field" as part of above, but I could
    not find anything else general enough except "subject" and using that
    would be even more confusing. Another possibility is just use Reported-URI
    and use "dns" for reporting dns and "mailto" for reporting email addresses

3. On above, it is probably a good idea to indicate in report if what is
    being reported is data field from email transmission, email header
    or email body (and if email body not a bad idea to make possible
    to report cid URI reference to particular mime body part). Perhaps
    also indicating particular "location" (byte number) where what is
    being reported is at is good idea as well (this brings question on
    syntax to report if field appears in more then one place, probably
    mutliple Reported-Field).

4. I don't like "Received-Date" - I think its better if "Received-"* are
    left for use for trace header fields. Maybe better if you pick another
    name, possibly "Reported-ReceivedDate" to be consistent.

5. This has yet another use of Original-* which is yet again different
    then what it was before.... In any case, my comment is that I think
    its better to not name it directly "Original-Mail-From" and
    "Original-Rcpt-To" but indicate that its envelope parameters, maybe
    "Original-Envelope-Mail-From" and "Original-Envelope-Rcpt-To" and also
    leave possibility for parameters of the MAIL and RCPT commands, i.e.
    "Original-Envelope-Mail-Submitter".

6. "X-Source-IP" is used in some places to indicate source of actual
     message. Lets not confuse people, change to "Reported-SourceIP".

7. "Version" as separate header field is way too ambitious and unnecessary,
     lets leave that along and include version tag as part of MIME type, i.e.
      Content-Type: message/feedback-report ; format-version=0.1

Overall I think the draft and "spam reporting" in general still needs a 
lot of work and this work should be both deciding in general as to what
goes into report and deciding on report format (xml or header fields) and
particular syntax as last part.

---
William Leibzon
   mailto: william at completewhois.com
Anti-Spam and Email Security Research Worksite:
   http://www.elan.net/~william/emailsecurity/
Whois & DNS Network Investigation Tools:
   http://www.completewhois.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 1118 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mipassoc.org/pipermail/abuse-feedback-report/attachments/20050520/12b1539d/smime.bin