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

[hub ryck <[e-mail]>]

Hi,

------------------------------------
*    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.
*
I did a mistake when I posted the first version. I wanted to change the
name but I don't know how. The problem is, when I post a new version, if I
change the name how the site will related it to the previous version ?
------------------------------------

------------------------------------
*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.
*
"it is easy to say" is ok for me. I modified section 1 in draft
"draft-hryckelynck-writing-rfcs-04" as follows :

"It is easy to say that mails with, for example, an attempted fraud content
are mails we must intercept."

Thank you !
------------------------------------

------------------------------------
*    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.
*
I deleted reference to RFC706 in draft "draft-hryckelynck-writing-rfcs-04"

Following your suggestion "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."

I checked every expired draft containing "mail" or "smtp" or "spam".
I could see that finding a way to get the user advice has been a concern
for others.
But none of the previous approaches I found is close from the one I propose.
The previous approaches I identified (I may have miss some) in the expired
drafts are mainly about :
- requesting the user advice with a "Challenge/Response"
- accepting or rejecting the sender adress

"Challenge/response" systems add suplementary work.
=> First message received from a new domain has to be treated anyway and
can be considered as a challenge and the user action on this message can be
considered as a response.

based the accept/reject on the sender address is not (yet?) affordable in
both of ressources and cost.
=> accept/reject on the domain would be much more affordable.
More over there is no method to check the user part today while we have
method to check if domain exists (DNS), and if the sender who uses the
domain is who he pretends to be (SPF, SENDER ID, DKIM).
------------------------------------

------------------------------------
*    "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. :-)
*
I was not sure of what you meant when you asked "What is my opinion".

I thought I had to reference both SPF and Sender ID as the note says :
"The IESG takes no position about which approach is to be preferred"

Also, I realized, as these RFCs are experimental, I may have referenced
them as non normative ?

My opinion is that it is too bad "efforts to reconcile the two approaches
have failed".
But I don't think it will help :-)

I didn't know you were writing a draft on the subject =>
"draft-moonesamy-senderid-spf-conclusion-xx"

I could give you a return of my own experience on this subject if you like.
------------------------------------

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

I added your name as a contributor in the acknowledgement section of new
draft
"draft-hryckelynck-writing-rfcs-04"

Would you like to be an author ? I would be more than happy if you want to.
------------------------------------

------------------------------------
*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 mail exchange we had is a really good example to discuss.

As a matter of fact your first mail arrived in the junk mail directory :-)

It is clear that Public Messagery can not implement an "offensive policy"
as described in section 6.1. And that's why I wrote in section 7.2.2.1.
(Which Strategy for which user / Public messagery / as a receiver) the
following.

"  Public messagery, if they finally decide to implement such mechanism,
   WOULD probably choose a defensive strategy like :

   o  put the "non accepted" mail in the junk mail directory

   o  accept the domain for the user if he declares a mail from this
      domain is not an unsollicited mail."


If we look now on what happen with IETF mailing list, my mail was submitted
to approbation.
It looks like my mail has to be "accepted" by someone. Also I could find in
RFC3683,
"maintainers of any IETF mailing list may, at their discretion, also remove
posting rights to that IETF mailing list."

But anyway I see what you mean, and I modified
"draft-hryckelynck-writing-rfcs-04" as follows :

- in section 3.3.2.2. (I put a reference to section 6)

   "*  If the answer is no, none of our users has explicitly, by
   sending some mail to it, declared that he wants to communicate
   with this domain and then we MAY apply some policy to reject or
   penalize the mail (see section 6)."

   Even in the most offensive policy (reject and notify), this mechanism
   is fully compliant with the SMTP responsability notion (deliver or
   report).

- in section 4.1. (I added penalize) :

   o  Start to reject or penalize non previoulsy accepted domain.

-  in section 6.1 (I put a warning about offensive policy) :

   "Offensive Policy" here means, mail that match the policy will be
   directly rejected.

   WARNING : You SHOULD carefully check what are your users need before
   to apply an offensive policy as described below, because you MAY
   reject some sollicited mails. If you are not sure it is preferable
   to choose defensive policy (see section 6.2)
------------------------------------

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

I fully agree with "the paragraph before Section 1.2 of
draft-klensin-rfc2821bis-06".

Drafts treating about spam issues has to be viewed as "best practices and
extensions for use with email to minimize the problem." They should avoid
"changes in the email environment that  sacrifice functionally"
particularly "the expectation that mail will be either delivered as
expected or properly rejected"

This can change "but the discussion about whether a different model is
desirable should occur before we start adding text to this document."

In my point of view, a part of that discussion should be how we could
establish that the "delivery is mutually desired (whether expected or not)
by both sender and recipient."

Until those discussions produce a wide consensus they "should be in
documents that build on RFC 2821 and 2821bis (and 2822 and 2822bis), rather
than being part of them."


So I will do an answer similar to the one I made about experimental status.
At this stage,  "draft-hryckelynck-writing-rfcs-xx" has to be viewed as a
practice and then if the community gives sympathetic consideration to this
practice we could then design parts of this practice
as a protocol (like for example communication between MTA and Base) or as
protocol extensions (specific header, error code, ...).

