Subject: Re: New Version Notification for draft-kucherawy-mta-malformed-00
From: Douglas Otis <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 30 Nov 2010 15:06:16 -0800
List-Id: <ietf-822.imc.org>

On 11/30/10 11:55 AM, Murray S. Kucherawy wrote:
>> On Tuesday, November 30, 2010 11:11 AM, Douglas Otis wrote:
>>
>> DKIM should be repaired to ensure deceptive malformed header fields do
>> not verify as having valid DKIM signatures to prevent the exploits, such
>> as having multiple singleton header fields invalidate signatures.  DKIM
>> should have included checks necessary to disqualify messages likely
>> crafted by malefactors.  These checks may need to grow over time.  The
>> impact of adding checks to DKIM's verification process will not justify
>> new mandates for making message repairs or rejections by SMTP or MUAs.
>> [...]
> I think this is completely off-topic for the work being discussed here, Doug.  The discussion has to do with what MTAs, and perhaps MUAs if that's appropriate, should do with common malformations independent of things like DKIM.
Murray,

Any deviations from standards normally used by malefactors to deceive 
recipients should be rejected!  Unfortunately this draft suggests:

1) Ignore
2) Repair
3) Reject

Ignoring and repairing remains problematic.  IMHO, repair will never be 
required for SMTP or MUA level compliance.  Without format compliance 
being part of trust related verifications, systems claiming enhanced 
levels of trust will not be trustworthy.  Since SMTP does not mandate 
non-compliance be rejected, the only reasonable strategy is to ensure 
mechanisms such as DKIM makes no exploitable assertions when confronting 
malformed messages.

I see this draft as a dubious attempt to suggest SMTP or MUAs should be 
expected to defend enhanced levels of trust based upon mechanisms such 
as DKIM.  This is inherently wrong, as this will result in indeterminate 
message status and untrustworthy systems.

-Doug

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 30 Nov 2010 11:55:01 -0800
Subject: RE: New Version Notification for draft-kucherawy-mta-malformed-00
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Tuesday, November 30, 2010 11:11 AM
> To: Martijn Grooten
> Cc: [email-masked]
> Subject: Re: New Version Notification for draft-kucherawy-mta-malformed-00
> 
> DKIM should be repaired to ensure deceptive malformed header fields do
> not verify as having valid DKIM signatures to prevent the exploits, such
> as having multiple singleton header fields invalidate signatures.  DKIM
> should have included checks necessary to disqualify messages likely
> crafted by malefactors.  These checks may need to grow over time.  The
> impact of adding checks to DKIM's verification process will not justify
> new mandates for making message repairs or rejections by SMTP or MUAs.
> [...]

I think this is completely off-topic for the work being discussed here, Doug.  The discussion has to do with what MTAs, and perhaps MUAs if that's appropriate, should do with common malformations independent of things like DKIM.

Date: Tue, 30 Nov 2010 11:10:53 -0800
From: Douglas Otis <[email-masked]>
To: Martijn Grooten <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: New Version Notification for draft-kucherawy-mta-malformed-00
Sender: [email-masked]

