Hi Alessandro, Thank you for your feedback. > I think reporting mechanisms are the meat and potatoes of MARF. I > wish this draft be adopted by this WG.
I certainly hope so, especially because there is no active IMAP-related working group at the moment to progress this draft. There should be a liaison statement coming from OMA EVVM soon, seeking 'home' for the draft. I - and maybe I can speak for the rest of the OMA EVVM group here - would be glad if the MARF group would take it. More about this later once the liaison statement came through. > 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. Well, yes and no. We do not define 'abuse' and 'other' in our draft: - 'Abuse' is more or less "default" for all spam. Every single message one reports is a spam, so we decided to support including only additional information that would detail the nature of the spam. - 'Other' does not make much sense for a spam-only reporting mechanism (which our command is). I've considered reusing them, but I decided not to because I would have to explain in the draft that 'abuse' and 'other' are not used, while fraud maps to phishing and virus maps to malware. By the way, how come you are not naming these phishing and malware? I mean, fraud is only one specific type of phishing while virus is only one specific type of malware. Do you intend to expand the list with all possible sub-types? I kept it simple in our draft because most users don't even understand the high-level types. > 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. We are trying to come up with a keyword format that would allow us storing the reason and the location of the spam. This is a work-in-progress in OMA EVVM, we might come back with keyword proposals/registrations once we came to agreement in OMA EVVM. I decided not to include any keywords in the draft on purpose. > 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? Well, yes, the client can identify a virus, an ill-willed script, etc and report it. But, in my opinion the user will be the primary source for spam reports; ultimately is the user that decides what he considers a spam. One man's treasure is another man's rubbish. The user should be able to indicate which message he considers a spam and why. Naturally, header fields will be more or less limited to what the user can normally see: sender, subject field. In addition, the user should be able to indicated which part of the message is a spam (which body). While this does not carry much meaning to the user, it would greatly improve the accuracy of heuristic spam filters. > 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. I was not sure whether I should keep these or drop these. You see, this specification was going to be part of the OMA EVVM specs, but the group decided to go with IETF because this is the "natural home" for IMAP extensions. Consider the OMAEVVM10s a leftover for now, we will follow up on this once the keywords in OMA has been sorted out. > 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 The reason it was included is that OMA EVVM would like to use the SpamRep Enabler to deal with spam, specifically. I agree that making it informational is not going to change that, so I took a note here to move it to the informational section. Expect it in the next revision of the draft. > 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. Yes, this is the intent. The more generic, the better. We've been working with SpamRep only thus far in OMA EVVM. Could you put this into words that I could include in the draft? What is the security issue with triggering the server's action accidentally? Thank you for your comments, Alessandro! --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
