Subject: [apps-discuss] Spam reporting over IMAP

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Jan 2012 10:50:51 -0800

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'/>

---

From: "John Levine" <[email-masked]>
Date: 9 Jan 2012 21:05:57 -0000

> 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 think it's a fine idea, but I wouldn't want to invest time in this
proposal unless there were some indication that large IMAP operators
were interested in doing something with it.

Do we know anyone at AOL, Yahoo, or Gmail to ask?  I can probably ask
Tucows.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Jan 2012 18:37:46 -0500

--On Monday, January 09, 2012 10:50 -0800 "Murray S. Kucherawy"
<[email-masked]> wrote:

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

Murray,

I have taken a _very_ quick look at this (I have not read all
the way through it).  Procedurally, if they want this processed
in the IETF, it would be good if it conformed to requirements
for I-Ds (e.g., the RFC Editor will not consider a document with
a page-long abstract, much less one that has a "Conventions
Used..." section apparently in the middle of it).

More substantively, 

-- they are assuming a whole serious of functions, capabilities,
and relationships that may not exist in a typical IMAP server,
at least one that is not also SIEVE-enabled (see below)

-- someone needs to tell them about current trends in
specifications like this.  In particular, while I remain in the
(apparently small) minority who still see value in "X-" and "X"
constructions even though I also favor adjusting registration
rules to make them _much_ less useful, it seems to me that this
specification should not be encouraging entirely new sets of
uses of them.

-- they posit the existence of "spam aggregator services" but
never really define those or explain how an IMAP server is
supposed to find one with the right capabilities except by an
putative informative reference to [OMA-SPAMREP].   First of all,
if they say something like "such as an aggregator service based
on [OMA-SPAMREP]" as the only definition of what such a thing
might be, then it is a normative reference -- certainly an IMAP
server would need to understand what a spam aggregator service
is in order to organize handing off work to one of them.   I
can't find the document referenced in the "Publicly Available
Documents" list on the OMA web site
(http://www.openmobilealliance.org/Technical/PublicMaterial.aspx).
Granted I didn't spend a huge amount of time poking around but,
even for an informative reference --much less for a reference
that is critical for understanding the spec-- being able to find
documents easily is usually a good idea.  I've heard that
something called a "URL" was invented for that purpose.

-- As a general rule, IMAP servers are not, in general, designed
to communicate with anything or any one, other than users via
the IMAP protocol and maybe (statistically or otherwise) with
the mail store about the status of messages and user opinion of
them.  Asking them to do so, via a "spam aggregator services" or
otherwise, seems to me to require far more understanding of
trust and privacy relationships than are covered by the
near-hand-waving in the Security Considerations section of this
document.    It might also require fairly significantly
re-architecting several of the IMAP servers of my acquaintance.

-- As a very high level architectural observation, someone might
think about whether it would be helpful to graft something of
this nature onto a SIEVE server.  Because such a server
(possibly in conjunction with other delivery MTA-components) is
responsible for processing messages before they disappear into a
mail store, they could, in principle, ensure
appropriately-unique message identifiers (which an IMAP server,
especially a distributed one, may not be able to do).  Because
they can specify and handle (or get something else to handle)
message rejections, they might also be in a better position to
handle some of the requirements here.  In any event, a document
of this sort needs to go much further to explain what functions
and interfaces an IMAP server would actually need to add to
support something like this.  The document leaves that to the
imagination and this is a sufficient departure from the classic
IMAP architectural and functional assumptions that imagination
really isn't adequate.

Conclusion: 

Not ready from prime time.  Not even ready for a careful and
comprehensive review.

You asked.
    john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Jan 2012 15:48:45 -0800

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]]
> Sent: Monday, January 09, 2012 3:38 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [apps-discuss] Spam reporting over IMAP
> 
> Conclusion:
> 

I did, and thanks for that.

