Re: [apps-discuss] Comments on draft-hryckelynck-writing-rfcs-01

SM <sm@resistor.net> Sun, 29 April 2012 21:55 UTC

Return-Path: <sm@resistor.net>
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 125B021F85A4 for <apps-discuss@ietfa.amsl.com>; Sun, 29 Apr 2012 14:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Level:
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 hPrFhArJ5mJK for <apps-discuss@ietfa.amsl.com>; Sun, 29 Apr 2012 14:55:10 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9CA21F8546 for <apps-discuss@ietf.org>; Sun, 29 Apr 2012 14:55:10 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3TLt2R3021607; Sun, 29 Apr 2012 14:55:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335736508; i=@resistor.net; bh=zFt328gSRtUQfTQVfyVgRVj7T7+LNyunSOPzwXmoFCM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RLVi1BG7RqawagM396LCCLWAo5Brg3saVlGc4QF6pQBtQk1ixCwdxc3cIa0zQcN+9 kUmmdS1nytA7t4rOC3xHjodKLfLX65bhr0xEnBZMh9GIpy7qmgYEGniRmQK4mjwwhi L0fiRx/HEvmCHR2rRpF/gk/yZs/7bF/XNXSAalic=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335736508; i=@resistor.net; bh=zFt328gSRtUQfTQVfyVgRVj7T7+LNyunSOPzwXmoFCM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=I74k6S5sQe1TfpuMyDm1if4GCnNxWC/qSbpsXF1m9TKk0gsgZ894tPDB0GNvqusch OfEh2Ir2FNlN+dnc4CcsKVuJCif0rUSWdmXhlYLKRBbP3tADCQVhWknKEtjwABOe9m yavNz+A7O482kcl/5u9eHAyTZnxGLyRzs5EctF0I=
Message-Id: <6.2.5.6.2.20120429134847.08f02068@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 29 Apr 2012 14:53:11 -0700
To: hub ryck <hub.ryck@gmail.com>
From: SM <sm@resistor.net>
In-Reply-To: <CAAyzDoSNZUiRnfg7tePdaSY1xjmQqqW37TbwMk8mL-uVKHEuTg@mail.g mail.com>
References: <6.2.5.6.2.20120421143240.07253358@elandnews.com> <CAAyzDoSNZUiRnfg7tePdaSY1xjmQqqW37TbwMk8mL-uVKHEuTg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comments on draft-hryckelynck-writing-rfcs-01
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: Sun, 29 Apr 2012 21:55:13 -0000

Hi Hubert,
At 09:59 29-04-2012, hub ryck wrote:
>About April 1st, I confirm to you this is not a "funny RFC".
>I do not have a plan yet about how long this experiment should be run.
>If the community gives sympathetic consideration to this idea maybe 
>one day I would intend another status. But at this time the only 
>intended status is experimental.

Ok.

>Modified in new version "draft-hryckelynck-writing-rfcs-03"

You might wish to choose a different filename for the draft as the 
"writing-rfcs" does not say much about the subject of the draft.

>You are right. In fact I was thinking pornographic content should 
>not be sent to a working environment. But then you could also say 
>that some people are working in the pornographic business. So I will 
>take another example.

The draft does not mention that it is applicable to a working 
environment only.  As you mentioned above, it can be argued that 
there are work environments where such content may be used.

>  "Mails with, for example, an attempted fraud content are easy to 
> identify as mails we MUST intercept."

Some people may ask how to identify "fraud content".  It's easy to 
say that fraud MUST be intercepted.  If there is no way to identify 
fraud, it cannot be implemented.

>As this section is talking about the responsabilty notion described 
>in RFC5321,
>I replaced in new version "draft-hryckelynck-writing-rfcs-03" the 
>term "Philosophy" by "responsibility notion" in the entire section 3.

Ok, for now.

>In RFC 5321, section 3.6.2 on page 27 :
>                               "A server MAY attempt to verify the return

I missed that.

>I did not remember of this RFC. Thank you for the information.

There are a lot of RFCs.  Some of them contain good ideas, some of 
them contain bad ideas.  It is up to you to assess whether the 
contents of the RFC are appropriate or not.

>The only differences I could find between RFC 706 and my draft are :
>- a list of sources to refuse against a list of source to accept
>- a list of sources kept per host against a list of sources kept for any host.
>
>But as RFC 706 described these differences only as possibilities and 
>as it mentions it is an open issue, we could consider my draft is an 
>attempt to give an answer to the same problematic. I have then 
>referenced RFC 706 directly in section 1 in new version 
>"draft-hryckelynck-writing-rfcs-03" as follows :
>
>    "With this in mind, it MAY be useful to find a mechanism for users to
>    choose themselves who will be able to send them some mails as that
>    was suggested in RFC 706 [RFC706]."

I suggest not using RFC 706 as a reference unless you are sure that 
you can make a case for why it is relevant.

There were and there still are open issues.  It may help to research 
why some of these open issues remain open after over 25 years and see 
whether the answer you provide was not proposed previously before 
being considered as not workable.

>"For this purpose you may need other mechanism that could be viewed 
>as complementary like Sender ID [RFC4406], SPF [RFC4408] or DKIM [RFC6376]."

That doesn't really answer the question I asked. :-)

>As a newcomer I have a question. Do I need your authorization to 
>reference your name as contributor in my draft ?

You do not need my authorization to provide an acknowledgement.  If 
you were to add me as an author, for example, it is better if you 
seek authorization first.  If you are unsure, it is easier to ask.

>Please tell me if there is anything else you would change.

As I mentioned previously, the draft needs more work.  It would help 
if you could get reviews of the draft from other people involved in email.

There is a lot I would change.  For example, this is from the Abstract section:

   "Mail Accepted by Previous Sending defines a mechanism by which
    incoming unsollicited mails may be rejected or penalized by a MTA if
    their sender address domains has never been a destination for the
    outgoing mails treated by this MTA."

The email I sent to you was unsolicited.  Are you sure that the MTA 
for your mailbox has seen emails with my email address as a 
destination?  If the answer is no, my email would be rejected or 
penalized by the MTA at your end.  There is a higher probability that 
you would not be seeing my previous message.  There is a word in my 
previous message which could get it tagged as containing offensive content.

The draft is more about email practices than a protocol.  There is a 
difference between the notion of responsibility for hand-off 
(relaying messages) and the notion from a non-technical 
perspective.  There is a note in the paragraph before Section 1.2 of 
draft-klensin-rfc2821bis-06.  I suggest that you take a look at it.

Regards,
-sm