Subject: Re: Exception handling
From: Keith Moore <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Date: Wed, 29 Sep 2010 18:33:01 -0400
List-Id: <ietf-822.imc.org>

On Sep 29, 2010, at 3:31 AM, Hector Santos wrote:

> 
> SM wrote:
>> Hi Murray,
>> At 15:48 28-09-10, Murray S. Kucherawy wrote:
>>> In some R&D I'm doing I'm comparing numerous MTAs about how they handle things like a non-header line before CRLF between the header and body.  I'm trying to figure out if there's a rough consensus among them about how to handle such exceptions.
>> Documenting the exception handling is useful.
>>> Would a compilation of the results of that investigation be a useful candidate for publication as a BCP or Informational?
>> I suggest Informational.  If you are aiming for consensus on how to handle the exceptions, it can end up being more work that it is worth.
> 
> +1.
> 
> There are all kinds of issues here that I don't think a tabulation of MTAs will correctly represent.
> 
> It could be a matter of a "Switch" for strict vs Relax 822/2822/5322 compliance.  A few years back in this group we had a long discussion about the level of 822 vs 2822 compliance and how some MTA will have their own "extended" rules for what is considered "valid headers." Many just look for the basic requirements - a combo of To/CC, From and/or Date and then for the double <crlf><crlf> to point to the body.  So if there any junk in the headers, it can be passed thru.  We have four operational options here:
> 
>   Strict 822   From, Date and to/cc
>   Strict 2822  From, Date
>   Strict {OurBrand} with header syntax checking
>   Relaxed {OurBrand} which includes a "Received" line (DEFAULT)
> 
> There are 20+ years in the making and years past attempts to go strict (enforce by default) failed miserably in the support area.  Regardless if it was just a few people, it created a 'surprise' and support cost.
> 
> Recently I created a DATA filter script to check for multiple From: headers. The script will immediately reject it if more than one From: is found.   I just added the logic to check for the last header line to see if its complaint.  No reject though, just logging to check numbers if any.
> 
> What will be useful is to also test the numerous MUAs. I know OE and Thunderbird will hide, ignore, skip and not show the errant header lines.

IMO, With a few notable exceptions (e.g. submission servers, spam filters, gateways to foreign systems), MTAs shouldn't be checking message headers at all.  The problem is that a message typically has to pass through several MTAs.  Every one of those MTAs is an opportunity for rejection of a valid message - should that MTA's code either be buggy or deliberately reject something that happens to be reasonable.   Even if a message is malformed in some way according to 822, 2822, and/or 5322, that does not mean it's not valuable to the recipient.  When MTAs check message headers, that's a layering violation.

Keith

From: [email-masked]
Cc: Tony Hansen <[email-masked]>, [email-masked]
Date: Wed, 29 Sep 2010 14:34:25 -0700 (PDT)
Subject: Re: Exception handling
To: "Carl S. Gutekunst" <[email-masked]>
Sender: [email-masked]

> Tony Hansen wrote:
> >> That has it's problems, too. I had an issue with a legit corporate
> >> sender that added a malformed header line in the middle, before the
> >> From: and To: fields. Result was that people's filters didn't work.
> > Garbage input leads to "interesting" results, no matter what choice
> > was taken.

> Sure, just sayin' that both approaches resulted in calls to customer
> service. In my experience, though, most of the time when the receiver
> inserted the blank line, it was inserted in the correct place.

We provide both options, by the default is to insert, and we've found it
generates fewer calls.

There are other malformations that aren't so clear cut, though. The example
that immediately comes to mind is:

    Content-type: multipart/mixed; boundary=whatever
    Content-transfer-encoding: base64

As of today, when we see exampples of this it usually means the multipart isn't
encoded and the line needs to be ignored to properly process the messsage. But
some years back the odds were it meant the part really was encoded, never mind
the nested encoding prohibition. The best handling choice has changed over
time.

But if EAI is successful the nested encoding restirction is going to go away.
that may tilt this back the other direction, for subtypes of message at least.

We actually get reports of issues with this malformation a lot more often than
we see problems with header termination.

				Ned

Date: Wed, 29 Sep 2010 08:58:40 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: Exception handling
Sender: [email-masked]

Tony Hansen wrote:
>> That has it's problems, too. I had an issue with a legit corporate 
>> sender that added a malformed header line in the middle, before the 
>> From: and To: fields. Result was that people's filters didn't work.
> Garbage input leads to "interesting" results, no matter what choice 
> was taken.

Sure, just sayin' that both approaches resulted in calls to customer 
service. In my experience, though, most of the time when the receiver 
inserted the blank line, it was inserted in the correct place.

<csg>

Date: Wed, 29 Sep 2010 11:53:45 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Exception handling
Sender: [email-masked]

On 9/29/2010 11:03 AM, Carl S. Gutekunst wrote:
>
> Hector Santos wrote:
>> There are 20+ years in the making and years past attempts to go 
>> strict (enforce by default) failed miserably in the support area.  
>> Regardless if it was just a few people, it created a 'surprise' and 
>> support cost. 
>
> Yep. Everywhere I've worked, I wanted to reject mail that was missing 
> the blank line (CRLF) between header and body. And everywhere I've 
> worked, my employer mandated otherwise because rejecting such mails 
> was a call generator. So, I've always implicitly inserted that blank 
> line at the point where I encounter text that doesn't appear to be a 
> header line.
All SMTP implementations I've ever been involved in have chosen this tactic.

> That has it's problems, too. I had an issue with a legit corporate 
> sender that added a malformed header line in the middle, before the 
> From: and To: fields. Result was that people's filters didn't work.
Garbage input leads to "interesting" results, no matter what choice was 
taken.

     Tony Hansen

Date: Wed, 29 Sep 2010 08:03:08 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked]
Subject: Re: Exception handling
Sender: [email-masked]

Hector Santos wrote:
> There are 20+ years in the making and years past attempts to go strict 
> (enforce by default) failed miserably in the support area.  Regardless 
> if it was just a few people, it created a 'surprise' and support cost. 

Yep. Everywhere I've worked, I wanted to reject mail that was missing 
the blank line (CRLF) between header and body. And everywhere I've 
worked, my employer mandated otherwise because rejecting such mails was 
a call generator. So, I've always implicitly inserted that blank line at 
the point where I encounter text that doesn't appear to be a header line.

That has it's problems, too. I had an issue with a legit corporate 
sender that added a malformed header line in the middle, before the 
From: and To: fields. Result was that people's filters didn't work.

I'm wondering, though, how many non-OSS companies will want to reveal 
what they do with invalid header lines. If my past experience is any 
guide, few will, since (as Hector noted) they're often part of the 
anti-spam strategy, and non-OSS companies don't like "revealing their 
secrets to the bad guys." Or something like that.

<csg>

Date: Wed, 29 Sep 2010 03:31:56 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
Subject: Re: Exception handling
Sender: [email-masked]

SM wrote:
> 
> Hi Murray,
> At 15:48 28-09-10, Murray S. Kucherawy wrote:
>> In some R&D I'm doing I'm comparing numerous MTAs about how they 
>> handle things like a non-header line before CRLF between the header 
>> and body.  I'm trying to figure out if there's a rough consensus among 
>> them about how to handle such exceptions.
> 
> Documenting the exception handling is useful.
> 
>> Would a compilation of the results of that investigation be a useful 
>> candidate for publication as a BCP or Informational?
> 
> I suggest Informational.  If you are aiming for consensus on how to 
> handle the exceptions, it can end up being more work that it is worth.

+1.

There are all kinds of issues here that I don't think a tabulation of 
MTAs will correctly represent.

It could be a matter of a "Switch" for strict vs Relax 822/2822/5322 
compliance.  A few years back in this group we had a long discussion 
about the level of 822 vs 2822 compliance and how some MTA will have 
their own "extended" rules for what is considered "valid headers." 
Many just look for the basic requirements - a combo of To/CC, From 
and/or Date and then for the double <crlf><crlf> to point to the body. 
  So if there any junk in the headers, it can be passed thru.  We have 
four operational options here:

    Strict 822   From, Date and to/cc
    Strict 2822  From, Date
    Strict {OurBrand} with header syntax checking
    Relaxed {OurBrand} which includes a "Received" line (DEFAULT)

There are 20+ years in the making and years past attempts to go strict 
(enforce by default) failed miserably in the support area.  Regardless 
if it was just a few people, it created a 'surprise' and support cost.

Recently I created a DATA filter script to check for multiple From: 
headers. The script will immediately reject it if more than one From: 
is found.   I just added the logic to check for the last header line 
to see if its complaint.  No reject though, just logging to check 
numbers if any.

What will be useful is to also test the numerous MUAs. I know OE and 
Thunderbird will hide, ignore, skip and not show the errant header lines.

-- 
HLS