I think at this point perhaps a higher-level question is in order: Are we (either IETF in general, or APPSAWG specifically) interested in or willing to put time into developing this in conjunction with OMA?  Would this be something ultimately beneficial to have, and have it come from us?

I suppose I'm also concerned with the idea of an external SDO, on getting a "no" from us, deciding they want to do this anyway so they publish their own (unsanctioned, of course) IMAP extension only to have it see some level of ubiquity as a result.  Indeed it may be possible that this is coming to us only because some OMA member organizations have already developed and are deploying this, at least experimentally.  There's friction between geopriv and OMA's LOC WG of this nature already which I'd just as soon resolve sooner rather than later somehow.

-MSK

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 9 Jan 2012 16:15:13 -0800

> I think at this point perhaps a higher-level question is in order: Are we (either IETF in general, or APPSAWG specifically) interested in or willing to put time into developing this in conjunction…

I'm sure many people would like to see something like SREP, but IMAP is absolutely the wrong place to put it.  IMAP servers store messages.  An IMAP server doesn't decide whether something is spam, and is in no way capable of doing anything about it.

SPAM filtering happens further up the delivery chain, usually within the MDA, or a preceding MTA, typically one that borders the recipient's site.  For an SREP-like system to have value, it needs to be able to provide feedback to the appropriate location in the delivery chain.  A generic reporting protocol might be a way of doing this, but it needs to be agnostic of the message stores and transport agents if it's to be useful.

So while I applaud the concept, the proposed solution isn't even close to baked.

--lyndon

---

From: SM <[email-masked]>
Date: Mon, 09 Jan 2012 16:21:42 -0800

Hi Murray,
At 10:50 09-01-2012, Murray S. Kucherawy wrote:
>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 don't think that the ISE will not take a draft with such a 
boilerplate.  There is also an IPR disclosure.  The draft needs a lot of work.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Jan 2012 16:29:57 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Monday, January 09, 2012 4:22 PM
> To: [email-masked]

There's no doubt it's far from submission-ready and needs some developmemt.  The larger question, I believe, is whether or not this is even the right path for this kind of technical work to take (is it a reasonable architecture, for example), and do we want to work with them on this?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 10 Jan 2012 01:47:26 -0000

I agree this draft needs a lot of work, but for the purposes of
argument, I'm assuming it gets rewritten to be a reasonable spec,
removing irrelevant stuff like the speculation about spam aggregation
services.  This is basically a way to provide a spam button in MUAs
that works like the spam button in web mail, for systems that are
prepared to handle user spam reports.  It's something we need, for
reasons that will shortly become apparent.

> I'm sure many people would like to see something like SREP, but IMAP
> is absolutely the wrong place to put it.  IMAP servers store messages.
> An IMAP server doesn't decide whether something is spam, and is in no
> way capable of doing anything about it.

That may be the way your IMAP server works, but it is not the way
everyone's IMAP servers work.  

AOL provides IMAP access to their mail system.  Each user has a folder
called Spam.  Moving a message into the Spam folder is the equivalent
of pushing the spam button in web mail.  Gmail also provides IMAP
access.  Their system is a little peculiar because of the way they map
message tags to IMAP folders, but there's a folder called Gmail/Spam
which works the same way.  This is, needless to say, a gross kludge,
but until there's some better way to handle spam reporting in IMAP
clients, it's what people will do. 

Don't take my word for it -- sign up for a free account at either or
both, and try it out.

> SPAM filtering happens further up the delivery chain, usually within
> the MDA, or a preceding MTA, ...

Really, it's a bad idea to assume that everyone's mail software works
the way that yours does.

R's,
John

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 9 Jan 2012 17:56:16 -0800

On 2012-01-09, at 17:47 PM, John Levine wrote:

> of pushing the spam button in web mail.

No doubt.  But only, as you say, in *your* IMAP server.

SREP demands a ubiquitous solution.  One that will outlive AOL and Google's missions to destroy IMAP.   It's an autonomous service; let's give it an autonomous protocol.

--lyndon

---