On 11/30/10 9:26 AM, Martijn Grooten wrote:
> (Reposted to the list as per Murray's suggestion.)
>> Please do feel free to review what's there and comment, and also submit
>> suggestions for other cases that might be of interest to record for
>> future implementers.
> A couple of things:
>
> - an example of non-valid header I have seen "in the wild" (in legitimate email) is a non-encoded non-ASCII header (something Russian, I believe). I'm not quite sure how this can be abused though, but it's probably worth mentioning. I know at least one spam filter that does (or did; I think they changed it) block such messages outright as non-valid email.
>
> - it's not mentioned in the document, but in the related discussion on the DKIM-list, "actions" to be taken by MUAs were implicitly or explicitly mentioned. I just wanted to say I don't think a MUA _should_ do anything but, perhaps, render a message in a specific way. Many people have filters built in their MUAs, but many others haven't.
>
> - it would be great if the document could somehow say it is okay for a filter to discard/deny/drop certain kinds of messages. (Multiple From-headers, for example.) I know many spam filters don't dare to do this, as there is always the risk of false positives and the need to be liberal. A document like this could give them some kind of official 'permission' to block these messages which would, hopefully, encourage both legitimate senders and spammers to not send them.
Disagree.

DKIM should be repaired to ensure deceptive malformed header fields do 
not verify as having valid DKIM signatures to prevent the exploits, such 
as having multiple singleton header fields invalidate signatures.  DKIM 
should have included checks necessary to disqualify messages likely 
crafted by malefactors.  These checks may need to grow over time.  The 
impact of adding checks to DKIM's verification process will not justify 
new mandates for making message repairs or rejections by SMTP or MUAs.

DKIM uniquely attempts to leverage use of header fields, unlike S/MIME 
or PGP.  As such, ensuring against deceptive malformed header fields 
from receiving DKIM validation is reasonable.  This is the value 
proposition of DKIM after all.  Expecting rejection or repair of such 
header fields is likely to prove counter productive at providing 
compatible DKIM validations.

-Doug

From: Martijn Grooten <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 30 Nov 2010 17:26:11 +0000
Subject: RE: New Version Notification for draft-kucherawy-mta-malformed-00 
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Sender: [email-masked]

(Reposted to the list as per Murray's suggestion.)

> Please do feel free to review what's there and comment, and also submit
> suggestions for other cases that might be of interest to record for
> future implementers.

A couple of things:

- an example of non-valid header I have seen "in the wild" (in legitimate email) is a non-encoded non-ASCII header (something Russian, I believe). I'm not quite sure how this can be abused though, but it's probably worth mentioning. I know at least one spam filter that does (or did; I think they changed it) block such messages outright as non-valid email.

- it's not mentioned in the document, but in the related discussion on the DKIM-list, "actions" to be taken by MUAs were implicitly or explicitly mentioned. I just wanted to say I don't think a MUA _should_ do anything but, perhaps, render a message in a specific way. Many people have filters built in their MUAs, but many others haven't.

- it would be great if the document could somehow say it is okay for a filter to discard/deny/drop certain kinds of messages. (Multiple From-headers, for example.) I know many spam filters don't dare to do this, as there is always the risk of false positives and the need to be liberal. A document like this could give them some kind of official 'permission' to block these messages which would, hopefully, encourage both legitimate senders and spammers to not send them.

Martijn.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

From: [email-masked]
Cc: Ned Freed <[email-masked]>, "Murray S. Kucherawy" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 09 Nov 2010 13:16:56 -0800 (PST)
Subject: Re: New Version Notification for draft-kucherawy-rfc3462bis-00
To: Keith Moore <[email-masked]>
Sender: [email-masked]

> On Nov 9, 2010, at 12:12 PM, Ned Freed wrote:

> >> FWIW, I'm strongly opposed to such a change, as it breaks backward
> >> compatibility.
> >
> > If this really is a serious interoperability issue (and I doubt very much it
> > is) then perhaps the thing to do is place the restriction in the specific
> > instances of multipart/report defined thus far. It's unnecessary to restrict
> > all future use of multipart/report. It's also pointless, since all it will do
> > is result in the definition of another report container without the
> > restriction, which is messy and ugly.

> I probably agree with that.

> > Indeed, every single one of these restrictions we thought would be helpful for
> > MIME implementors (e.g., encoding restrictions on message) has in hindsight
> > turned out to be both unhelpful and a bad idea.

> I don't know how to evaluate that statement.  I am certainly aware of
> implementations of MIME that use statically allocated buffers for decoding
> base64, for instance. Though it's certainly possible to write a decoder that
> doesn't work that way, this is easier in some languages than others.  We
> didn't specify MIME that way specifically because we didn't want to make
> implementation overly difficult for those using languages without automatic
> garbage collection; nor did we want to invite subtle bugs resulting from naive
> implementation.

Given the EAI experiment, it now appears that this isn't as difficult for
people to get right as we thought.

> Though not allowing nested encodings has been "unhelpful" in
> some ways, on balance I don't know how to say whether in hindsight it's been a
> bad idea.

Given the restrictions it places on security enclosures, I have a hard time
seeing the effect as other than bad.

> But we made the decision for valid reasons, and I haven't seen anything so
> "unhelpful" as to convince me that we were totally off base there.

> > Oh, and I'd buy that this is a real interop issue if you can name some MUA
> > implemenations which when forwarduing using message/rfc822 encapsulation check
> > to see if the message being forwarded contains a multipart/report and do
> > something to correct that "invalid" nesting. (Exactly what it should do is a
> > little unclear.)

> I'm always dubious of arguments of the form "if you can't prove that this
> breaks something that's working now, assume that it doesn't break anything". 

That's not the argument. The argument is that if there was something out there
that depended on reports appearing at the top level to display them properly,
agents that generate reports not at the top level would have come under
pressure to correct their behavior. But despite the HUGE population of such
agents - pretty much every MUA of any sophistication that's been written can
and does generate nested reports because it doesn't check the subtype when it
forwards a multipart message - nobody seems to care.

Perhaps this is more a function of there not being any special support for
processing reports out there than anything else, but regardless, I think
it's pretty convincing.

I'll also point out that an agent whose report processing is restricted to
top-level reports is not free to error or misbehave when they receive a nested
report. MIME compliance places clear requirements on the handling of multiparts
that don't go away when the subtype isn't recognized. So at most you're going
to get a suboptimal display of a nested report as multipart/mixed. Any other
breakage is clearly not in conformance to RFC 2049.

Of course there are other sorts of reporting processing than displaying them,
such as automatic unsubscription of recipients from mailing list. In such cases
I'm not entirely sure I want them processing reports not at the top level,
restriction or no restriction.

> What we know from long experience is that the set of mail handling programs is
> large and that their behavior is diverse.  I don't think it's reasonable to try
> to determine what will break by experimentation, certainly not by exhaustive
> survey.

But we have in effect already done the experiment.

> And I think we have an obligation to not break things that were
> written to conform to earlier standards, at least not without a very good
> reason.

THat assumes they were actually written, and that the misbehavior is serious
enough to care about. I'm don't believe either condition applies in the case of
the restriction of reports to the top level.

> On the other hand, I don't know that I have ever bought the idea that
> something that does forwarding is expected to re-encode any multiparts just to
> make sure that there are no nested content-transfer encodings.

This is a tough one. The reason it's tough is that there are two cases, both of
which are forbidden but both of which are seen in practice:

(1) The specified CTE is actually present on the nested message or multipart.
(2) The header specifying the CTE is present, but the part isn't actually
    encoded.

I saw a fair amount of (1) right after MIME came out. Then (2) started showing
up, and if my experience is in any way typical, cases of (2) currently
outnumber (1) by a factor of 20 or more. But EAI is going to make (1) legal in
some cases, so the pendulum may end up swinging back the other way.

All that said, I don't see how this is relevant to the issue of allowing nested
reports. A proper report is going to have any CTE on the leaf nodes only. If
it's on a non-leaf node, you have (currently) invalid MIME and a problem
that transcends the subtype of multipart you happen to be using.

> I've always been more of the opinion that the message portion of a
> multipart/report (or any message/rfc822 bodypart) should be treated as an
> opaque object - not something that should automatically be presented on receipt
> or re-encoded when forwarded.

We certainly intended for this to be a viable approach.

> So I think that maybe we didn't specify the behavior of multipart in general or
> multipart/report in particular as well as we might have.  The goal was to not
> require MUAs to have to decode multiple layers of c-t-e.  What we did was to
> insist that there never be multiple layers of c-t-e, which (given forwarded
> messages) never was workable.

I don't see why. AFAIK nobody is saying the design is unworkable, only that
in hindsight the restriction had a lot more cost and a lot less benefit
than we thought.

>  Whether we can reasonably change that now is a
> different question.

AFAIK the report proposal isn't talking about allowing nested CTEs, only
nested reports.

				Ned

Subject: Re: New Version Notification for draft-kucherawy-rfc3462bis-00
From: Keith Moore <[email-masked]>
Date: Tue, 9 Nov 2010 13:02:17 -0500
Cc: "Murray S. Kucherawy" <[email-masked]>, "[email-masked]" <[email-masked]>
To: Ned Freed <[email-masked]>
Sender: [email-masked]

On Nov 9, 2010, at 12:12 PM, Ned Freed wrote:

>> FWIW, I'm strongly opposed to such a change, as it breaks backward
>> compatibility.
> 
> If this really is a serious interoperability issue (and I doubt very much it
> is) then perhaps the thing to do is place the restriction in the specific
> instances of multipart/report defined thus far. It's unnecessary to restrict
> all future use of multipart/report. It's also pointless, since all it will do
> is result in the definition of another report container without the
> restriction, which is messy and ugly.

I probably agree with that.

> Indeed, every single one of these restrictions we thought would be helpful for
> MIME implementors (e.g., encoding restrictions on message) has in hindsight
> turned out to be both unhelpful and a bad idea. 

I don't know how to evaluate that statement.  I am certainly aware of implementations of MIME that use statically allocated buffers for decoding base64, for instance.  Though it's certainly possible to write a decoder that doesn't work that way, this is easier in some languages than others.  We didn't specify MIME that way specifically because we didn't want to make implementation overly difficult for those using languages without automatic garbage collection; nor did we want to invite subtle bugs resulting from naive implementation.   Though not allowing nested encodings has been "unhelpful" in some ways, on balance I don't know how to say whether in hindsight it's been a bad idea.   But we made the decision for valid reasons, and I haven't seen anything so "unhelpful" as to convince me that we were totally off base there.

> Oh, and I'd buy that this is a real interop issue if you can name some MUA
> implemenations which when forwarduing using message/rfc822 encapsulation check
> to see if the message being forwarded contains a multipart/report and do
> something to correct that "invalid" nesting. (Exactly what it should do is a
> little unclear.)

I'm always dubious of arguments of the form "if you can't prove that this breaks something that's working now, assume that it doesn't break anything".  What we know from long experience is that the set of mail handling programs is large and that their behavior is diverse.  I don't think it's reasonable to try to determine what will break by experimentation, certainly not by exhaustive survey.  And I think we have an obligation to not break things that were written to conform to earlier standards, at least not without a very good reason. 

On the other hand, I don't know that I have ever bought the idea that something that does forwarding is expected to re-encode any multiparts just to make sure that there are no nested content-transfer encodings.  I've always been more of the opinion that the message portion of a multipart/report (or any message/rfc822 bodypart) should be treated as an opaque object - not something that should automatically be presented on receipt or re-encoded when forwarded.  So I think that maybe we didn't specify the behavior of multipart in general or multipart/report in particular as well as we might have.  The goal was to not require MUAs to have to decode multiple layers of c-t-e.  What we did was to insist that there never be multiple layers of c-t-e, which (given forwarded messages) never was workable.  Whether we can reasonably change that now is a different question.

Keith

From: [email-masked]
Cc: "Murray S. Kucherawy" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 09 Nov 2010 09:12:29 -0800 (PST)
Subject: Re: New Version Notification for draft-kucherawy-rfc3462bis-00
To: Keith Moore <[email-masked]>
Sender: [email-masked]

> FWIW, I'm strongly opposed to such a change, as it breaks backward
> compatibility.

If this really is a serious interoperability issue (and I doubt very much it
is) then perhaps the thing to do is place the restriction in the specific
instances of multipart/report defined thus far. It's unnecessary to restrict
all future use of multipart/report. It's also pointless, since all it will do
is result in the definition of another report container without the
restriction, which is messy and ugly.

Indeed, every single one of these restrictions we thought would be helpful for
MIME implementors (e.g., encoding restrictions on message) has in hindsight
turned out to be both unhelpful and a bad idea. You'd think we'd learn
eventually, but no.

Oh, and I'd buy that this is a real interop issue if you can name some MUA
implemenations which when forwarduing using message/rfc822 encapsulation check
to see if the message being forwarded contains a multipart/report and do
something to correct that "invalid" nesting. (Exactly what it should do is a
little unclear.)

I for one get nested multipart/reports all the time, because people have a
question about a report the natural thing for them to do is forward it.

				Ned

Subject: Re: New Version Notification for draft-kucherawy-rfc3462bis-00 
From: Keith Moore <[email-masked]>
Date: Tue, 9 Nov 2010 11:23:50 -0500
Cc: "[email-masked]" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Sender: [email-masked]

--Apple-Mail-20--372498095
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

FWIW, I'm strongly opposed to such a change, as it breaks backward =
compatibility.

Keith

On Nov 8, 2010, at 12:40 AM, Murray S. Kucherawy wrote:

> Another effort that was mentioned here previously.  This one is just a =
re-posting of RFC3462 (multipart/report) removing the =
must-be-outermost-MIME-type restriction.
>=20
> Comments welcome.
>=20
> -MSK
>=20
> From: IETF I-D Submission Tool <[email-masked]>
> Date: November 8, 2010 12:19:58 AM EST
> To: "Murray S. Kucherawy" <[email-masked]>
> Subject: New Version Notification for draft-kucherawy-rfc3462bis-00=20
>=20
>=20
>=20
> A new version of I-D, draft-kucherawy-rfc3462bis-00.txt has been =
successfully submitted by Murray Kucherawy and posted to the IETF =
repository.
>=20
> Filename:	 draft-kucherawy-rfc3462bis
> Revision:	 00
> Title:		 The Multipart/Report Media Type for the =
Reporting of Mail System Administrative Messages
> Creation_date:	 2010-11-07
> WG ID:		 Independent Submission
> Number_of_pages: 14
>=20
> Abstract:
> The multipart/report Multipurpose Internet Mail Extensions (MIME)
> media type is a general "family" or "container" type for electronic
> mail reports of any kind.  Although this memo defines only the use of
> the multipart/report media type with respect to delivery status
> reports, mail processing programs will benefit if a single media type
> is used to for all kinds of reports.
>=20
>=20
>=20
> The IETF Secretariat.
>=20
>=20
>=20
>=20

--Apple-Mail-20--372498095
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">FWIW, =
I'm strongly opposed to such a change, as it breaks backward =
compatibility.<div><br></div><div>Keith<br><div><br><div><div>On Nov 8, =
2010, at 12:40 AM, Murray S. Kucherawy wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Another =
effort that was mentioned here previously. &nbsp;This one is just a =
re-posting of RFC3462 (multipart/report) removing the =
must-be-outermost-MIME-type restriction.<br><br>Comments =
welcome.<br><br>-MSK<br><br><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(127, 127, =
127, 1.0);"><b>From: </b></span><span style=3D"font-family:'Helvetica'; =
font-size:medium;">IETF I-D Submission Tool &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br></s=
pan></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(127, 127, =
127, 1.0);"><b>Date: </b></span><span style=3D"font-family:'Helvetica'; =
font-size:medium;">November 8, 2010 12:19:58 AM EST<br></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
font-size:medium; color:rgba(127, 127, 127, 1.0);"><b>To: =
</b></span><span style=3D"font-family:'Helvetica'; =
font-size:medium;">"Murray S. Kucherawy" &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br></span></di=
v><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
font-size:medium; color:rgba(127, 127, 127, 1.0);"><b>Subject: =
</b></span><span style=3D"font-family:'Helvetica'; =
font-size:medium;"><b>New Version Notification for =
draft-kucherawy-rfc3462bis-00 </b><br></span></div><br><br><br>A new =
version of I-D, draft-kucherawy-rfc3462bis-00.txt has been successfully =
submitted by Murray Kucherawy and posted to the IETF =
repository.<br><br>Filename:<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span> =
draft-kucherawy-rfc3462bis<br>Revision:<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span> 00<br>Title:<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span> The =
Multipart/Report Media Type for the Reporting of Mail System =
Administrative Messages<br>Creation_date:<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span> 2010-11-07<br>WG ID:<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span> =
Independent Submission<br>Number_of_pages: 14<br><br>Abstract:<br>The =
multipart/report Multipurpose Internet Mail Extensions (MIME)<br>media =
type is a general "family" or "container" type for electronic<br>mail =
reports of any kind. &nbsp;Although this memo defines only the use =
of<br>the multipart/report media type with respect to delivery =
status<br>reports, mail processing programs will benefit if a single =
media type<br>is used to for all kinds of reports.<br><br><br><br>The =
IETF =
Secretariat.<br><br><br><br><br></blockquote></div><br></div></div></body>=
</html>=

--Apple-Mail-20--372498095--

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sun, 7 Nov 2010 21:40:54 -0800
Subject: FW: New Version Notification for draft-kucherawy-rfc3462bis-00 
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

Another effort that was mentioned here previously.  This one is just a re-p=
osting of RFC3462 (multipart/report) removing the must-be-outermost-MIME-ty=
pe restriction.

Comments welcome.

-MSK

--_002_F5833273385BB34F99288B3648C4F06F1340E63E1FEXCHC2corpclo_
Content-Type: message/rfc822

From: IETF I-D Submission Tool <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Nov 2010 21:19:58 -0800
Subject: New Version Notification for draft-kucherawy-rfc3462bis-00 

--_002_F5833273385BB34F99288B3648C4F06F1340E63E1FEXCHC2corpclo_--

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sun, 7 Nov 2010 21:28:19 -0800
Subject: FW: New Version Notification for draft-kucherawy-mta-malformed-00 
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

Some time ago I started looking into what the consensus is for various MTAs=
' handling of common malformations of email messages and MIME structures.  =
The collected wisdom thus obtained so far appears in the draft I've introdu=
ced, which is only meant as a starting point for such a collection of other=
 cases.

There was some consensus that this would be a useful effort to start, so he=
re I am starting it.  :-)

Please do feel free to review what's there and comment, and also submit sug=
gestions for other cases that might be of interest to record for future imp=
lementers.

-MSK

--_002_F5833273385BB34F99288B3648C4F06F1340E63E1BEXCHC2corpclo_
Content-Type: message/rfc822

From: IETF I-D Submission Tool <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Nov 2010 21:20:24 -0800
Subject: New Version Notification for draft-kucherawy-mta-malformed-00 

--_002_F5833273385BB34F99288B3648C4F06F1340E63E1BEXCHC2corpclo_--