In resume :
1- what about this idea ?
2- work
3- if idea is OK => what about a practice ?
4- work
5- if practice is OK => what about designing parts of this practice as a
protocol ?

Do I have to modify something in this sense in the draft headers to show
this is a Practice and not a protocol ?
Is "Intended status: Experimental" still OK ?

========================
Also, I received the following comment from Dave Crocker "the proposal does
not seem to require any user choice". As a matter of fact at this stage I
was only proposing to store information about domain to which users were
sending mail. But If we want to store an explicit answer from the users (as
a real challenge/response) we would need some new elements :
- a 3 directories system (INBOX, NEW, JUNK) instead of the traditionnal 2
directries system (INBOX, JUNK).
- store the domain names and values representing the user's declaration
(accepted, rejected) instead of only the domain name.

Please find below an explanation of how it could work (copy the following
scheme in a txt file) :

                      1.6                      +--+--+
        +------------------------------------->|AC|RE|
        |                            +---------------+
        |                        +---|@dom2.com|01|00|<---+ 2.2
        |                        | +-|@dom1.com|00|00|<-+ | 1.2
        |                        | | +---------------+  | |
        |                        | +-------+   +--------+ |
        |                        +-----+   |   |   +------+
        |                              |   |   |   |
    ####|####################      ####|###|###|###|####
    #   |                   #      #   |   |   |   |   #
    #   |  MUA    ######### #      #   |   |   |   |   #
    #   |         #       # # 2.3  #   |   |   |   |   # 2.1
    #   |    1.5  # INBOX #<-----------+   |   |   +---------
    #   |  +----->#       # #      #       |   |       #
    #   |  |      ######### #      #       |   |       #
    # ######## 1.4          #      #       |   |       #
    # #ACCEPT#<---######### #      #       |   |       #
    # ########    #       # # 1.3  #       |   |       # 1.1
    #             #  NEW  #<---------------+   +-------------
    # ######## 3.4#       # #      #                   #
    # #REJECT#<---######### #      #                   #
    # ########              #      #        MTA        #
    #   |  | 3.5  ######### #      #                   #
    #   |  +----->#       # # 3.3  #                   # 3.1
    #   |         # JUNK  #<---------------+   +-------------
    #   |         #       # #      #       |   |       #
    #   |         ######### #      #       |   |       #
    #   |                   #      #       |   |       #
    ####|####################      #       |   |       #
        |                          #       |   |       #
        |         +-------+        #       |   |       # 4.1
        |         |       |   4.3  #       |   |   +---------
        |         | DROP  |<-----------+   |   |   |   #
        |         |       |        #   |   |   |   |   #
        |         +-------+        ####|###|###|###|####
        |                              |   |   |   |
        |                        +-----+   |   |   +------+
        |                        | +-------+   +--------+ |
        |                        | | +---------------+  | |
        |                        | +-|@dom3.com|00|01|<-+ | 3.2
        |                        +---|@dom4.com|01|10|<---+ 4.2
        |                            +---------------+
        |                                      |AC|RE|<-+
        |              3.6                     +--+--+  |
        +-----------------------------------------------+


1.1 : A mail arrives from @dom1.com on the MTA.
1.2 : The MTA checks in the base and sees nobody has previously accepted
this domain ("00" in the column "AC").
1.3 : The MTA adds a "new" header and send it to the MUA. A rule on the MUA
identifies the header and put the  mail in the "NEW" Directory.
1.4 : If the user wants do declare this mail is sollicited, he clicks on
the "ACCEPT" button.
1.5 : Then the MUA puts the mail in the "INBOX" Directory
1.6 : and declares the domain as accepted in the base (+1 in the column
"AC").

2.1 : A mail arrives from @dom2.com on the MTA.
2.2 : The MTA checks in the base and sees somebody has previously accepted
this domain ("01" in column "AC").
2.3 : The MTA sends it to the MUA and the MUA put the mail in the "INBOX"
Directory.

3.1 : A mail arrives from @dom3.com on the MTA.
3.2 : The MTA checks in the base and sees somebody has previously rejected
this domain ("01" in column "RE").
3.3 : The MTA adds a "junk" header and send it to the MUA. A rule on the
MUA identifies the header and put the  mail in the "JUNK" Directory.
3.4 : If nobody had accept or reject the mail from @dom3.com, the mail
would have been sent whith a "new" header  in the "NEW" box and then the
user may have wanted do declare it as unsollicited by clicking on the
"REJECT"  button.
3.5 : the MUA would then have put the mail in the "JUNK" Directory
3.6 : and declares the domain as rejected in the base (+1 in the column
"RE").

4.1 : A mail arrives from @dom4.com on the MTA.
4.2 : The MTA checks in the base and can see somebody has previously
accepted this domain ("01" in column "AC")   but also that mails from this
domain has been rejected 10 times ("10" in column "RE").
4.3 : If 10 is more than the limit the administrator fixed the mail is
directly dropped.
============

I'm looking forward for your comment.

Thank you very much again for your time and your help.


Regards,
Hubert




2012/4/29 SM <[e-mail]>
>
> 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