Date: Tue, 28 Sep 2010 21:06:21 -0700
To: "Murray S. Kucherawy" <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Exception handling
Cc: [email-masked]
Sender: [email-masked]

Hi Murray,
At 15:48 28-09-10, Murray S. Kucherawy wrote:
>In some R&D I'm doing I'm comparing numerous MTAs about how they 
>handle things like a non-header line before CRLF between the header 
>and body.  I'm trying to figure out if there's a rough consensus 
>among them about how to handle such exceptions.

Documenting the exception handling is useful.

>Would a compilation of the results of that investigation be a useful 
>candidate for publication as a BCP or Informational?

I suggest Informational.  If you are aiming for consensus on how to 
handle the exceptions, it can end up being more work that it is worth.

Regards,
-sm 

Date: Tue, 28 Sep 2010 20:19:21 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Murray S. Kucherawy" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Exception handling
Sender: [email-masked]

yes.

d/

On 9/28/2010 3:48 PM, Murray S. Kucherawy wrote:
> Would a compilation of the results of that investigation be a useful candidate
> for publication as a BCP or Informational?

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 28 Sep 2010 15:48:47 -0700
Subject: Exception handling
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_F5833273385BB34F99288B3648C4F06F13407BABF7EXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In some R&D I'm doing I'm comparing numerous MTAs about how they handle thi=
ngs like a non-header line before CRLF between the header and body.  I'm tr=
ying to figure out if there's a rough consensus among them about how to han=
dle such exceptions.

Would a compilation of the results of that investigation be a useful candid=
ate for publication as a BCP or Informational?

-MSK

--_000_F5833273385BB34F99288B3648C4F06F13407BABF7EXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DWordSection1>

<p class=3DMsoNormal>In some R&amp;D I&#8217;m doing I&#8217;m comparing nu=
merous
MTAs about how they handle things like a non-header line before CRLF betwee=
n
the header and body.&nbsp; I&#8217;m trying to figure out if there&#8217;s =
a rough consensus
among them about how to handle such exceptions.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Would a compilation of the results of that investigati=
on be
a useful candidate for publication as a BCP or Informational?<o:p></o:p></p=
>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>-MSK<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

--_000_F5833273385BB34F99288B3648C4F06F13407BABF7EXCHC2corpclo_--

Date: Fri, 24 Sep 2010 01:19:03 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Stephan Wehner <[email-masked]>
CC: [email-masked]
Subject: Re: Length Limit for display-name
Sender: [email-masked]

Stephan Wehner wrote:
>> Again, you're dreaming if you think this is true.
> 
> Alright, let's look at an alternative to what I'm trying to do.
> 
> How is it with using Optional Fields (section 3.6.8). Are they safe with respect
> to "intermediaries perform[ing] all sorts of processing of header fields"?
> 
> Stephan

I think we all work on the premise that "passthru" mail is "safe." 
That has been the rule of thumb.

But you never know what mail flows, paths and channels exist and do 
all sorts of things.

In our system, there is a heterogeneous network transformation to a 
common structure and from there are XYZ transformations back into XYZ 
network or channels or no transformations at all.  You never know what 
has been filtered or persistent with optional fields.

-- 
Hector, Engineering & Technical Support
Santronics Software, Inc.
http://www.santronics.com (sales)
http://www.winserver.com (support)
http://www.winserver.com/AupInfo (Online AUP Help)
Office: 305-248-3204

Date: Fri, 24 Sep 2010 09:57:06 +0530
Subject: Re: Length Limit for display-name
From: Arnt Gulbrandsen <[email-masked]>
To: Stephan Wehner <[email-masked]>, [email-masked]
Sender: [email-masked]

Intermediaries may case-smash such header field names, reorder the fields, and/or remove the fields altogether, but I can't recall having seen anything else.

Arnt

From: [email-masked]
Cc: [email-masked]
Date: Thu, 23 Sep 2010 16:43:48 -0700 (PDT)
Subject: Re: Length Limit for display-name
To: Stephan Wehner <[email-masked]>
Sender: [email-masked]

> Alright, let's look at an alternative to what I'm trying to do.

Perhaps you should describe what you're trying to do. It's very difficult
to make suggesions without knowing the semantics you're trying to get.

> How is it with using Optional Fields (section 3.6.8). Are they safewith respect
> to "intermediaries perform[ing] all sorts of processing of header fields"?

First of all, the semantics of display-names and optional headers are very
different. A display-name is always associated with a header address. If
whatever you're doing needs to track along with header addresses, then optional
fields do not offer a solution, because agents that mess with header
addresses won't know to make the corresponding change in your private
information fields.

OTOH, if whatever you're doing isn't associated with header addresses, then you
shouldh't have tried to cram the information into a display-name to begin with.

Now, as for using optional fields, the answer is that as long as you pick one
nobody else is using for something, I'd say they're safe up to 4K octets or so.
(You can also use more than one if you need the space.) Beyond that you may
start running into implementation limits again. Putting a vendor name in the
field name is often a good plan - it makes it far less likely some else will
use it for something different.

You'll need to properly fold the field if it is very long, and you should
be tolerant of folding changes.

				Ned

Date: Thu, 23 Sep 2010 15:32:54 -0700
Subject: Re: Length Limit for display-name
From: Stephan Wehner <[email-masked]>
To: [email-masked]
Sender: [email-masked]

On Mon, Sep 20, 2010 at 12:44 PM, Ned Freed <[email-masked]> wrote:
>
>> For example, qmail-remote, and gateways when
>> passing a message to another server. Here
>> I thought the To: header being within the message they would not touch
>> it, or parse it and just pass it on, so
>> that "trace fields are prepended to the message" (A.4 in the Appendix )

> Dream on. That's not how things work in th real world. Lots of intermediaries
> perform all sorts of processing of header fields. The legality or illegality of
> doing this is mostly irrelevant, since you have to deal with what's out there,
> not what the standards-writers hoped would be out there, but even then,
> specific header modifications are specifically condoned by vaiorus standards,
> e.g., MIME downgrading.

> In the specific case of To: fields, an obvious one is for submission servers to
> rewrite addresses to eliminae short form names and other local crap.
> The answer is no, you cannot count on it.
>
>> I would think only
>> the total email length limit would come
>> into play, which is usually pretty large (measured in MB)
>
> Again, you're dreaming if you think this is true.

Alright, let's look at an alternative to what I'm trying to do.

How is it with using Optional Fields (section 3.6.8). Are they safewith respect
to "intermediaries perform[ing] all sorts of processing of header fields"?

Stephan

>>                                Ned
>

-- 
Stephan Wehner

-> http://stephan.sugarmotor.org (blog and homepage)
-> http://loggingit.com
-> http://www.thrackle.org
-> http://www.buckmaster.ca
-> http://www.trafficlife.com
-> http://stephansmap.org -- http://blog.stephansmap.org
-> http://twitter.com/stephanwehner / @stephanwehner

Subject: RE: multipart/report
Date: Wed, 22 Sep 2010 01:11:29 -0700
Content-class: urn:content-classes:message
From: "Alex Bobotek" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB5A2D.C26AF0A6
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01CB5A2D.C26AF0A6"

------_=_NextPart_002_01CB5A2D.C26AF0A6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This issue was raised (without resolution or even near-consensus
guidance) in the MARF WG at IETF78.  Here's some reference material (1
and 2 below) and an additional question (3 below). =20

=20

1.        There is a document at=20
http://www.ietf.org/proceedings/78/slides/marf-0.pdf describing this
issue.  While it is no-longer up-to-date in that the SpamRep MIME
structure has been changed to promote OMA/IETF convergence, it provides
background.=20

2.       The current Open Mobile Alliance (OMA) SpamRep MIME structures
are described in Section 5 of the draft SpamRep specification available
at: =20
http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRe
p/Permanent_documents/OMA-TS-SpamRep-V1_0-20100913-D.zip .  The two most
important structures are the single report "Simple SpamRep Message" and
the multi-report "Complex SpamRep Message," illustrated below.

SpamRep Document (XML, application/vnd.oma.spamrep+xml)

 =20
   =20

or                                                ...

 =20

[Optional:  Spam Content]

 =20

