Subject: [marf] FW: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 26 Aug 2011 11:19:23 -0700

For those of us tracking the SpamRep convergence issue (which should be most of us!), this might be of interest:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 26, 2011 10:58 AM
To: [email-masked]
Subject: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Spam reporting using IMAP: SREP
	Author(s)       : Zoltan Ordogh
	Filename        : draft-ordogh-spam-reporting-using-imap-00.txt
	Pages           : 16
	Date            : 2011-08-26

   The Internet Message Access Protocol [IMAP4] does not support
   reporting spam on its own.  There are a number of solutions available
   based on the multipart/report content type defined in [REPORT].
   However, these solutions require including the message contents and
   hence, consume bandwidth to transmit the entire message.  In
   bandwidth-constrained environments - such as mobile networks - it is
   highly desirable to send only a minimum set of information - a
   reference - instead of the entire message.  Furthermore, it is
   desirable to permit individual server implementations to handle spam
   in any way these systems choose to: do nothing, flag, recommend
   deletion or relocation, perform deletion or relocation, and, involve
   any choice of spam aggregator services in the decision process, such
   as [OMA-SPAMREP].  Solutions that exist today employ manipulating
   proprietary flags in the IMAP storage to achieve the bare minimum,
   however more advanced solutions cannot be developed by using flags
   only; the IMAP server needs to be involved actively in the spam
   reporting process.

   This document specifies the syntax of the SREP command, which allows
   a client to inform the server that the user considered a message (or
   parts thereof) spam, or, that the user no longer considers a message
   (or parts thereof) spam.  Since all information about the message is
   readily available on the server, the command also allows the server
   to implement a more intelligent and accurate decision logic, which
   may be invoked when the spam is reported and the server can respond
   with its decision to the client.

   Additionally, this document contains example flows, illustrating
   various decisions that the server may choose to evaluate, including
   invoking a service based on [OMA-SPAMREP].

   This document focuses only on the client-server interactions and the
   scope is limited to messages that either exist on the IMAP server,
   or, exist elsewhere and the IMAP server is configured to access them.
   Consequently, deposit-time filtering, messages that have been
   deleted, or, exist in an external storage but are accessible via an
   access protocol unknown to the IMAP server are out of scope.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ordogh-spam-reporting-using-imap-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ordogh-spam-reporting-using-imap-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Alex Bobotek" <[email-masked]>
Date: Fri, 26 Aug 2011 11:21:24 -0700

Thanks.  Reading the link with interest ...

Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Murray S. Kucherawy
Sent: Friday, August 26, 2011 11:19 AM
To: [email-masked]
Subject: [marf] FW: I-D Action:
draft-ordogh-spam-reporting-using-imap-00.txt

For those of us tracking the SpamRep convergence issue (which should be
most of us!), this might be of interest:

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, August 26, 2011 10:58 AM
To: [email-masked]
Subject: I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ordogh-spam-reporting-using-im
ap-00.txt

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ordogh-spam-reporting-using-ima
p-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
marf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/marf

---

From: Zoltan Ordogh <[email-masked]>
Date: Fri, 26 Aug 2011 15:39:53 -0400

Hi all,
I was going to forward it myself, but it appears you are much faster.

I did not identify any working group in IETF in the draft on purpose.
I was thinking that YAM might be a good candidate, but YAM is closing.
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.

Some history.
The motivation for this document originates from the OMA EVVM working group.
"OMA" stands for Open Mobile Alliance, it is an SDO, see www.openmobilealliance.org
"EVVM" stands for Enhanced Visual Voice Mail.
In general, the group have requirements to report spam and to report that a message is longer spam.
"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.

While it is an individual contribution, it has been reviewed and endorsed by members of the OMA EVVM working group.
Hopefully there will be a liaison statement following up soon to back these statements up - once we identify the recipient of such liaison statement.

In the meantime, it would appreciate if you reviewed the draft.
Should you have questions or comments, please do not hesitate to contact me.

Thank you.

---------------------------------------------------------------------
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.

---

From: Zoltan Ordogh <[email-masked]>
Date: Fri, 26 Aug 2011 16:02:46 -0400

Hi all,
There is an error in my message below.
The word 'no' is missing. Here's the corrected sentence:
In general, the group have requirements to report spam and to report that a message is no longer spam.

Sorry about that, and thank you Moh, for pointing it out.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zoltan Ordogh
Sent: August 26, 2011 3:40 PM
To: [email-masked]
Subject: Re: [marf] I-D Action: draft-ordogh-spam-reporting-using-imap-00.txt

Hi all,

Some history.

Thank you.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 26 Aug 2011 13:15:31 -0700

Hi Zoltan,

In fact, we have in the MARF charter the requirement that we track the work going on in the OMA's SpamRep working group with an ideal solution being the convergence of the two mechanisms.  That's why your draft caught my eye.

I'm also the IETF liaison to the OMA.

So yes, we know who they are.  :-)

Thanks for contacting us.  I'm sure feedback will be coming soon.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 27 Aug 2011 11:33:16 +0200

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.

> 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

--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 29 Aug 2011 12:10:11 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Saturday, August 27, 2011 2:33 AM
> To: Zoltan Ordogh
> Cc: [email-masked]

A co-chair moment, brought to you by the letters R, F and C:

Handling an IMAP extension to enable browsers to do abuse reporting is outside of our current charter.  We would have to re-charter to include this work in order to adopt it as a working group item.  We do have in our charter the work of tracking SpamRep, but this didn't come out of the SpamRep WG at OMA.

That's not impossible, of course, but it means discussion of adopting this now is premature.

If there are others in this group that feel this is worth the exercise of re-chartering and (most importantly) are willing to put time into editing the document and creating and testing implementations, please say so.

-MSK, as co-chair