IETF Logo Mail Archive

Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-03

"Murray S. Kucherawy" <superuser@gmail.com> Fri, 17 May 2013 02:22 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC03711E80E3 for <apps-discuss@ietfa.amsl.com>; Thu, 16 May 2013 19:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.219
X-Spam-Level:
X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6P80-U1Ktro for <apps-discuss@ietfa.amsl.com>; Thu, 16 May 2013 19:22:17 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E6ECA21F8B2B for <apps-discuss@ietf.org>; Thu, 16 May 2013 19:22:16 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id t60so3302336wes.27 for <apps-discuss@ietf.org>; Thu, 16 May 2013 19:22:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dDLEwUdH0fZc+E/15A2hLjEl3VUqkYVvlZqQuA9UA7g=; b=CltwY+G2sfjADRb0taJpNHnBJznGiKixIkiAA83HNv3LMbBmIw9KwNj3cKgEC942jG VOKOyT/A+x+Ops0ZQbMLCExKX2/l+sKkjcvon7PzCUucf9TFDDiyeB1HLpj5zQg4a0BD /P2JiXRj4pxRODSd4vH9N49CI/Z1Xk/fVssOY94QCcS17daZljTCX6THOQRri1QKBjbq YhsCse4zxXDkYAQUhE43yg0vyUcJQTZvUNmzUCucse5YOZORnjLDD6J/7RxYjwGKg+cy YYDFr0eZAmWfPcpG3DLnINbCjzlP0zcVUhHqGnWcTBVnXXzV8xqhQOma3pAKYD2QomyY o1Ew==
MIME-Version: 1.0
X-Received: by 10.180.74.172 with SMTP id u12mr3610663wiv.0.1368757336071; Thu, 16 May 2013 19:22:16 -0700 (PDT)
Received: by 10.180.14.34 with HTTP; Thu, 16 May 2013 19:22:15 -0700 (PDT)
In-Reply-To: <566479399.228274.1368755255546.JavaMail.root@peachymango.org>
References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> <alpine.BSF.2.00.1305152133120.63512@joyce.lan> <WM!bfe1c6e9f2cec463d88767774705f9aef8a6e50e314f1208c41151b23f2f505efe6cba8b632fd037a0024672a98771a4!@asav-2.01.com> <566479399.228274.1368755255546.JavaMail.root@peachymango.org>
Date: Thu, 16 May 2013 19:22:15 -0700
Message-ID: <CAL0qLwYmMtDt07GGFAan1Qru87qzDjefKwUXJgZsj41sSCJLwA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Franck Martin <franck@peachymango.org>
Content-Type: multipart/alternative; boundary="f46d04389001cce5be04dce0a6a6"
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2013 02:22:17 -0000

On Thu, May 16, 2013 at 6:47 PM, Franck Martin <franck@peachymango.org>wrote:

> 8.1.5. Unbalanced Quotes
>
> Not sure I agree with that, we should avoid to place a domain name in the
> display part.
>
> should be interpreted as:
> To: "Joe" <joe@example.com>
>

The document doesn't talk about what end users should be shown.  It's all
about filters and other handling agents.  There's some specific text in
there that talks about "internal representations" and such; see Section 4.


> 8.5. Header Field Counts
>
> I see option 1 at the MTA level
> option 2 at the MSA
> for an MUA, it has to deal with an invalid message, I think 3 could apply,
> but then the MUA only renders the message why should it alter it,
> especially if the message will be rendered by different MUA.
>

The MSA is not in scope here, other than the fact that the document
mentions that MSAs need to be more strict.  This is all about MTAs and
filters.


> 8.6. Missing Header Fields
> I see it differently...
>
> If the email comes from a MSA then add the fields, if the email comes from
> another MTA, reject the email.
>

See above.

-MSK

v2.23.0 | Report a Bug | By Email