Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Jul 2011 20:30:15 +0100

Mykyta Yevstifeyev wrote:

> Is it going to result in something?

Yes, this is still on my to do list. I am being slow.

> Mykyta
>
> 21.04.2011 0:38, Alexey Melnikov wrote:
>
>> Dear APPSAWG participants,
>> There has been an active discussion about the document this week. 
>> Given that, I would like to ask the following questions:
>>
>> 1). Who is willing to review and post comments on the document if the 
>> WG accepts this document as a WG document?
>>
>> 2). Are there any objections to accepting this document as a WG 
>> document?
>>
>> If you have an objection, please be explicit about the nature of the 
>> objection (for example, if you think the document is harmful and 
>> shouldn't be worked on). Note that just saying that you don't like 
>> the document is not a good enough reason without further explanation.
>>
>> Explicit statements in favor of accepting are welcomed as well. But 
>> please also respond if you find objections by others to be 
>> objectionable ;-).
>>
>> You can send both objections and your statements of support directly 
>> to me (if you wish) or to the mailing list.
>>
>> Please send your responses by the end of April 29th.
>>
>> Alexey,
>> as an APPSAWG co-chair
>>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
twitter: aamelnikov

---

From: Randall Gellens <[email-masked]>
Date: Tue, 5 Jul 2011 21:25:04 -0700

This is a nice, short, clearly written draft.

In Section 1.1., the draft says:

    The history of email standards, going back to [RFC822] and beyond,
    contains a fairly rigid evolution of specifications.  But
    implementations within that culture have also long had an
    undercurrent known formally as the robustness principle, but also
    known informally as Postel's Law: "Be conservative in what you do, be
    liberal in what you accept from others."

    In general, this served the email ecosystem well by allowing a few
    errors in implementations without obstructing participation in the
    game.  The proverbial bar was set low.  However, as we have evolved
    into the current era, some of these lenient stances have begun to
    expose opportunities that can be exploited by malefactors.  Various
    email-based applications rely on strong application of these
    standards for simple security checks, while the very basic building
    blocks of that infrastructure, intending to be robust, fail utterly
    to assert those standards.

The robustness principle has had some controversy over the years.  If 
I recall correctly, there was a draft some years back called "Be 
Liberal Considered Harmful" because deployed servers that accepted 
non-compliant messages were responsible for widespread deployment of 
broken clients.  This resulted in "standards creep" where new servers 
were forced to accept common but erroneous messages and protocol, and 
made it harder to develop extensions.

It might be worthwhile to mention some of this immediately following 
the quoted text.  Also, it might be worthwhile to suggest that it's 
good for MSAs fix or reject stuff that is broken (obviously this 
draft can't mandate this).

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
(If you can't hear me, it's because I'm in parentheses)

---

From: "John Levine" <[email-masked]>
Date: 6 Jul 2011 05:22:47 -0000

>draft can't mandate this).

This draft can't mandate it, but since MSAs are only supposed to
submit valid RFC 5322 (or 2822) messages, I'd think it would be OK to
point out that existing standards already mandate it.

R's,
John

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 8 Jul 2011 11:10:13 +0100

> point out that existing standards already mandate it.

This is perhaps ok for MSAs, because the rejection happens close to the sender, who will typically get feedback.  It's a different story on the receiving end.  The existing standards mandate the *submission* of valid messages, but say little about what to do when you receive invalid messages.

It has been our experience that when we reject invalid incoming messages that are "nearly valid," our users tend to complain that their previous provider/software let such messages through, and they conclude that our system is broken for blocking mail that previously reached them.   They pressure us to "fix" our system with the threat that they'll seek alternative providers.  

You may not like it -- I certainly don't! -- but the market exerts strong pressures on us to accept malformed messages if we can possibly make sense of them.  I, for one, would love to see a third alternative besides "accept" and "reject" -- perhaps accepting the message for delivery but also sending a warning to the sender.  Of course, there are lots of problems with that, too. -- Nathaniel

---

From: "John R Levine" <[email-masked]>
Date: 8 Jul 2011 10:24:21 -0400

> This is perhaps ok for MSAs, because the rejection happens close to the sender, who will typically get feedback.  It's a different story on the receiving end.  The existing standards mandate the *s…

Well, I did carefully say MSAs in that sentence.  You're right, picky 
enforcement of RFC 5322 and its predecessors on mail from strangers tends 
to lose more sloppy legit mail than unwanted mail.

I think it'd be worth noting that MSAs can and should be stricter about 
what they accept than relay MTAs are.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 Jul 2011 07:27:41 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R Levine
> Sent: Friday, July 08, 2011 7:24 AM
> To: Nathaniel Borenstein
> Cc: [email-masked]
> Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document
> 

I'd be fine with that.

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 8 Jul 2011 07:37:35 -0700

>> what they accept than relay MTAs are.

+1, so long as we explain that this is most often due to end user preferences rather than technical concerns.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: "John R Levine" <[email-masked]>
Date: 8 Jul 2011 10:41:30 -0400

>> what they accept than relay MTAs are.

If I may revise and extend my remarks, an MSA, unlike an MTA, can 
reasonably fix a lot of flaws that an MTA would have to either tolerate or 
reject, since it typically has metadata like a sender (whoever AUTHed) and 
a date (now).  And as others have noted, the costs of rejection are 
typically a lot less, just bumping the message back to the author to fix.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Jul 2011 12:59:14 -0400

> If I may revise and extend my remarks, an MSA, unlike an MTA, can reasonably
> fix a lot of flaws that an MTA would have to either tolerate or reject,
> since it typically has metadata like a sender (whoever AUTHed) and a date
> (now).  And as others have noted, the costs of rejection are typically a lot
> less, just bumping the message back to the author to fix.

Beware, though: you quickly run into the infamous BMP -- "Barry's
Mother" Problem.

The "author" isn't going to fix it.  The MUA is.  If the author is
using a broken MUA, which generates the malformed message, bumping it
back to the author amounts to telling the author to use a different
(or newer version) MUA.

If the author is my mother, that simply won't work.  It also won't
work in the case of, say, a company with 20,000 copies of PoodleMail,
when the company just switched to you as their service provider.
"Oh," they will say, "That was a mistake.  I'd better switch back to
my old service provider, because PoodleMail worked fine with them!"
They certainly aren't likely to have all 20,000 of their employees
switch to a different mail program in order to accommodate *you* (as
they see it).

Barry

---

From: "John R Levine" <[email-masked]>
Date: 8 Jul 2011 13:19:32 -0400

> Beware, though: you quickly run into the infamous BMP -- "Barry's

It certainly depends on the context, and the problem.  If the problem is 
that the subject line is missing, Mom might fix it.  If it's that the 
message-id has two @ signs, probably not.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Jul 2011 13:24:34 -0400

> message-id has two @ signs, probably not.

Usually, the problem is that the body of the message contains a stupid
joke that everyone has seen 17,000 times.  Mom certainly won't fix
that.

In that case, I think the right work-around is to silently discard it.

b

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sat, 9 Jul 2011 13:37:32 +0100

+1