From: SM <[email-masked]>
Date: Mon, 09 Jan 2012 18:22:17 -0800

Hi Murray,
At 16:29 09-01-2012, Murray S. Kucherawy wrote:
>There's no doubt it's far from submission-ready and needs some 
>developmemt.  The larger question, I believe, is whether or not this 
>is even the right path for this kind of technical work to take (is 
>it a reasonable architecture, for example), and do we want to work 
>with them on this?

I don't think that IMAP folks would say that it is a reasonable 
architecture.  I would not spend too much time working on an IMAP 
draft if the author has not understood RFC 3501.  John Klensin 
already commented about the Abstract Section.  The draft needs a lot 
of development.  I suggest that the author finds someone to work with 
him on the draft before asking the IETF to consider it.

Regards,
-sm

---

From: "John R. Levine" <[email-masked]>
Date: 9 Jan 2012 22:48:55 -0500

> SREP demands a ubiquitous solution.  One that will outlive AOL and 
> Google's missions to destroy IMAP.   It's an autonomous service; let's 
> give it an autonomous protocol.

Oh, I forgot to mention, Yahoo does the same thing but their folder is 
called Bulk Mail.  AOL, Google, and Yahoo probably provide IMAP to more 
people than all the other IMAP providers in the world combined, so I'd 
think a standards organization would prefer to try engage with them and 
try to come up with something better than the existing kludge that's well 
on its way to becoming an ugly de-facto standard than to call them names. 
But maybe that's just me.

> SREP demands a ubiquitous solution.

We argued about this at some length in ASRG, and it's not an autonomous 
service.  You need an authenticated channel back to the mail provider, and 
a naming convention that the MUA can use to tell the provider what 
messages it's reporting.  If you have those, spam reporting is trivial. 
Otherwise it's pretty much impossible.  Web mail and IMAP are the only 
environments that do that.  (POP doesn't, by the time the user sees a 
message, the provider has forgotten about it.)  So if we provide it in 
IMAP, we are for all practical purposes done.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 9 Jan 2012 19:57:14 -0800

On 2012-01-09, at 19:48 PM, John R. Levine wrote:

> Oh, I forgot to mention, Yahoo does the same thing but their folder is called Bulk Mail

And Myspace called it?

---

From: "John Levine" <[email-masked]>
Date: 10 Jan 2012 05:20:40 -0000

>kind of work?  I can't think of any current working groups where it

If we detect interest in this from any of the large IMAP providers
(and, I suppose the usual MUA providers, although that's usually
doable with an extension), I'd be willing to help cleaning it up into
a something that lets an MUA communicate to an IMAP server that the
user considers a message to be spam or not, perhaps with a little
extra optional info to describe the nature of its spamitude.

My IMAP-fu is not fabulous, so it would be nice to have someone with
more IMAP background to help.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Jan 2012 16:30:25 +0000

I agree with John Levine that this is heading in the right direction even
though it neads a lot of tidying up.

> give it an autonomous protocol.

Why do you say this is an autonomous service? All the existing
user-oriented spam feedback systems are are an integrated part of the
user's email service provider's offering. Users really don't want to have
to type in yet another hostname and username and password just to provide
feedback to their provider's spam filters.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Westerly or southwesterly, veering northwesterly for a
time later, 5 to 7, occasionally gale 8 in Viking. Rough or very rough,
occasionally high later in north. Rain then wintry showers. Moderate or good,
occasionally poor later.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Jan 2012 19:08:04 +0000

On 09/01/2012 21:05, John Levine wrote:
> Do we know anyone at AOL, Yahoo, or Gmail to ask?
I can ask some people at Google.
> I can probably ask

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 10 Jan 2012 20:20:30 +0100

On 10/Jan/12 03:22, SM wrote:
> draft if the author has not understood RFC 3501.  John Klensin already
> commented about the Abstract Section.  The draft needs a lot of
> development.  I suggest that the author finds someone to work with him
> on the draft before asking the IETF to consider it.

