Re: [apps-discuss] Spam reporting over IMAP

Zoltan Ordogh <> Fri, 13 January 2012 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 386FB21F856A for <>; Fri, 13 Jan 2012 11:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.357
X-Spam-Status: No, score=-4.357 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FXchedqGHHsa for <>; Fri, 13 Jan 2012 11:11:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6573B21F8568 for <>; Fri, 13 Jan 2012 11:11:20 -0800 (PST)
X-AuditID: 0a412830-b7fe76d000001ee9-a0-4f1081d776f8
Received: from ( []) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by (SBG) with SMTP id CA.F1.07913.7D1801F4; Fri, 13 Jan 2012 19:11:19 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 13 Jan 2012 14:11:19 -0500
Received: from ([fe80::f1d2:c1d5:f469:3f83]) by ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.01.0339.001; Fri, 13 Jan 2012 14:11:17 -0500
From: Zoltan Ordogh <>
To: "Murray S. Kucherawy" <>, "" <>
Thread-Topic: Spam reporting over IMAP
Thread-Index: AczO/5w0zIm+SpJ7RGmLza1UzvIy+ADJcaFQ
Date: Fri, 13 Jan 2012 19:11:17 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1DE983233DBBEB4A81F18FABD8208D76226BE438XMB107ACNCrimne_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNKsWRmVeSWpSXmKPExsXC5Shmonu9UcDf4GWbicXqlyvYLFZ/3MHm wOTRMXEXk8eSJT+ZApiiGhhtEvPy8ksSS1IVUlKLk22VfFLTE3MUAooyyxKTKxVcMouTcxIz c1OLlBQyU2yVTJQUCnISk1NzU/NKbJUSCwpS81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/ roWFqaWuoZKdLhJI+MedcWydRcHSvYwV6xp/sDUwvljE2MXIwSEhYCLR8Ieji5ETyBSTuHBv PVsXIxeHkEAPk8SHfWtYIZxljBK97c9YIJxtQM6FLywg3WwCqhJzrsaCdIsIJEhMeb+TEcQW BgpvXPObBSKuJnH4x0Eo20hiw/Np7CA2C1DNhf+bwWxeAU+JS6ePs4LYQgLBEh2v+8FsToEQ iZn3F4P1MgrISuw+e50JxGYWEJe49WQ+E8TVAhJL9pxnhrBFJV4+/scKYStKPGnczAJRny9x oecJC8QuQYmTMyFsIQEZiedTLrFPYBSbhWTsLCQts5C0QMR1JBbs/sQGYWtLLFv4mhnGPnPg MROy+AJG9lWMgrkZxQZmhsl5yXpFmbl6eaklmxjBCUfDYAfjhL1ahxgFOBiVeHh9awT8hVgT y4orcw8xSnAwK4nwSpkChXhTEiurUovy44tKc1KLDzG6AkNuIrMUd3I+MBnmlcQbGxjg5iiJ 82qr3/MTEkgHJr3s1NSC1CKYOUwcnFINjDrflRlv/P2gfog3r227+cP6k6+m8nc8fnLxP9ON 4F8VJ/WjE1Zv+axxMdX3dP3u0y3BJkl7tq44d+39+8Jf86bx7v1e5DbvawPnEa96ns6NRyuP RnbUsLfwJhTdbbzKJ7taaq3f7ymPfffvCpZrfRW6OiJ4TmzVqnyjQA4bf4lI7u4nnddsZyqx FGckGmoxFxUnAgBBPX2lXgMAAA==
Subject: Re: [apps-discuss] Spam reporting over IMAP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Jan 2012 19:11:26 -0000

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: [] On Behalf Of Murray S. Kucherawy
Sent: January 9, 2012 1:51 PM
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.


M. Kucherawy

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.