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

From: hub ryck <[email-masked]>
Date: Thu, 17 May 2012 13:12:53 +0200

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|
        |                            +---------------+
        |                        [email-masked]|01|00|<---+ 2.2
        |                        | [email-masked]|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  |<-----------+   |   |   |   #
        |         |       |        #   |   |   |   |   #
        |         +-------+        ####|###|###|###|####
        |                              |   |   |   |
        |                        +-----+   |   |   +------+
        |                        | +-------+   +--------+ |
        |                        | | +---------------+  | |
        |                        | [email-masked]|00|01|<-+ | 3.2
        |                        [email-masked]|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 <[email-masked]>
>
> 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

---

From: hub ryck <[email-masked]>
Date: Thu, 17 May 2012 13:52:16 +0200

Hello,

2012/4/29, Dave Crocker <[email-masked]>:
> 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

I was unaware of draft-ietf-appsawg-greylisting-xx. I read it and
found many similarities between your approach and mine.

About the goal of such approaches :
-----------------------------------
Section 1 : "requirement is for an array of techniques to be used by
each filtering system"
Section 2 : "A set of attributes about the client-side smtp server are
used for assessing whether to perform"

IP Reputation has done a really good job those past years but is not
enough sufficient anymore.
We now have to add some other attribute to filter. Notably concerning
the developpement of cloud computing in which more and more senders
are sharing their IP.

About the way it will work :
----------------------------
Section 1.1 : "rejecting mail from unfamiliar sources"
Section 2.6 : "Being able to identify spamware within the SMTP context
beyond the simple notion of "not seen before" would be desirable"
Section 2.1 : "keep a record", "such a database acts as a cache"
Section 2.1 : "if the source is not in the database ... the server
does one of the following"
Section 4.2 : "serves should share the same ... database"
Section 5 : "manual override capability"
Section 3 : "so after a training period, only a small proportion of
mail is actually affected."

So, both approaches are really close in the way they work. I could see
so far 2 main differences.

the information kept in the base :
----------------------------------

You are proposing to store "tuples" about IP + Return-Path or HELO or
RCPT or Data.
And I propose to store information about domain.

First,I agree with the warning you put in your draft "another obvious
cost is for the required database" (section3). The base in our case
would be huge.
In case of TUPLE IP/RCPT  this would represent x times 100.000 records.
In case of TUPLE IP/RETURN-PATH this would represent x times 100.000 records.

More over if we use "IP/RETURN-PATH" tuple, "those that send so rarely
that they will age out of the database" (section 2.7) will represent x
times 1000 senders and we could not afford the proposed "known
friendly senders will be manually configured as exceptions" (section
3) even if the default timeout for database entries "should be at
least one week" (section 5).

The tuple "IP/HELO" tuple would be much more affordable but the
problem is that still a lot of sender's HELO/EHO are uncheckable (no
DNS reverse record). And also a same hello can send mail from
different mail domain some sollicited and some not.

Do you think it would be possible to add in your document a tuple with
Ip/domain ?
as an "IP/DOMAIN" tuple would, for us, represent only x times 10.000
records and this would be much more affordable.

Also, concerning the size of the base, I prefer a separate treatment
approach like :
- check the IP reputation
- check the domain on DNS
- store and check the accepted domains
...

To a tuple aproach in wich records are multiplied (sender x IP, rcpt x
IP, ....)

the action to be performed :
--------------------------

The action you are proposing is greylisting.
I propose to store information about sollicited domain and let the
administrator choose about what policy he wants to apply on this
information.

Greylisting has to be proposed as a solution among other and might be
a good solution for some but not for all. You have very well described
all the problems administrators may have implementing grey listing.

The main problem is of course that it impacts also good actors like
described in section 2.1  "simpler policy affects all new connections,
including those from good actors", in section 3 "imposition of delay
on legitimate mail.", and in section Section 4.2 : "delay can become
large enough to become large enough to become a nuisance to users"

The only point on wich I do not completely agree is the cost of
greylisting like described in
Section 1 "Greylisting happes to be a technique that is cheap" and
Section 3 "this cost is ultimately low". For the administrator who
implements greylisting it is cheap, but this will cost ressources to
others as mail temporary rejected are staying in the sender queue and
the sender MTA will have to send it Two times. This will then imply a
cpu and memory cost. If only a few administrators choose to implement
greylisting it will not be a problem but if everybody is implementing
greylisting this will cost to everybody particularly in term of memory
available in the departure queue.

As a matter of fact, greylisting practice is actually growing and I
had already to low down the time I was keeping mail in the departure
queue as I was concern by the quantity of memory taken by message
waiting in the queue.

So you may have understood greylisting is not my favorite approach.
But anyway you have done a really ggod job writing this document as I
think in the same approach we can find in the  RFC 4408 IESG Note
"documenting the different approaches does less harm than not
documenting them."