I posted a draft-ordogh-spam-reporting-using-imap-kleansed-00 with
some of the cleanup John mentioned.  I'm unable to understand some
other comments he made, e.g. about sieve, but I hope this version is
easier to read anyway.

I've made some arbitrary changes, including IPR, as explained in the
appendix.  If that's not correct, please delete my post.  The doc is
not to be used directly anyway: Zoltan can reuse any xml parts that he
likes and repost the result as version -01 of its draft.

hth

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Jan 2012 19:31:40 +0000

> I suppose I'm also concerned with the idea of an external SDO, on getting a "no" from us, deciding they want to do this anyway so they publish their own (unsanctioned, of course) IMAP extension onl…
As an individual participant:
I don't think this is yet deployed, but there is a need in something 
like that and yes, there is a risk that OMA will do the job if IETF says 
"no", but does so badly. (Not a strong argument to do anything, but if 
we (IETF) want to help, I think we should.)

I am happy to work on something in this space. But I am not going to do 
that if nobody else is interested.
(I don't have an opinion yet on whether this belongs to APPSAWG, but I 
am happy to help out either way.)

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 10 Jan 2012 11:56:55 -0800 (PST)

> feedback to their provider's spam filters.

I agree it's part of an integrated system, but what I'm trying to get at 
is that it's a standalone component within the whole.  While the service 
presents itself as a part of the MUA, it's not part of the message store 
itself (any more than the MUA's SMTP client functionlity is).

As for configuration, I'm reasonably confident this can be managed with 
SRV records, and would expect many implementations would share the same 
authentication credentials with the message store, so it should be 
possible to roll this out in many cases with no extra configuration 
required by the end user.

--lyndon

---

From: "John R. Levine" <[email-masked]>
Date: 10 Jan 2012 15:34:55 -0500

> that it's a standalone component within the whole.  While the service 

Sorry, that's just plain wrong.  Look at any web mail.  The spam button 
identifies a message in the mailbox as being spam or not-spam.  If the 
spam button isn't part of the message store, neither is marking a message 
as already read.

> SRV records, ...

We debated this at length in ASRG.  Your confidence appears to be 
misplaced.

Regards,

---

From: SM <[email-masked]>
Date: Tue, 10 Jan 2012 12:57:04 -0800

>I posted a draft-ordogh-spam-reporting-using-imap-kleansed-00 with

In my opinion, this is not a good idea.

>likes and repost the result as version -01 of its draft

Zoltan Ordogh and Alessandro Vesely are listed as the author/editor 
of draft-ordogh-spam-reporting-using-imap-kleansed-00.  Are they 
stating on behalf of Research In Motion Limited that IPR disclosure 
#1609 is not applicable for draft-ordogh-spam-reporting-using-imap-kleansed-00?

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 11 Jan 2012 10:34:30 +0100

On 10/Jan/12 21:57, SM wrote:
>> I posted a draft-ordogh-spam-reporting-using-imap-kleansed-00
> 

Agreed, but after a short mumbling I thought this attempt at least
wouldn't be harmful.

I have the (hopefully wrong) feeling that the bureaucratically correct
path would take decades before a "Spam" button can be enjoyed on
mobile and desktop IMAP devices alike.  A simple and unencumbered IMAP
command can be standardized and implemented rather quickly, and
satisfactorily for all involved parties --except spammers, maybe.

> Zoltan Ordogh and Alessandro Vesely are listed as the author/editor of
> draft-ordogh-spam-reporting-using-imap-kleansed-00.  Are they stating
> on behalf of Research In Motion Limited that IPR disclosure #1609 is
> not applicable for draft-ordogh-spam-reporting-using-imap-kleansed-00?

Not only I cannot speak for RIM, but I have never actually seen that
patent application.  I'm looking forward for a RIM's statement that
either confirms or denies that that patent does not apply to a reduced
version like the one I posted.  I'm confident that my post can be
deleted promptly in case RIM gives a negative response.

The IPR is filed here:
https://datatracker.ietf.org/ipr/1609/

The kleansed version is here:
http://datatracker.ietf.org/doc/draft-ordogh-spam-reporting-using-imap-kleansed/

Sincerely,
Alessandro Vesely

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jan 2012 12:27:43 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Wednesday, January 11, 2012 1:35 AM
> To: [email-masked]; Jon M. Jurgovan
> Cc: Sarah Guichard

This looks and feels a lot like the IPR claim Yahoo! made against DomainKeys (RFC4870).  The difference here, I think, is that Yahoo! also offered into the public domain an open source implementation of DK.  Does RIM plan to do something like that too?

Otherwise, I'm concerned that we will be contributing, presumably for "free", support in development of this toward the standards track where the beneficiary is RIM.  Not a very "open" approach to an open standards body.  I personally wouldn't be inclined to be very supportive.

Hopefully RIM can give us some good assurances that this is all on the level.  Or give us all free Blackberries.

-MSK

---

From: Zoltan Ordogh <[email-masked]>
Date: Fri, 13 Jan 2012 19:11:17 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: January 9, 2012 1:51 PM
To: [email-masked]
Subject: [apps-discuss] Spam reporting over IMAP

Thanks,

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.

---

From: SM <[email-masked]>
Date: Sat, 14 Jan 2012 04:00:29 -0800

Hi Zoltan,
At 11:11 13-01-2012, Zoltan Ordogh wrote:
>Instead of responding to individual emails one by one, I try to 
>clarify some of the concerns at least in a single response.

The single response does not address the issue I raised ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04079.html ).

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

