Re: [apps-discuss] Spam reporting over IMAP

[Zoltan Ordogh <[e-mail]>]

Hi all,
Instead of responding to individual emails one by one, I try to clarify some of the concerns at least in a single response.

I would like to start with a story.

I few companies got together in OMA EVVM to enhance the OMTP Visual Voice Mail 1.3 specs.
During the requirements phase it has been identified that spam voicemails are an issue, and a reporting mechanism must be in place.
OMA typically uses in-house solutions when it's available. This is where OMA-SpamRep comes to the picture; the OMA-SpamRep provide exactly that: spam reporting.
OMA-SpamRep unfortunately two weaknesses:
- it is an RFC3462-based reporting mechanism: to file report, one must include the original email.
-  it is HTTP-based.
- it cannot manage the mailbox (to make a decision and do what needs to be done [leavealone, flag, move, delete]) so one would need to go through IMAP anyway.
Some OMA members believe that keeping the bandwidth consumption at a minimum level is crucial, which make those two weaknesses stand out.
Consider that voicemails can be large (100k>) and establishing a separate connection when you already have one is far from being efficient.
So, members in OMA have studied this topic and concluded that:

-          we should keep it all in IMAP (reuse the existing IMAP connection),

-          report spam by using a reference (instead of sending entire messages),

-          let the service provider decide how spam is handled (instead of explicitly flagging, moving, deletion messages, leave these decision to the server).

-          an IMAP server has an ample supply of bandwidth to chat with another service to hand over 100k+ attachments in microseconds - including a bonus: without counting the traffic (generated by a useless piece of spam) into a user's traffic  quota (which is especially expensive while one is roaming).

-          allow a server to utilize any spam aggregator service  - such as a service based on OMA SpamRep - (instead of explicitly depending on one specific service).
Additional requirements include the ability to report messages that are no longer spam, being able to include additional information (severity, nature of the spam), etc.

So, this is how it all began.
Fast-forward a few months.

I volunteered to write up a draft that would include a new IMAP command that does all that OMA EVVM needs, so I did.
The draft has been reviewed in OMA EVVM, adjusted a bit, and finally uploaded to IETF.
I sent out an email about the draft to the MARF mailing list, explaining where it comes from. We have received a few technical comments, but the MARF group was concerned about the lack of IMAP experts in the group, so it was not taken into the MARF charter.
A bit later, a liaison statement was sent from OMA to IETF, seeking collaboration and a "home" for the draft; as required by RFC3975.
OMA EVVM have not received any response from IETF, so a discussion began in OMA EVVM regarding the possibility of releasing IMAP extensions within OMA EVVM. Lacking any other choices, it will surely happen.
But. I would prefer keeping an IMAP extension in the midst of IETF for several reasons (some of which Alexey already elaborated in his email), so I started talking with Murray and Alexey offline, asking for advice, regarding the silence of IETF and our options to progress this draft.

-          Alexey was kind enough to have a look at the draft and send a good deal of comments our way - which we have all intention to address.

-          Murray was kind enough to start a discussion to see whether there's interest in the draft.

-          I was also told that there won't be an IMAP-related working group for a long time (which is fine; there's no point creating a WG for a single draft).

Which bring us to where we are today:

-          There is a draft that fulfills a set of requirements (does what OMA EVVM needs it to do).

-          We have received some comments already (Alessandro, Alexey - thank you).

-          The only goal of this thread (as Murray said already) is to test the waters and see if there is interest in IETF APPSAWG to work a draft like this.

So far I've seen both positive and negative feedback, discussion of technical issues already, and even a new draft. To me, that shows that there is some level of interest.

PS. I am solely a technical contributor, so asking me IPR-related questions will always be a dead end. Please direct those questions directly to the appropriate contact person, which, in, this case is Sarah Guichard. Thank you.


From: [e-mail] [mailto:[e-mail]] On Behalf Of Murray S. Kucherawy
Sent: January 9, 2012 1:51 PM
To: [e-mail]
Subject: [apps-discuss] Spam reporting over IMAP

In September the OMA sent a notice to the IETF that it had submitted draft-ordogh-spam-reporting-using-imap for our consideration as they need it (or something like it) to complete work of their Enhanced Visual Voice Mail working group.  It has since then failed to get any IETF attention.

It was submitted to the Messaging Abuse Reporting Format (MARF) working group but they are not chartered to handle this work, nor is there any apparent interest or momentum to recharter to do so.

Is there any interest among those of us following APPSAWG to do this kind of work?  I can't think of any current working groups where it might otherwise fit.

I can suggest they present in Paris if they want to gauge interest if people would be interested in hearing something about it.  Otherwise, I believe I should reply to them that the IETF is not currently doing work in this area so their options include an ISE submission or something AD-sponsored that goes for Experimental status or suchlike.

I'd be happy if someone (or a few of us) here could review it and make some suggestions about next steps.

Thanks,

M. Kucherawy
<hat-type='OMA-Liaison'/>


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