Hi Zoltan, thank you so much for a long awaited IMAP extension!! On 26/Aug/11 21:39, Zoltan Ordogh wrote: > MARF is a good candidate, but I was not sure about the attendance > of IMAP experts. So, I left it as an individual draft for now.
I think reporting mechanisms are the meat and potatoes of MARF. I wish this draft be adopted by this WG. > In general, the group have requirements to report spam and to > report that a message is no longer spam. These match the "abuse" type defined by RFC 5965 and the "non-spam" type that draft-ietf-marf-not-spam-feedback is going to define. In http://www.iana.org/assignments/marf-parameters/marf-parameters.xml there is a registry of these types. While spam-reporting-using-imap can define any new types it needs, I think it may reference that registry and use existing types when possible. http://www.iana.org/assignments/imap-keywords/imap-keywords.xml is a similar registry for IMAP flags. $Junk and $NotJunk are there, but $WHATEVER-spam-user-identified is not. Obviously, it is relevant for the IMAP server to know whether spam-classification is a user's or an automated decision, so I'd suggest to register this flag. Currently, it is not possible to transmit such user-vs-auto info using ARF. The one use case that I can think of for an identified-body.X is client-side detected viral attachments, but I'm sure there are more. Header fields identification looks more tricky. Anyway, those values seem to be rather orthogonal to one another. Would there be any advantage if they were defined independently of one another? > "Message" here refers to voicemails, which include audio and video > attachments. Being a mobile-focused group, the group needs a > mechanism to report spam while keeping the bandwidth usage at the > minimal level, and possibly reuse a protocol stack which is already > in the scope. The choice for IMAP was very convenient because it is > already in the scope (it is the base protocol), it is easily > extensible, and, the entire message is already available on the > server (no need to upload anything but a reference). The rest is > pretty straightforward: a new, extensible command with the > arguments to go, facilitating all kinds use cases. I see. I welcome examples with voicemail, but would encourage you to also add examples of plain text messages. I'd remove the OMAENVVM10 prefix from flags, though, especially if they're going to be registered at IANA. The example in section 1.10.1 is not going to be very useful for people who ignore what an aggregator service is. While I'd hope that standardizing aggregation services is the topic of this or some other WG, it is obviously not going to be defined within this document, hence I'd confine this term to informative examples --that is, remove it from Abstract and Security Considerations-- in order to avoid giving the impression that this protocol is somehow proprietary. In facts, it is very general, and hacks for similar functionality common. See http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs#Via_IMAP A more generic discussion of server-side features is probably useful. In particular, I would mention that a server MAY report spammy messages to external, possibly public or foreign audiences, and/or make local copies of them. Of course, users have to know and agree to site policy, especially where law mandates that. The Security Considerations section should mention the possibility that users trigger server's actions accidentally. > --------------------------------------------------------------------- > This transmission (including any attachments) may contain > confidential information, [...] Please read this (and possibly more) on confidentiality notices: http://www.ietf.org/mail-archive/web/ietf/current/msg67516.html -- _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