Human Readable text (e.g., "OMA Spam Report:  Spam received by
+12062187967")=20

 =20
=20

=20

=20

   =20

multipart/mixed

=20

=20

=20

=20

=20

=20

        ...

=20

 =20

Human Readable text (e.g., "This is a collection of OMA Spam Reports")=20

 =20
              =20

=20

=20

3.        An issue not raised in Murry's message is whether and how to
promote spam reports that are readable by both RFC5965 and SpamRep
servers.  One possibility is to allow the second part of the
multipart/report to be a multipart/alternative MIME part.  This
multipart/alternative might contain two or more MIME parts, including
both OMA-defined application/vnd.oma.spamrep+xml and RFC5965-defined
message/feedback-report MIME parts.  To comply with the letter (yet
perhaps not the spirit) of RFC3462, an outer(most) MIME type would need
to be 'multipart/report, report-type=3Dalternative'.  What is the =
group's
reaction to this? =20

=20

=20

Regards,

=20

Alex Bobotek

=20

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Murray S. Kucherawy
Sent: Tuesday, September 21, 2010 10:53 PM
To: [email-masked]
Subject: multipart/report

=20

I'm doing some work with the OMA in the area of spam reporting.  They
have developed an XML message format for reporting spam from a mobile
handset.  Because SMS and MMS (and even IM) have different structure
than email, they went with something more extensible than what we
currently do with DSNs.  I'm helping that group try to converge with
what we do in the email world, especially with what the MARF working
group is producing (e.g., ARF, specified by recently-published RFC5965).
The first thing is to register the MIME type they've created, and so
I've crafted a template for that.

=20

The next thing we'd like to achieve is to be able to specify multiple
spam reports in a single message, regardless of transport (they
currently use HTTP POST, but there's no reason SMTP couldn't be used).
The most obvious thing to do would be to use a multipart/mixed MIME
message, and then include their MIME type in each of "n" parts.
However, this is different than what was done with ARF, which used
multipart/report.  The advantage to using multipart/report, which
stipulates that it must be the outermost MIME type, is that you know
right away that you're processing a report rather than having to parse
part way into the MIME tree to figure that out.  (According to Tony
Hansen, that's why this rule was put in place.)  But although
multipart/report is the most obvious construct for doing this, it
doesn't lend itself to multi-report messages.  So to get these to
converge, we have to be a little creative or be very creative (in the
"create a lot of documents" sense).

=20

We could do a message/digest, each sub-part of which is message/rfc822
and the MIME type within that is multipart/report.  One could argue that
this approach conforms to the multipart/report rules by having that be
the outermost MIME part of each constituent message in the aggregate
message, but that might be hard to defend given the spirit of that rule.

=20

There's also a stipulation that the MIME subtype of the second part in a
multipart/report message must be equal to the report-type of the
outermost part, with no other constraints.  Thus to keep
multipart/report at the outermost MIME but allow multi-message reports,
we could comply by using "multipart/report; report-type=3Dmixed" as the
outermost MIME type and then use "multipart/mixed" inside.  But this
also sure feels hack-ish.

=20

So what would be more palatable to this community?  Could
multipart/report be updated to accommodate this use case?  Should we
register multipart/multi-report that relaxes some of the existing
restrictions without changing the existing media type?

=20

Feedback/guidance is welcome.

=20

-MSK

------_=_NextPart_002_01CB5A2D.C26AF0A6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
 /* List Definitions */
 @list l0
	{mso-list-id:22102135;
	mso-list-type:hybrid;
	mso-list-template-ids:-1109636010 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.75in;
	text-indent:-.25in;}
@list l1
	{mso-list-id:734861661;
	mso-list-type:hybrid;
	mso-list-template-ids:-1548980470 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2
	{mso-list-id:884950460;
	mso-list-type:hybrid;
	mso-list-template-ids:-1548980470 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3
	{mso-list-id:1521820485;
	mso-list-type:hybrid;
	mso-list-template-ids:-686661202 67698689 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l3:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
@list l3:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1040" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DWordSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This issue was raised =
(without
resolution or even near-consensus guidance) in the MARF WG at =
IETF78.&nbsp; Here&#8217;s
some reference material (1 and 2 below) and an additional question (3 =
below).&nbsp;
<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l2 =
level1 lfo2'><![if !supportLists]><span
style=3D'color:#1F497D'><span style=3D'mso-list:Ignore'>1.<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'color:#1F497D'>&nbsp;There =
is a document
at <a =
href=3D"http://www.ietf.org/proceedings/78/slides/marf-0.pdf">http://www.=
ietf.org/proceedings/78/slides/marf-0.pdf</a>
describing this issue.&nbsp; While it is no-longer up-to-date in that =
the
SpamRep MIME structure has been changed to promote OMA/IETF convergence, =
it
provides background. <o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l2 =
level1 lfo2'><![if !supportLists]><span
style=3D'color:#1F497D'><span style=3D'mso-list:Ignore'>2.<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'color:#1F497D'>The current =
Open
Mobile Alliance (OMA) SpamRep MIME structures are described in Section 5 =
of the
draft SpamRep specification available at:&nbsp; <a
href=3D"http://member.openmobilealliance.org/ftp/Public_documents/COM/COM=
-SpamRep/Permanent_documents/OMA-TS-SpamRep-V1_0-20100913-D.zip">http://m=
ember.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/Permane=
nt_documents/OMA-TS-SpamRep-V1_0-20100913-D.zip</a>
.&nbsp; The two most important structures are the single report =
&#8220;Simple
SpamRep Message&#8221; and the multi-report &#8220;Complex SpamRep =
Message,&#8221;
illustrated below.<o:p></o:p></span></p>

<p class=3DMsoNormal><!--[if gte vml 1]><v:shapetype id=3D"_x0000_t202"=20
 coordsize=3D"21600,21600" o:spt=3D"202" =
path=3D"m,l,21600r21600,l21600,xe">
 <v:stroke joinstyle=3D"miter" />
 <v:path gradientshapeok=3D"t" o:connecttype=3D"rect" />
</v:shapetype><v:shape id=3D"_x0000_s1033" type=3D"#_x0000_t202" =
style=3D'position:absolute;
 =
margin-left:21pt;margin-top:65.3pt;width:348.4pt;height:66.35pt;z-index:2=
51660288'>
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1033' />
</v:shape><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251660288;margin-left:27px;margin-top:86px;width:471px;
height:95px'>

<table cellpadding=3D0 cellspacing=3D0>
 <tr>
  <td width=3D471 height=3D95 bgcolor=3Dwhite style=3D'border:.75pt =
solid black;
  vertical-align:top;background:white'><![endif]><![if !mso]><span
  style=3D'position:absolute;mso-ignore:vglayout;z-index:251660288'>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div v:shape=3D"_x0000_s1033" style=3D'padding:4.35pt 7.95pt 4.35pt =
7.95pt'
    class=3Dshape>
    <p class=3DMsoNormal>SpamRep Document (XML, =
application/vnd.oma.spamrep+xml)<span
    style=3D'font-size:8.0pt'><o:p></o:p></span></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  </span><![endif]><![if !mso & !vml]>&nbsp;<![endif]><![if !vml]></td>
 </tr>
</table>

</span><![endif]><!--[if gte vml 1]><v:rect id=3D"_x0000_s1037" =
style=3D'position:absolute;
 =
margin-left:30.7pt;margin-top:81.5pt;width:63pt;height:42.9pt;z-index:251=
664384'>
 <v:stroke dashstyle=3D"1 1" />
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1037'>
  <![if !mso]>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div>
    <p class=3DMsoNormal>Spam Report<o:p></o:p></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  <![endif]></v:textbox>
</v:rect><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251664384;margin-left:40px;margin-top:108px;width:90px;
height:63px'><img width=3D90 height=3D63 =
src=3D"cid:[email-masked]"
alt=3D"Text Box: Spam Report" =
v:shapes=3D"_x0000_s1037"></span><![endif]><!--[if gte vml 1]><v:rect=20
 id=3D"_x0000_s1039" =
style=3D'position:absolute;margin-left:255.55pt;margin-top:81.5pt;
 width:75.55pt;height:42.9pt;z-index:251666432'>
 <v:stroke dashstyle=3D"1 1" />
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1039'>
  <![if !mso]>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div>
    <p class=3DMsoNormal>(Etc.)</p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  <![endif]></v:textbox>
</v:rect><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251666432;margin-left:340px;margin-top:108px;width:106px=
;
height:63px'><img width=3D106 height=3D63 =
src=3D"cid:[email-masked]"
alt=3D"Text Box: (Etc.)" =
v:shapes=3D"_x0000_s1039"></span><![endif]><!--[if gte vml 1]><v:rect=20
 id=3D"_x0000_s1038" =
style=3D'position:absolute;margin-left:140.65pt;margin-top:81.5pt;
 width:66.45pt;height:42.9pt;z-index:251665408'>
 <v:stroke dashstyle=3D"1 1" />
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1038'>
  <![if !mso]>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div>
    <p class=3DMsoNormal>Action<o:p></o:p></p>
    <p class=3DMsoNormal>Request<o:p></o:p></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  <![endif]></v:textbox>
</v:rect><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251665408;margin-left:187px;margin-top:108px;width:94px;=

height:63px'><img width=3D94 height=3D63 =
src=3D"cid:[email-masked]"
alt=3D"Text Box: Action&#13;&#10;Request&#13;&#10;" =
v:shapes=3D"_x0000_s1038"></span><![endif]><!--[if gte vml 1]><v:shape=20
 id=3D"_x0000_s1034" type=3D"#_x0000_t202" =
style=3D'position:absolute;margin-left:94pt;
 margin-top:92.8pt;width:183.65pt;height:26.15pt;z-index:251661312' =
stroked=3D"f">
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1034' />
</v:shape><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251661312;margin-left:125px;margin-top:124px;width:249px=
;
height:39px'>

<table cellpadding=3D0 cellspacing=3D0>
 <tr>
  <td width=3D249 height=3D39 bgcolor=3Dwhite =
style=3D'vertical-align:top;background:
  white'><![endif]><![if !mso]><span =
style=3D'position:absolute;mso-ignore:vglayout;
  z-index:251661312'>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div v:shape=3D"_x0000_s1034" style=3D'padding:3.6pt 7.2pt 3.6pt =
7.2pt'
    class=3Dshape>
    <p =
class=3DMsoNormal>or&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;
    &#8230;<o:p></o:p></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  </span><![endif]><![if !mso & !vml]>&nbsp;<![endif]><![if !vml]></td>
 </tr>
</table>

</span><![endif]><!--[if gte vml 1]><v:shape id=3D"_x0000_s1035" =
type=3D"#_x0000_t202"=20
 =
style=3D'position:absolute;margin-left:21pt;margin-top:139.15pt;width:162=
.2pt;
 height:25.9pt;z-index:251662336'>
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1035' />
</v:shape><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251662336;margin-left:27px;margin-top:185px;width:222px;=

height:40px'>

<table cellpadding=3D0 cellspacing=3D0>
 <tr>
  <td width=3D222 height=3D40 bgcolor=3Dwhite style=3D'border:.75pt =
solid black;
  vertical-align:top;background:white'><![endif]><![if !mso]><span
  style=3D'position:absolute;mso-ignore:vglayout;z-index:251662336'>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div v:shape=3D"_x0000_s1035" style=3D'padding:4.35pt 7.95pt 4.35pt =
7.95pt'
    class=3Dshape>
    <p class=3DMsoNormal>[Optional:&nbsp; Spam Content]<o:p></o:p></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  </span><![endif]><![if !mso & !vml]>&nbsp;<![endif]><![if !vml]></td>
 </tr>
</table>

</span><![endif]><!--[if gte vml 1]><v:shape id=3D"_x0000_s1036" =
type=3D"#_x0000_t202"=20
 =
style=3D'position:absolute;margin-left:21pt;margin-top:31.6pt;width:348.4=
pt;
 height:28.1pt;z-index:251663360'>
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1036' />
</v:shape><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251663360;margin-left:27px;margin-top:41px;width:471px;
height:44px'>

<table cellpadding=3D0 cellspacing=3D0>
 <tr>
  <td width=3D471 height=3D44 bgcolor=3Dwhite style=3D'border:.75pt =
solid black;
  vertical-align:top;background:white'><![endif]><![if !mso]><span
  style=3D'position:absolute;mso-ignore:vglayout;z-index:251663360'>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div v:shape=3D"_x0000_s1036" style=3D'padding:4.35pt 7.95pt 4.35pt =
7.95pt'
    class=3Dshape>
    <p class=3DMsoNormal><span style=3D'color:#1F497D'>H</span>uman =
Readable text <span
    style=3D'font-size:8.0pt'>(e.g., &#8220;OMA Spam Report:&nbsp; Spam =
received
    by +12062187967&#8221;) <o:p></o:p></span></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  </span><![endif]><![if !mso & !vml]>&nbsp;<![endif]><![if !vml]></td>
 </tr>
</table>

</span><![endif]><!--[if gte vml 1]><v:rect=20
 id=3D"_x0000_s1032" =
style=3D'width:391.6pt;height:168.45pt;mso-left-percent:-10001;
 mso-top-percent:-10001;mso-position-horizontal:absolute;
 mso-position-horizontal-relative:char;mso-position-vertical:absolute;
 =
mso-position-vertical-relative:line;mso-left-percent:-10001;mso-top-perce=
nt:-10001'>
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1032'>
  <![if !mso]>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div>
    <p class=3DMsoNormal>SpamRep Statement/Simple SpamRep Message <span=20
    style=3D'font-size:8.0pt'>(multipart/report, =
report-type=3Dvnd.oma.spamrep+xml)<o:p></o:p></span></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  <![endif]></v:textbox>
 <w:wrap type=3D"none"/>
 <w:anchorlock/>
</v:rect><![endif]--><![if !vml]><img width=3D528 height=3D231
src=3D"cid:[email-masked]"
alt=3D"Text Box: SpamRep Statement/Simple SpamRep Message =
(multipart/report, report-type=3Dvnd.oma.spamrep+xml)"
v:shapes=3D"_x0000_s1032"><![endif]><!--[if gte vml 1]><v:shapetype =
id=3D"_x0000_t75"=20
 coordsize=3D"21600,21600" o:spt=3D"75" o:preferrelative=3D"t" =
path=3D"m@4@5l@4@11@9@11@9@5xe"=20
 filled=3D"f" stroked=3D"f">
 <v:stroke joinstyle=3D"miter" />
 <v:formulas>
  <v:f eqn=3D"if lineDrawn pixelLineWidth 0" />
  <v:f eqn=3D"sum @0 1 0" />
  <v:f eqn=3D"sum 0 0 @1" />
  <v:f eqn=3D"prod @2 1 2" />
  <v:f eqn=3D"prod @3 21600 pixelWidth" />
  <v:f eqn=3D"prod @3 21600 pixelHeight" />
  <v:f eqn=3D"sum @0 0 1" />
  <v:f eqn=3D"prod @6 1 2" />
  <v:f eqn=3D"prod @7 21600 pixelWidth" />
  <v:f eqn=3D"sum @8 21600 0" />
  <v:f eqn=3D"prod @7 21600 pixelHeight" />
  <v:f eqn=3D"sum @10 21600 0" />
 </v:formulas>
 <v:path o:extrusionok=3D"f" gradientshapeok=3D"t" =
o:connecttype=3D"rect" />
 <o:lock v:ext=3D"edit" aspectratio=3D"t" />
</v:shapetype><![endif]--><o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><!--[if gte vml 1]><v:rect id=3D"_x0000_s1030" =
style=3D'position:absolute;
 =
margin-left:36.3pt;margin-top:131pt;width:256.75pt;height:25.9pt;z-index:=
251658240'>
 <v:stroke dashstyle=3D"1 1" />
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1030'>
  <![if !mso]>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div>
    <p class=3DMsoNormal>SpamRep Statement #2<o:p></o:p></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  <![endif]></v:textbox>
</v:rect><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251658240;margin-left:47px;margin-top:174px;width:349px;=

height:40px'><img width=3D349 height=3D40 =
src=3D"cid:[email-masked]"
alt=3D"Text Box: SpamRep Statement #2" =
v:shapes=3D"_x0000_s1030"></span><![endif]><!--[if gte vml 1]><v:rect=20
 id=3D"_x0000_s1031" =
style=3D'position:absolute;margin-left:36.3pt;margin-top:183.6pt;
 width:256.75pt;height:25.9pt;z-index:251658240'>
 <v:stroke dashstyle=3D"1 1" />
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1031'>
  <![if !mso]>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div>
    <p class=3DMsoNormal>SpamRep Statement #N</p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  <![endif]></v:textbox>
</v:rect><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251658240;margin-left:47px;margin-top:244px;width:349px;=

height:40px'><img width=3D349 height=3D40 =
src=3D"cid:[email-masked]"
alt=3D"Text Box: SpamRep Statement #N" =
v:shapes=3D"_x0000_s1031"></span><![endif]><!--[if gte vml 1]><v:rect=20
 id=3D"_x0000_s1029" =
style=3D'position:absolute;margin-left:36.3pt;margin-top:88.15pt;
 width:256.75pt;height:28.5pt;z-index:251658240'>
 <v:stroke dashstyle=3D"1 1" />
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1029'>
  <![if !mso]>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div>
    <p class=3DMsoNormal>SpamRep Statement #1 <o:p></o:p></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  <![endif]></v:textbox>
</v:rect><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251658240;margin-left:47px;margin-top:117px;width:349px;=

height:44px'><img width=3D349 height=3D44 =
src=3D"cid:[email-masked]"
alt=3D"Text Box: SpamRep Statement #1 " =
v:shapes=3D"_x0000_s1029"></span><![endif]><!--[if gte vml 1]><v:shape=20
 id=3D"_x0000_s1027" type=3D"#_x0000_t202" =
style=3D'position:absolute;margin-left:21pt;
 margin-top:65.3pt;width:348.4pt;height:185.45pt;z-index:251658240'>
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1027' />
</v:shape><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251658240;margin-left:27px;margin-top:86px;width:471px;
height:253px'>

<table cellpadding=3D0 cellspacing=3D0>
 <tr>
  <td width=3D471 height=3D253 bgcolor=3Dwhite style=3D'border:.75pt =
solid black;
  vertical-align:top;background:white'><![endif]><![if !mso]><span
  style=3D'position:absolute;mso-ignore:vglayout;z-index:251658240'>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div v:shape=3D"_x0000_s1027" style=3D'padding:4.35pt 7.95pt 4.35pt =
7.95pt'
    class=3Dshape>
    <p class=3DMsoNormal>multipart/mixed<o:p></o:p></p>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
    <p class=3DMsoNormal><span =
style=3D'font-size:20.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&#8230;<o:p></o:p></span></p>
    <p class=3DMsoNormal><span =
style=3D'font-size:8.0pt'><o:p>&nbsp;</o:p></span></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  </span><![endif]><![if !mso & !vml]>&nbsp;<![endif]><![if !vml]></td>
 </tr>
</table>

</span><![endif]><!--[if gte vml 1]><v:shape id=3D"_x0000_s1028" =
type=3D"#_x0000_t202"=20
 =
style=3D'position:absolute;margin-left:21pt;margin-top:31.6pt;width:348.4=
pt;
 height:28.1pt;z-index:251658240'>
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1028' />
</v:shape><![endif]--><![if !vml]><span =
style=3D'mso-ignore:vglayout;position:
absolute;z-index:251658240;margin-left:27px;margin-top:41px;width:471px;
height:44px'>

<table cellpadding=3D0 cellspacing=3D0>
 <tr>
  <td width=3D471 height=3D44 bgcolor=3Dwhite style=3D'border:.75pt =
solid black;
  vertical-align:top;background:white'><![endif]><![if !mso]><span
  style=3D'position:absolute;mso-ignore:vglayout;z-index:251658240'>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div v:shape=3D"_x0000_s1028" style=3D'padding:4.35pt 7.95pt 4.35pt =
7.95pt'
    class=3Dshape>
    <p class=3DMsoNormal>Human Readable text <span =
style=3D'font-size:8.0pt'>(e.g.,
    &#8220;This is a collection of OMA Spam Reports&#8221;) =
<o:p></o:p></span></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  </span><![endif]><![if !mso & !vml]>&nbsp;<![endif]><![if !vml]></td>
 </tr>
</table>

</span><![endif]><!--[if gte vml 1]><v:rect=20
 id=3D"_x0000_s1026" =
style=3D'width:432.7pt;height:257.65pt;mso-left-percent:-10001;
 mso-top-percent:-10001;mso-position-horizontal:absolute;
 mso-position-horizontal-relative:char;mso-position-vertical:absolute;
 =
mso-position-vertical-relative:line;mso-left-percent:-10001;mso-top-perce=
nt:-10001'>
 <v:textbox style=3D'mso-next-textbox:#_x0000_s1026'>
  <![if !mso]>
  <table cellpadding=3D0 cellspacing=3D0 width=3D"100%">
   <tr>
    <td><![endif]>
    <div>
    <p class=3DMsoNormal>Complex SpamRep Message (multipart/report,=20
    report-type=3Dmixed)<o:p></o:p></p>
    </div>
    <![if !mso]></td>
   </tr>
  </table>
  <![endif]></v:textbox>
 <w:wrap type=3D"none"/>
 <w:anchorlock/>
</v:rect><![endif]--><![if !vml]><img width=3D583 height=3D350
src=3D"cid:[email-masked]"
alt=3D"Text Box: Complex SpamRep Message (multipart/report, =
report-type=3Dmixed)"
v:shapes=3D"_x0000_s1026"><![endif]>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l2 =
level1 lfo2'><![if !supportLists]><span
style=3D'color:#1F497D'><span style=3D'mso-list:Ignore'>3.<span =
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'color:#1F497D'>&nbsp;An =
issue not
raised in Murry&#8217;s message is whether and how to promote spam =
reports that
are readable by both RFC5965 and SpamRep servers.&nbsp; One possibility =
is to
allow the second part of the multipart/report to be a =
multipart/alternative MIME
part.&nbsp; This multipart/alternative might contain two or more MIME =
parts,
including both OMA-defined </span>application/vnd.oma.spamrep+xml and
RFC5965-defined message/feedback-report MIME parts.&nbsp; To comply with =
the letter
(yet perhaps not the spirit) of RFC3462, an outer(most) MIME type would =
need to
be &#8216;multipart/report, report-type=3Dalternative&#8217;.&nbsp; What =
is the
group&#8217;s reaction to this?&nbsp; <span =
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Alex =
Bobotek<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On =
Behalf
Of </b>Murray S. Kucherawy<br>
<b>Sent:</b> Tuesday, September 21, 2010 10:53 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> multipart/report<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I&#8217;m doing some work with the OMA in the area =
of spam
reporting.&nbsp; They have developed an XML message format for reporting =
spam
from a mobile handset.&nbsp; Because SMS and MMS (and even IM) have =
different
structure than email, they went with something more extensible than what =
we
currently do with DSNs.&nbsp; I&#8217;m helping that group try to =
converge with
what we do in the email world, especially with what the MARF working =
group is
producing (e.g., ARF, specified by recently-published RFC5965).&nbsp; =
The first
thing is to register the MIME type they&#8217;ve created, and so =
I&#8217;ve
crafted a template for that.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The next thing we&#8217;d like to achieve is to be =
able to
specify multiple spam reports in a single message, regardless of =
transport
(they currently use HTTP POST, but there&#8217;s no reason SMTP =
couldn&#8217;t
be used).&nbsp; The most obvious thing to do would be to use a =
multipart/mixed
MIME message, and then include their MIME type in each of =
&#8220;n&#8221;
parts.&nbsp; However, this is different than what was done with ARF, =
which used
multipart/report.&nbsp; The advantage to using multipart/report, which
stipulates that it must be the outermost MIME type, is that you know =
right away
that you&#8217;re processing a report rather than having to parse part =
way into
the MIME tree to figure that out.&nbsp; (According to Tony Hansen, =
that&#8217;s
why this rule was put in place.)&nbsp; But although multipart/report is =
the
most obvious construct for doing this, it doesn&#8217;t lend itself to
multi-report messages.&nbsp; So to get these to converge, we have to be =
a
little creative or be very creative (in the &#8220;create a lot of
documents&#8221; sense).<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We could do a message/digest, each sub-part of =
which is
message/rfc822 and the MIME type within that is multipart/report.&nbsp; =
One
could argue that this approach conforms to the multipart/report rules by =
having
that be the outermost MIME part of each constituent message in the =
aggregate
message, but that might be hard to defend given the spirit of that =
rule.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>There&#8217;s also a stipulation that the MIME =
subtype of
the second part in a multipart/report message must be equal to the =
report-type
of the outermost part, with no other constraints.&nbsp; Thus to keep
multipart/report at the outermost MIME but allow multi-message reports, =
we
could comply by using &#8220;multipart/report; =
report-type=3Dmixed&#8221; as the
outermost MIME type and then use &#8220;multipart/mixed&#8221; =
inside.&nbsp;
But this also sure feels hack-ish.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>So what would be more palatable to this =
community?&nbsp;
Could multipart/report be updated to accommodate this use case?&nbsp; =
Should we
register multipart/multi-report that relaxes some of the existing =
restrictions
without changing the existing media type?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Feedback/guidance is welcome.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>-MSK<o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_002_01CB5A2D.C26AF0A6--

------_=_NextPart_001_01CB5A2D.C26AF0A6
Content-Type: image/png;
	name="image009.png"
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>
Content-Description: image009.png
Content-Location: image009.png

------_=_NextPart_001_01CB5A2D.C26AF0A6
Content-Type: image/png;
	name="image010.png"
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>
Content-Description: image010.png
Content-Location: image010.png

------_=_NextPart_001_01CB5A2D.C26AF0A6
Content-Type: image/png;
	name="image011.png"
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>
Content-Description: image011.png
Content-Location: image011.png

------_=_NextPart_001_01CB5A2D.C26AF0A6
Content-Type: image/png;
	name="image012.png"
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>
Content-Description: image012.png
Content-Location: image012.png

AAAAAElFTkSuQmCC

------_=_NextPart_001_01CB5A2D.C26AF0A6
Content-Type: image/png;
	name="image013.png"
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>
Content-Description: image013.png
Content-Location: image013.png

------_=_NextPart_001_01CB5A2D.C26AF0A6
Content-Type: image/png;
	name="image014.png"
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>
Content-Description: image014.png
Content-Location: image014.png

------_=_NextPart_001_01CB5A2D.C26AF0A6
Content-Type: image/png;
	name="image015.png"
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>
Content-Description: image015.png
Content-Location: image015.png

------_=_NextPart_001_01CB5A2D.C26AF0A6
Content-Type: image/png;
	name="image016.png"
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>
Content-Description: image016.png
Content-Location: image016.png

------_=_NextPart_001_01CB5A2D.C26AF0A6--

From: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 21 Sep 2010 23:34:02 -0700 (PDT)
Subject: Re: multipart/report
To: "Murray S. Kucherawy" <[email-masked]>
Sender: [email-masked]

> I'm doing some work with the OMA in the area of spam reporting.  They have
> developed an XML message format for reporting spam from a mobile handset. 
> Because SMS and MMS (and even IM) have different structure than email, they
> went with something more extensible than what we currently do with DSNs.  I'm
> helping that group try to converge with what we do in the email world,
> especially with what the MARF working group is producing (e.g., ARF, specified
> by recently-published RFC5965).  The first thing is to register the MIME type
> they've created, and so I've crafted a template for that.

> The next thing we'd like to achieve is to be able to specify multiple spam
> reports in a single message, regardless of transport (they currently use HTTP
> POST, but there's no reason SMTP couldn't be used).  The most obvious thing to
> do would be to use a multipart/mixed MIME message, and then include their MIME
> type in each of "n" parts.  However, this is different than what was done with
> ARF, which used multipart/report.  The advantage to using multipart/report,
> which stipulates that it must be the outermost MIME type, is that you know
> right away that you're processing a report rather than having to parse part way
> into the MIME tree to figure that out.

IMO this has always been a silly requirement because it imposes a condition
that in practice cannot possible be met. And as usual, it all boils down to
people having an idealized view of how email works and failing to take real
world conditions into account. (I did point this out at the time this was
written, but got no support and I was also the NOTARY chair, and as such my
main concern was getting the thing done, not worrying about this sort of
detail.)

While it is true that you can impose such a rule on agents sending out such
parts, you cannot possibly hope to have such a rule respected by intermediate
processors. So when, say, someone forwards a report they got to someone else
for analysis - guess what? The multipart/report ends up inside a message/rfc822
or whatever. Ditto for inclusion in multipart/digest objects.

As for the ease of processing business, you'd think that by now we'd have
learned not to do this sort of thing. The painful reality is that when it comes
to encouraging user agents to go the extra mile and do stuff like handle
reports properly, or handle alternatives properly, etc. etc., concessions to
simplicity have not helped in the slightest. User agent authors implement the
stuff they think is useful - even when it is difficult - and ignore the rest.
And for whatever reason support for processing multipart/report has not been
seen as useful, so there are very few implementations that do it. (I know of
only two, one of which I wrote and for which, BTW, the outermost part
rule didn't make things any simpler.)

> (According to Tony Hansen, that's why this rule was put in place.)

RFC 3462 specifically states that this is the case.

> But although multipart/report is the most obvious construct for doing this,
> it doesn't lend itself to multi-report messages. So to get these to converge,
> we have to be a little creative or be very creative (in the "create a lot of
> documents" sense).

> We could do a message/digest, each sub-part of which is message/rfc822 and
> the MIME type within that is multipart/report.  One could argue that this
> approach conforms to the multipart/report rules by having that be the outermost
> MIME part of each constituent message in the aggregate message, but that might
> be hard to defend given the spirit of that rule.

Won't fly. Again, RFC 3462 is quite specific about the purpose of the rule is
so reports can be detected by looking at the RFC 822 header. Such a purpose is
totally defeated by embedding the message inside additional MIME content.

No, if you want to get rid of this rule, you need to bite the bullet and
revise/update RFC 3462 to get rid of it. And I don't think this is that big of
a deal - this is very small beer compared to changing the no nested parts rule
in MIME, which EAI does.

> There's also a stipulation that the MIME subtype of the second part in a
> multipart/report message must be equal to the report-type of the outermost
> part, with no other constraints.  Thus to keep multipart/report at the
> outermost MIME but allow multi-message reports, we could comply by using
> "multipart/report; report-type=mixed" as the outermost MIME type and then use
> "multipart/mixed" inside.  But this also sure feels hack-ish.

I don't believe that works either, because in addition to the restriction you
note RFC 3462 requires that the content of a multipart/report be a specific
structure containing two or three parts with specific semantics. In fact I'd
say that relaxing this rule is likely to cause far more interop problems - for
example, my report processing code can handle reports not at the outermost
level, but would refuse to process what you're proposing here.

> So what would be more palatable to this community?  Could multipart/report be
> updated to accommodate this use case?  Should we register
> multipart/multi-report that relaxes some of the existing restrictions without
> changing the existing media type?

This would be the simplest thing to do that doesn't change anything else, but
I would prefer to get rid of the silly rule in RFC 3462.

				Ned

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 21 Sep 2010 22:52:59 -0700
Subject: multipart/report
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_BB012BD379D7B046ABE1472D8093C61C02AFC3C1FBEXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I'm doing some work with the OMA in the area of spam reporting.  They have =
developed an XML message format for reporting spam from a mobile handset.  =
Because SMS and MMS (and even IM) have different structure than email, they=
 went with something more extensible than what we currently do with DSNs.  =
I'm helping that group try to converge with what we do in the email world, =
especially with what the MARF working group is producing (e.g., ARF, specif=
ied by recently-published RFC5965).  The first thing is to register the MIM=
E type they've created, and so I've crafted a template for that.

The next thing we'd like to achieve is to be able to specify multiple spam =
reports in a single message, regardless of transport (they currently use HT=
TP POST, but there's no reason SMTP couldn't be used).  The most obvious th=
ing to do would be to use a multipart/mixed MIME message, and then include =
their MIME type in each of "n" parts.  However, this is different than what=
 was done with ARF, which used multipart/report.  The advantage to using mu=
ltipart/report, which stipulates that it must be the outermost MIME type, i=
s that you know right away that you're processing a report rather than havi=
ng to parse part way into the MIME tree to figure that out.  (According to =
Tony Hansen, that's why this rule was put in place.)  But although multipar=
t/report is the most obvious construct for doing this, it doesn't lend itse=
lf to multi-report messages.  So to get these to converge, we have to be a =
little creative or be very creative (in the "create a lot of documents" sen=
se).

We could do a message/digest, each sub-part of which is message/rfc822 and =
the MIME type within that is multipart/report.  One could argue that this a=
pproach conforms to the multipart/report rules by having that be the outerm=
ost MIME part of each constituent message in the aggregate message, but tha=
t might be hard to defend given the spirit of that rule.

There's also a stipulation that the MIME subtype of the second part in a mu=
ltipart/report message must be equal to the report-type of the outermost pa=
rt, with no other constraints.  Thus to keep multipart/report at the outerm=
ost MIME but allow multi-message reports, we could comply by using "multipa=
rt/report; report-type=3Dmixed" as the outermost MIME type and then use "mu=
ltipart/mixed" inside.  But this also sure feels hack-ish.

So what would be more palatable to this community?  Could multipart/report =
be updated to accommodate this use case?  Should we register multipart/mult=
i-report that relaxes some of the existing restrictions without changing th=
e existing media type?

Feedback/guidance is welcome.

-MSK

--_000_BB012BD379D7B046ABE1472D8093C61C02AFC3C1FBEXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>I&#8217;m doing some work with the OMA in the area of =
spam
reporting.&nbsp; They have developed an XML message format for reporting sp=
am
from a mobile handset.&nbsp; Because SMS and MMS (and even IM) have differe=
nt
structure than email, they went with something more extensible than what we
currently do with DSNs.&nbsp; I&#8217;m helping that group try to converge =
with
what we do in the email world, especially with what the MARF working group =
is
producing (e.g., ARF, specified by recently-published RFC5965).&nbsp; The f=
irst
thing is to register the MIME type they&#8217;ve created, and so I&#8217;ve
crafted a template for that.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The next thing we&#8217;d like to achieve is to be abl=
e to
specify multiple spam reports in a single message, regardless of transport
(they currently use HTTP POST, but there&#8217;s no reason SMTP couldn&#821=
7;t
be used).&nbsp; The most obvious thing to do would be to use a multipart/mi=
xed
MIME message, and then include their MIME type in each of &#8220;n&#8221; p=
arts.&nbsp;
However, this is different than what was done with ARF, which used
multipart/report.&nbsp; The advantage to using multipart/report, which stip=
ulates
that it must be the outermost MIME type, is that you know right away that y=
ou&#8217;re
processing a report rather than having to parse part way into the MIME tree=
 to
figure that out.&nbsp; (According to Tony Hansen, that&#8217;s why this rul=
e
was put in place.)&nbsp; But although multipart/report is the most obvious
construct for doing this, it doesn&#8217;t lend itself to multi-report
messages.&nbsp; So to get these to converge, we have to be a little creativ=
e or
be very creative (in the &#8220;create a lot of documents&#8221; sense).<o:=
p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>We could do a message/digest, each sub-part of which i=
s
message/rfc822 and the MIME type within that is multipart/report.&nbsp; One
could argue that this approach conforms to the multipart/report rules by ha=
ving
that be the outermost MIME part of each constituent message in the aggregat=
e
message, but that might be hard to defend given the spirit of that rule.<o:=
p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>There&#8217;s also a stipulation that the MIME subtype=
 of
the second part in a multipart/report message must be equal to the report-t=
ype
of the outermost part, with no other constraints.&nbsp; Thus to keep
multipart/report at the outermost MIME but allow multi-message reports, we
could comply by using &#8220;multipart/report; report-type=3Dmixed&#8221; a=
s the
outermost MIME type and then use &#8220;multipart/mixed&#8221; inside.&nbsp=
;
But this also sure feels hack-ish.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>So what would be more palatable to this community?&nbs=
p; Could
multipart/report be updated to accommodate this use case?&nbsp; Should we
register multipart/multi-report that relaxes some of the existing restricti=
ons
without changing the existing media type?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Feedback/guidance is welcome.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>-MSK<o:p></o:p></p>

</div>

</body>

</html>

--_000_BB012BD379D7B046ABE1472D8093C61C02AFC3C1FBEXCHC2corpclo_--

From: [email-masked]
Cc: [email-masked]
Date: Mon, 20 Sep 2010 12:44:45 -0700 (PDT)
Subject: Re: Length Limit for display-name
To: Stephan Wehner <[email-masked]>
Sender: [email-masked]

> On Sat, Sep 18, 2010 at 8:51 AM, Ned Freed <[email-masked]> wrote:
> >
> >> Section 3.4. Address Specification of RFC2822 specifies
> >
> >> name-addr       =       [display-name] angle-addr
> >
> >> What are the length limits on the display-name field? I take it a long
> >> display-name
> >> value would simply be folded as described under 2.2.3. Long Header Fields
> >
> > AFAICT the relevant specifications impose no limits on the size of the
> > display-name. What implementations actually do is another matter, of course. I
> > believe I've encountered limits as low as 64 octets. I certainly wouldn't
> > recommend putting in stuff longer than 100 or so octets and  expect it to pass
> > through everything intact.
> >

> Thanks a lot for your replies, Ned and Hector!

> Indeed, I tracked down the display-name rule in

>  display-name    =       phrase
>  phrase          =       1*word / obs-phrase

> where 1*word implies no length limit (RFC 2234)

> When I asked about clients, I meant clients that connect to the mail
> server to send an email message, not end-user
> or display clients.

THat excludes the thnings that impose by far the shortest limits on these
fields.

> For example, qmail-remote, and gateways when
> passing a message to another server. Here
> I thought the To: header being within the message they would not touch
> it, or parse it and just pass it on, so
> that "trace fields are prepended to the message" (A.4 in the Appendix )

Dream on. That's not how things work in th real world. Lots of intermediaries
perform all sorts of processing of header fields. The legality or illegality of
doing this is mostly irrelevant, since you have to deal with what's out there,
not what the standards-writers hoped would be out there, but even then,
specific header modifications are specifically condoned by vaiorus standards,
e.g., MIME downgrading.

In the specific case of To: fields, an obvious one is for submission servers to
rewrite addresses to eliminae short form names and other local crap.

> Would such clients leave a display-name unchanged?

The answer is no, you cannot count on it.

> I would think only
> the total email length limit would come
> into play, which is usually pretty large (measured in MB)

Again, you're dreaming if you think this is true.

				Ned

Date: Mon, 20 Sep 2010 10:56:15 -0700
Subject: Re: Length Limit for display-name
From: Stephan Wehner <[email-masked]>
To: [email-masked]
Sender: [email-masked]

On Sat, Sep 18, 2010 at 8:51 AM, Ned Freed <[email-masked]> wrote:
>
>> Section 3.4. Address Specification of RFC2822 specifies
>
>> name-addr       =       [display-name] angle-addr
>
>> What are the length limits on the display-name field? I take it a long
>> display-name
>> value would simply be folded as described under 2.2.3. Long Header Fields
>
> AFAICT the relevant specifications impose no limits on the size of the
> display-name. What implementations actually do is another matter, of course. I
> believe I've encountered limits as low as 64 octets. I certainly wouldn't
> recommend putting in stuff longer than 100 or so octets and  expect it to pass
> through everything intact.
>

Thanks a lot for your replies, Ned and Hector!

Indeed, I tracked down the display-name rule in

 display-name    =       phrase
 phrase          =       1*word / obs-phrase

where 1*word implies no length limit (RFC 2234)

When I asked about clients, I meant clients that connect to the mail
server to send an email message, not end-user
or display clients. For example, qmail-remote, and gateways when
passing a message to another server. Here
I thought the To: header being within the message they would not touch
it, or parse it and just pass it on, so
that "trace fields are prepended to the message" (A.4 in the Appendix )

Would such clients leave a display-name unchanged? I would think only
the total email length limit would come
into play, which is usually pretty large (measured in MB)

Stephan

>> Are there practical length limits with respect to current SMTP clients
>> and servers?
>
> Given that there are clients which don't show users the display-name at all, I
> suppose the practical length limit could be seen as zero. Those clients that do
> display this information often allocated a fairly narrow field to it, so I
> wouldn't count on anything more than 30-40 characters (not octets) being
> visible.
>
>                                Ned
>

-- 
Stephan Wehner

-> http://stephan.sugarmotor.org (blog and homepage)
-> http://loggingit.com
-> http://www.thrackle.org
-> http://www.buckmaster.ca
-> http://www.trafficlife.com
-> http://stephansmap.org -- http://blog.stephansmap.org
-> http://twitter.com/stephanwehner / @stephanwehner

From: [email-masked]
Cc: [email-masked]
Date: Sat, 18 Sep 2010 08:51:30 -0700 (PDT)
Subject: Re: Length Limit for display-name
To: Stephan Wehner <[email-masked]>
Sender: [email-masked]

> Section 3.4. Address Specification of RFC2822 specifies

> name-addr       =       [display-name] angle-addr

> What are the length limits on the display-name field? I take it a long
> display-name
> value would simply be folded as described under 2.2.3. Long Header Fields

AFAICT the relevant specifications impose no limits on the size of the
display-name. What implementations actually do is another matter, of course. I
believe I've encountered limits as low as 64 octets. I certainly wouldn't
recommend putting in stuff longer than 100 or so octets and  expect it to pass
through everything intact.

> Are there practical length limits with respect to current SMTP clients
> and servers?

Given that there are clients which don't show users the display-name at all, I
suppose the practical length limit could be seen as zero. Those clients that do
display this information often allocated a fairly narrow field to it, so I
wouldn't count on anything more than 30-40 characters (not octets) being
visible.

				Ned

Date: Sat, 18 Sep 2010 01:50:56 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Stephan Wehner <[email-masked]>
CC: [email-masked]
Subject: Re: Length Limit for display-name
Sender: [email-masked]

Stephan Wehner wrote:
> Section 3.4. Address Specification of RFC2822 specifies
> 
> name-addr       =       [display-name] angle-addr
> 
> What are the length limits on the display-name field? I take it a long
> display-name
> value would simply be folded as described under 2.2.3. Long Header Fields
> 
> Are there practical length limits with respect to current SMTP clients
> and servers?

Stephen,

The display name is not used in SMTP. Only the actual address is used 
at the SMTP level.

However, in the message 5322 headers itself, the MUA, mail readers, 
display systems, etc, will use the display name extracted from 
5322.From and 5322.To

The only practical limit I can think of is:

old days: 80 character limit or 72 to limit single line console display:

      12345......................80
      From: display-name

For the new days with gui, I guess that would be dependent on the GUI 
mail reader and how it is displayed and also limits it as well. We are 
still constrained with some practical limit for display a pretty 
message header frame even with GUI. GUI affords you doubling up one or 
more fields on a single row.

      From:                             Date:
      To:
      Subject

But some software will truncate and triple dot it so it fits.

     From: This User has a long Displ....  Date: xx/xx/xxxx xx:xxpm

For our backend software, we still display names to 72 characters 
since it carried on from the old days and also, before email, most of 
the time a display name was the login name, and 72 characters was 
sufficient for any person's name. :)

Also, think the growing Mobil market.  There for sure you have design 
rendering limits, but that should relaxed with the growing tablet 
market with larger screens.

Hope this helps.

-- 
Hector, Engineering & Technical Support
Santronics Software, Inc.
http://www.santronics.com (sales)
http://www.winserver.com (support)
http://www.winserver.com/AupInfo (Online AUP Help)
Office: 305-248-3204

Date: Fri, 17 Sep 2010 21:44:06 -0700
Subject: Length Limit for display-name
From: Stephan Wehner <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Section 3.4. Address Specification of RFC2822 specifies

name-addr       =       [display-name] angle-addr

What are the length limits on the display-name field? I take it a long
display-name
value would simply be folded as described under 2.2.3. Long Header Fields

Are there practical length limits with respect to current SMTP clients
and servers?

Stephan

Date: Thu, 16 Sep 2010 19:55:07 -0400
From: Tony Hansen <[email-masked]>
To: Yet Another Mail Working Group <[email-masked]>, ietf-822 <[email-masked]>, SMTP Interest Group <[email-masked]>, [email-masked], [email-masked], IETF DKIM WG <[email-masked]>
Subject: Fwd: NomCom 2010-2011: Call for More Nominations
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060003020505000404050703
Content-Type: multipart/alternative;
 boundary="------------080408080408030406050702"

--------------080408080408030406050702
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

fyi. Please nominate someone today.

     Tony Hansen

PS. Yeah, I'm on the nomcom this year.

-------- Original Message --------
Subject: 	NomCom 2010-2011: Call for More Nominations
Date: 	Thu, 16 Sep 2010 16:26:02 -0700 (PDT)
From: 	NomCom Chair <[email-masked]>
To: 	IETF Announcement list <[email-masked]>

Hi Folks,

Nominations have slowed down dramatically, so this update is to enlist
the community in an effort to pick up the pace.

We are very far behind in nominations for all the open positions but in
particular we need nominations for the IESG and IAOC open positions.
There have been no nominations received (other than for the incumbents)
in INT, RAI, and RTG, and only 1 for OPS.  Likewise, in IAOC there have
been no nominations submitted other than the incumbent.

The acceptance rates of those nominated has also been very slow. In
order to initiate the open list of willing nominees we are in need of a
reasonable number of acceptances, and due to the low number of nominees
and acceptances have delayed the start date for publishing the first
open list to September 20.  So if you have been nominated and are
willing to serve, but have not yet confirmed this by email back to the
NomCom, please do so as soon as possible.

We need Community input and participation! We cannot properly execute
the task of selecting the best candidates for these positions with so
few nominations and acceptances. So, please consider making
nominations for the open positions, in particular those for which we
have so few nominations =C2=96 it takes just a few minutes of your time.
Right now, we just need the names/email addresses.

Why do we need more nominations?  Well, even if you think a willing
incumbent is doing a very good job and should be returned, his or her
ability to serve again might be impacted by unforeseen circumstances
between now and March. NomCom needs to consider multiple nominees to be
prepared in the event one or more candidates is unable to serve come next=

March and to ensure we have chosen the best candidate.

There are several ways you can help the IETF Nominating Committee.

- You may nominate yourself.
- You can nominate someone you know whom you think would do a good job.

Do not worry about whether they might already be nominated. We would
much prefer to receive the same nomination several times rather than
miss a good person we should consider.

How to submit Nominations:
--------------------------
The list of positions we need to fill, and the provided Job
Descriptions, and forms for nominations, can be found in the call for
nominations at: https://datatracker.ietf.org/ann/nomcom/2468/

You may enter a nomination by going to the following URL
https://wiki.tools.ietf.org/group/nomcom/10/nominate

You may also nominate someone by sending an email to [email-masked]
and giving us their name, email address and the open position you are
nominating them for. We will take care of the rest.

If you are asked for a user name and password, use an existing ietf login=

and password. If you need a login and password, request one from the tool=
s
page at the following URL http://trac.tools.ietf.org/newlogin

Open List:
----------
As you already know, NomCom 2010-2011 will follow the policy for "Open
Disclosure of Willing Nominees" described in RFC 5680.

Feedback Collection:
--------------------
Once the open list is available, the entire community will be invited
to provide feedback. I will send a further announcement requesting
feedback on the nominees, describing how to submit feedback, and how to
view the open list of nominees.

Thank you,

Thomas Walsh
Chair, NomCom 2010-2011
[email-masked]
[email-masked]

--------------080408080408030406050702
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8">=

</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
fyi. Please nominate someone today.<br>
<br>
=C2=A0=C2=A0=C2=A0 Tony Hansen<br>
<br>
PS. Yeah, I'm on the nomcom this year.<br>
<br>
-------- Original Message --------
<table class=3D"moz-email-headers-table" border=3D"0" cellpadding=3D"0"
 cellspacing=3D"0">
  <tbody>
    <tr>
      <th valign=3D"BASELINE" align=3D"RIGHT" nowrap=3D"nowrap">Subject: =
</th>
      <td>NomCom 2010-2011: Call for More Nominations</td>
    </tr>
    <tr>
      <th valign=3D"BASELINE" align=3D"RIGHT" nowrap=3D"nowrap">Date: </t=
h>
      <td>Thu, 16 Sep 2010 16:26:02 -0700 (PDT)</td>
    </tr>
    <tr>
      <th valign=3D"BASELINE" align=3D"RIGHT" nowrap=3D"nowrap">From: </t=
h>
      <td>NomCom Chair <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:=
[email-masked]">&lt;[email-masked]&gt;</a></td>
    </tr>
    <tr>
      <th valign=3D"BASELINE" align=3D"RIGHT" nowrap=3D"nowrap">To: </th>=

      <td>IETF Announcement list <a class=3D"moz-txt-link-rfc2396E" href=3D=
"mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>
Hi Folks,

Nominations have slowed down dramatically, so this update is to enlist=20
the community in an effort to pick up the pace.=20

We are very far behind in nominations for all the open positions but in=20
particular we need nominations for the IESG and IAOC open positions.=20
There have been no nominations received (other than for the incumbents)=20
in INT, RAI, and RTG, and only 1 for OPS.  Likewise, in IAOC there have=20
been no nominations submitted other than the incumbent.

The acceptance rates of those nominated has also been very slow. In=20
order to initiate the open list of willing nominees we are in need of a=20
reasonable number of acceptances, and due to the low number of nominees=20
and acceptances have delayed the start date for publishing the first=20
open list to September 20.  So if you have been nominated and are=20
willing to serve, but have not yet confirmed this by email back to the=20
NomCom, please do so as soon as possible.

We need Community input and participation! We cannot properly execute=20
the task of selecting the best candidates for these positions with so=20
few nominations and acceptances. So, please consider making=20
nominations for the open positions, in particular those for which we=20
have so few nominations =C2=96 it takes just a few minutes of your time. =

Right now, we just need the names/email addresses.

Why do we need more nominations?  Well, even if you think a willing
incumbent is doing a very good job and should be returned, his or her
ability to serve again might be impacted by unforeseen circumstances
between now and March. NomCom needs to consider multiple nominees to be
prepared in the event one or more candidates is unable to serve come next=

March and to ensure we have chosen the best candidate.=20

There are several ways you can help the IETF Nominating Committee.

- You may nominate yourself.
- You can nominate someone you know whom you think would do a good job.

Do not worry about whether they might already be nominated. We would=20
much prefer to receive the same nomination several times rather than=20
miss a good person we should consider.

How to submit Nominations:
--------------------------
The list of positions we need to fill, and the provided Job=20
Descriptions, and forms for nominations, can be found in the call for=20
nominations at: <a class=3D"moz-txt-link-freetext" href=3D"https://datatr=
acker.ietf.org/ann/nomcom/2468/">https://datatracker.ietf.org/ann/nomcom/=
2468/</a>=20

You may enter a nomination by going to the following URL=20
<a class=3D"moz-txt-link-freetext" href=3D"https://wiki.tools.ietf.org/gr=
oup/nomcom/10/nominate">https://wiki.tools.ietf.org/group/nomcom/10/nomin=
ate</a>

You may also nominate someone by sending an email to <a class=3D"moz-txt-=
link-abbreviated" href=3D"mailto:[email-masked]">[email-masked]</a>=
=20
and giving us their name, email address and the open position you are=20
nominating them for. We will take care of the rest.=20

If you are asked for a user name and password, use an existing ietf login=

and password. If you need a login and password, request one from the tool=
s
page at the following URL <a class=3D"moz-txt-link-freetext" href=3D"http=
://trac.tools.ietf.org/newlogin">http://trac.tools.ietf.org/newlogin</a>

Open List:
----------
As you already know, NomCom 2010-2011 will follow the policy for "Open=20
Disclosure of Willing Nominees" described in RFC 5680.

Feedback Collection:
--------------------
Once the open list is available, the entire community will be invited=20
to provide feedback. I will send a further announcement requesting=20
feedback on the nominees, describing how to submit feedback, and how to=20
view the open list of nominees.=20

Thank you,

Thomas Walsh
Chair, NomCom 2010-2011
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]=
g">[email-masked]</a>
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email-masked]">=
[email-masked]</a>

</pre>
</body>
</html>

--------------080408080408030406050702--

--------------060003020505000404050703
Content-Type: text/plain;
 name="Attached Message Part"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="Attached Message Part"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYt
QW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCg0K
--------------060003020505000404050703--