> Minor:
>
> On 4/21/2012 3:26 PM, SM wrote:
>> In the Abstract Section:
>>
>> incoming unsollicited mails MAY be rejected or penalized by a MTA if
>> 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
>

=> modified in new version "draft-hryckelynck-writing-rfcs-04"

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

=> I deleted reference to RFC 706 in new version
"draft-hryckelynck-writing-rfcs-04"

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

Following your remark, I checked every expired draft containing "mail"
or "smtp" or "spam".
I found many drafts in which user advice was a concern but none is
close from what I propose.

The previous approaches I identified in expired drafts are mainly about :
- requesting the user advice with a "Challenge/Response"
- accepting or rejecting the sender adress

About "Challenge/response" :
As first message received from a domain (which has to be treated
anyway) can be considered as a challenge and the user action on this
message can be considered as a response to this challenge, I  think
suplementary "Challenge/response" would be suplementary work.

About accepting or rejecting the sender adress :
I think based the accept/reject on the sender address is not (yet?)
affordable in terms of both ressources and cost. That's why I proposed
to accept/reject on the domain as this would be much more affordable.
More over there is no method to check the user part today, where 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).

As I may have missed some I would be grateful if you can give me
information about these experiences that were not working.

>> users to
>>    choose themselves who will be able to send them some mails
>
> Too much user effort of the wrong kind.
>

with all due respect to a man who was involved in SMTP development
from the very beginning, I do not share your advice on this point.

spammers or marketing sender are professionnal while users most of the
time don't know nothing about SMTP

Whatever the new method to apply spammers and marketing sender are
reading RFC and will tune their system consenquently, this is a
question of months (as a matter of facts, I could already identified
some marketing senders who are sending 2 times their mail).
While small companies may need years to apply properly what is
described in RFCs.
SPF and DKIM are good examples. Excellent methods but after years lots
of small company don't even know it exists and many have false
configuration so it is still difficult to filter on it.

As mentionned in RFC 2635 section 6, we should Educate our "users
about how to react to spew and spewers" and "Support their efforts to
deal with unwanted mail at the local level" and this way, we may
expect "taking some of the burden from your system administrators."

I think the best way to "educate" them and to "support their efforts"
without overcrowded "system administrators" is to imply them more in
the process and give them way to explicitly declared what they want.
On this, spammers or marketing sender could do nothing. This is an
open issue which I want to discuss.

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

That's true, My first post was to share the general idea and get some
request, but following your remark I thought about it and in the case
of "defensive policy" described in my draft section 6.2.1, you will
find below a proposition on what could be implemented to require the
user choice.

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 directories 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 on how it could work (please paste
the scheme in a txt file):

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

Thank you very much for your time and your help.

Regards,
Hubert

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 May 2012 11:15:52 -0400

Addressing only one question:

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

Post a -00 version with the new name, then send email to
[email-masked], asking them to note in the tracker that
draft-hryckelynck-new-name replaces draft-hryckelynck-writing-rfcs.

Barry

---

From: SM <[email-masked]>
Date: Thu, 17 May 2012 16:40:56 -0700

Hi Hubert,
At 04:12 17-05-2012, hub ryck wrote:
>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 ?

Barry Leiba provided an explanation at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05884.html

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

I was trying to explain and you used it as suggested text.  :-)

>I could see that finding a way to get the user advice has been a 
>concern for others.

Ok.  I'll suggest that you get reviews from other people as it may 
help to refine the proposal.

>I was not sure of what you meant when you asked "What is my opinion".

I meant it "as what would conclude after reading the material".

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

The Style Guide at 
http://www.rfc-editor.org/rfc-style-guide/rfc-style explains how to 
determine whether a reference should be normative or informative.

>My opinion is that it is too bad "efforts to reconcile the two 
>approaches have failed".

No comment. :-)

>"draft-moonesamy-senderid-spf-conclusion-xx"

That draft will never be published.  I would not even recommend 
spending the time to read it.

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

It's going to be a lot of work to get this draft anywhere near 
consensus.  May I suggest that you contact the APPSAWG Chairs ( 
https://datatracker.ietf.org/wg/appsawg/charter/ ) to see whether 
there is any support for your proposal?  I'll consider your question 
if the WG Chairs determine that there is support.

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

:-)

>If we look now on what happen with IETF mailing list, my mail was 
>submitted to approbation.

That is because you are not subscribed to the mailing list ( 
https://www.ietf.org/mailman/listinfo/apps-discuss ).

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

I'll try and explain this in simple terms.  It may not be the correct 
explanation.  If there are several messages about a topic which the 
moderator of an IETF mailing list considers as unrelated to the topic 
being discussed on that mailing list, they will send you a message 
about the matter.  If you keep ignoring their kind advice, they can 
moderate the messages you send to the mailing list.

>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, ...).

It is more about whether there is consensus.

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

I suggest contacting the APPSAWG Chairs before getting into such an effort.

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

I saw Dave Crocker's message as it was posted to the 
[email-masked] mailing list.  Please see the suggested I made above.

Regards,
-sm