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

From: SM <[email-masked]>
Date: Sat, 21 Apr 2012 15:26:32 -0700

Hello,

[message copied to apps-discuss@ in case other people would like to 
provide feedback about this proposal]

The initial version of draft-hryckelynck-writing-rfcs-01 was posted 
on April 1.  I wasn't sure whether the date was intentionally 
chosen.  I note that draft-hryckelynck-writing-rfcs is intended to be 
published as Experimental.  Do you have a plan about how long this 
experiment should be run?

In 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 "MAY" should be written as "may".

In the Introduction Section:

   "Mails with, for example, a pornographic contains are easy to identify
    as mail we MUST intercept."

Some people enjoy pornographic content.  The above requirement 
forbids that.  Is that intentional?

The RFC 2119 key words in the first section should be removed.

In Section 2, you are using a "MUST" before the RFC 2119 boilerplate.

   "These words take their normative meanings only when they
    are presented in ALL UPPERCASE."

That's somewhat unusual.  Is that from RFC 2119 or the author's choice?

In Section 3.1:

   "In the SMTP RFC [RFC5321], you will find a responsability notion."

Shouldn't this be about design instead of philosophy?

In Section 3.2.1:

   "Because of the huge quantity of unsollicited mail and to avoid giving
    more information to those whore are sending them, section 6.2 of RFC
    5321 [RFC5321] permit in practice silent dropping and more and
    more MTA are configured to drop silently those mails."

"whore" looks like a typo.

I note that Section 6.2 of RFC 5321 also says:

   "However, it is extremely dangerous and violates a long tradition and
    community expectations that mail is either delivered or returned. If
    silent message-dropping is misused, it could easily undermine
    confidence in the reliability of the Internet's mail systems."

In Section 3.3.1:

   "But at this time the RFC 5321 [RFC5321]in section 3.6.2 doesn't
    RECOMMENDED any method."

I could not find anything in Section 3.6.2 about Return-path.

In Section 6.2.2:

   "For example, if the MTA receive a mail that SHOULD be dropped because
    it comes from an IP which has a bad reputation."

That sentence could be part of the sentence in the previous paragraph.

In Section 7.1.2.2:

   "When a user wants to be reached by a commercial site, he will only
    have to declare the domain.  This will force commercial site to
    specify clearly which domain they use for their sending."

In the above based upon RFC 706?

In Section 9.2:

   "It is not garantied, when a mail which has a sender address from a
    domain you previously accepted, that this mail really come from this
    domain.  For this purpose you will need other mechanism that could be
    viewed as complementary like SPF [RFC4408] or DKIM [RFC6376]."

What is your opinion about the IESG note at the beginning of RFC 4408?

The "Mail Accepted by Previous Sending" proposal might need some more 
work before it is ready for publication as a RFC.

Regards,
-sm

---

From: hub ryck <[email-masked]>
Date: Sun, 29 Apr 2012 18:59:13 +0200

Hello,

[message copied to apps-discuss@ in case other people would like to provide
feedback about this proposal]

*The initial version of draft-hryckelynck-writing-rfcs-01 was posted on
April 1.  I wasn't sure whether the date was intentionally chosen.  I note
that draft-hryckelynck-writing-rfcs is intended to be published as
Experimental.  Do you have a plan about how long this experiment should be
run?
*
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.

*In the Abstract Section:

The "MAY" should be written as "may".*

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

*

Some people enjoy pornographic content.  The above requirement forbids
that.  Is that intentional?*

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.

Sentence has been modified in new version
"draft-hryckelynck-writing-rfcs-03" as follows :

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

*The RFC 2119 key words in the first section should be removed.
*
Modified in new version "draft-hryckelynck-writing-rfcs-03"

*In Section 2, you are using a "MUST" before the RFC 2119 boilerplate.

That's somewhat unusual.  Is that from RFC 2119 or the author's choice?*

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

*In Section 3.1:

Shouldn't this be about design instead of philosophy?
*
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.

*In Section 3.2.1:

"whore" looks like a typo.*

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

*I note that Section 6.2 of RFC 5321 also says:

 "However, it is extremely dangerous and violates a long tradition and
  community expectations that mail is either delivered or returned. If
  silent message-dropping is misused, it could easily undermine
  confidence in the reliability of the Internet's mail systems."
*
Section 3.3.1 has been modified in new version
"draft-hryckelynck-writing-rfcs-03" as follows :

   "If section 6.2 of RFC 5321 [RFC5321] permits in practice silent
   dropping, it also pleads to keep the "delivered or returned" way to
   deal with mails.

   In this sense, those past years, efforts has been made to find some
   ways to check the return path as to stay close from the original
   responsability notion (deliver or notify). You of course need a
   return path in case of notify."

*In Section 3.3.1:

I could not find anything in Section 3.6.2 about Return-path.*

In RFC 5321, section 3.6.2 on page 27 :
                              "A server MAY attempt to verify the return
   path before using its address for delivery notifications, but methods
   of doing so are not defined here nor is any particular method
   recommended at this time."

*In Section 6.2.2:

That sentence could be part of the sentence in the previous paragraph.*

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

*In Section 7.1.2.2:

In the above based upon RFC 706?*

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

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]."

*In Section 9.2:

What is your opinion about the IESG note at the beginning of RFC 4408?*

Last sentence has been modified in new version
"draft-hryckelynck-writing-rfcs-03" as follows :

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

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

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

Thank you very much for your time and your help.

Regards,
Hubert

2012/4/22 SM <[email-masked]>

> The initial version of draft-hryckelynck-writing-**rfcs-01 was posted on
> April 1.  I wasn't sure whether the date was intentionally chosen.  I note
> that draft-hryckelynck-writing-rfcs is intended to be published as
> Experimental.  Do you have a plan about how long this experiment should be
> run?
>
> In the Abstract Section:
>
> Some people enjoy pornographic content.  The above requirement forbids
> that.  Is that intentional?
>
> The "Mail Accepted by Previous Sending" proposal might need some more work
> before it is ready for publication as a RFC.
>
> Regards,
> -sm
>
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Apr 2012 13:57:02 -0700

Basic concern:

This document appears to be unaware of the established practice of 
greylisting, such as the just-approved document.

    http://tools.ietf.org/html/draft-ietf-appsawg-greylisting-09

Minor:

> The "MAY" should be written as "may".

Actually, that changes nothing.  Normative vocabulary does not require 
capitalization. If the document uses the normative terms, it needs to 
use non-normative vocabulary for non-normative meaning, per:

    http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119-01.html

> With this in mind, it may be useful to find a mechanism for users to
>    was suggested in RFC 706 [RFC706].

A document that was written 35 years ago, before spam had ever happened, 
cannot reflect the last 20 years of operational experience, no matter 
how insightful the author.

It happens that some of that experience shows quite strongly that a 
mechanism like the one proposed here won't work.

> users to
>    choose themselves who will be able to send them some mails

Too much user effort of the wrong kind.

In addition, the proposal does not seem to require any user choice.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: SM <[email-masked]>
Date: Sun, 29 Apr 2012 14:53:11 -0700

Hi Hubert,
At 09:59 29-04-2012, hub ryck wrote:
>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.

>                               "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.

>- 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 

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