draft-ordogh-spam-reporting-using-imap-kleansed-00 lists Zoltan 
Ordogh, Research In Motion Limited, as the author of the 
Internet-Draft.  The document states that:

   "This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79."

Do you have any concerns about 
draft-ordogh-spam-reporting-using-imap-kleansed-00 in respect to BCP 
78 and BCP 79?

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 14 Jan 2012 14:32:26 +0100

Hi Zoltan,

> I would like to start with a story.

A rather similar story is summarized here:
http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs

> A bit later, a liaison statement was sent from OMA to IETF, seeking
> collaboration and a “home” for the draft; as required by RFC3975.

I assume you're still talking about SREP.  I read a reply by John
Klensin, whom I consider a sort of IETF guru, and it didn't prospect a
bright future for the draft.  I posted a "kleansed" version trying to
address some of those concerns, in an attempt to improve the chances
that APPSAWG will adopt it.  Somewhat arbitrarily, I changed the IPR
qualification of the document too.  In fact, I had the impression that
the IPR was that way because OMA SpamRep was being mentioned, albeit
not being specified, and also because that was one of the points raised.

I hope my editing was correct, but your approval as author is needed.

> PS. I am solely a technical contributor,

So am I (but I signed no contract.)

> so asking me IPR-related questions will always be a dead end.

As a survival requirement, you have to be able to answer SM's
question, though.

> Please direct those questions directly to the appropriate contact
> person, which, in, this case is Sarah Guichard.

I sent my previous comment on this to Jon M. Jurgovan, cc Sarah
Guichard, but had no reply either.

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

The above boilerplate formally makes of no effect whatever else you
wrote in that message, according to Andrew's explanation:
http://www.ietf.org/mail-archive/web/ietf/current/msg67516.html

I usually group these issues to the same bin I use for IPRs, as I
guess many others on this list do.  Unfortunately, at times they
become relevant, which is why we have to deal with them.  See
"survival" above :-)

Specifically, if you need a written authorization of your employer in
order to contribute technical specifications to the IETF under IETF's
terms, please ask them to provide it.  I guess we need that paperwork.

Ciao
Ale

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Jan 2012 12:40:06 -0500

--On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely
<[email-masked]> wrote:

>...
>> A bit later, a liaison statement was sent from OMA to IETF,
>> seeking collaboration and a "home" for the draft; as
>> required by RFC3975.
> 
> I assume you're still talking about SREP.  I read a reply by
> John Klensin, whom I consider a sort of IETF guru, and it
> didn't prospect a bright future for the draft.  I posted a
> "kleansed" version trying to address some of those concerns,
> in an attempt to improve the chances that APPSAWG will adopt
> it.  Somewhat arbitrarily, I changed the IPR qualification of
> the document too.  In fact, I had the impression that the IPR
> was that way because OMA SpamRep was being mentioned, albeit

>...

Alessandro, Zoltan,

Guru or not (some would certainly dispute that), this is
strictly a personal comment and personal opinion.  Just to
clarify my view of this (other may have different opinions)...

(1) I think SM's question, and anything else having to do with
the IRP status of this document (or pair of documents) has to be
completely clear.   The IETF could certainly decide to process
the document even if the technology were encumbered (has
happened many times before), but uncertainty is pretty much a
showstopper.  Alessandro's concerns about distribution
disclaimers on email messages that discuss the topic only
reinforce my concern in this area.

(2) Similarly, both of you, and RIM and OMA, need to understand
that handing something like this off to IETF, especially for
standards-track processing, is a handoff of change control.  The
IETF can modify (we hope improve) things as it likes, even after
approval of the first version of the document as a Proposed
Standard.  Joint ownership/ change control arrangements are
possible, but they are very hard and time-consuming to negotiate
and perhaps, due to some bad experience, likely to get harder.

(3) The leadership of AppAWG, and the ADs, will do as they think
appropriate, but, if I were making the rules, no one would spend
energy trying to sort out the differences between a pair of
competing documents.  I suggest that the two of you get
together, offlist, and see if you can reach clear agreement on a
single draft that supercedes both documents.  That is a matter
of courtesy to those of us you are asking to consider the work
and is quite independent of the IPR concerns (although they do
interact).

All three of those issues are administrative, not technical.
They should be easily solved.  My personal preferences is that
the AppsAWG, and the apps-discuss list, spend no more time on
this until/unless they are resolved.  YMMD, of course.

(4) The core of my previous comments was a technical concern,
not an administrative one.  Even if one ignores the security
concerns, the stability issues for normative references, and so
on, many of us believe that the IMAP protocol has become far too
complicated, with too many options and features.  That
complexity increases the requirements on IMAP servers that wish
to support a wide range of clients and applications and on
clients that wish to support a reasonable range of features but
work with servers that may not support all of them.   Whatever
the advantages, too much code and too many code paths are not
conducive to very high quality, bug-free, implementations.

This proposal seems to me to take IMAP into a whole new area.
I'm not questions whether or not that is possible because I'd be
certain it would be, even without the assertiosn that there are
implementations out there.  I am questioning whether there is a
strong enough case to be made that this belongs in IMAP to
justify further clutter in the protocol and even lower odds of
seeing high-quality clients.  I observe that probably the best
general-purpose --as distinct from, e.g., specialized for mobile
devices-- IMAP client out there is now quite old, largely
unmaintained, and has not picked up on any of the new features
added in the last several years.    Neither version of the
document really addresses that issue.  Some of  the comments
from the two of you about why it is hard and/or expensive to do
it in other ways certainly have merit, but need, IMO, to be
balanced off against other considerations including the above.
That balance won't be easy to find especially since, as I am
sure you both know, there is no community agreement about the
degree to which it is appropriate to make normal, desired, email
work worse in order to provide better facilities for
spam-handling, especially spam-handling at or after the final
delivery MTA.

Bottom line: I think we should see a single draft that really
addresses all of the technical issues, including the design
tradeoffs and security topics, _and_ addresses the
IPR/administrative one in a way with which we can all be
comfortable before being asked to decide whether AppsAWG should
take this up.   If asked to make a decision without such a draft
having been posted, I would vote "no".

   john