spf-discuss
[Top] [All Lists]

Re: Suggesting SMTP and DSN codes in case receiver chooses to reject on TempError and PermError

2005-06-06 12:29:43
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Summary:  We should treat the resolution as if its last sentence said "may" 
instead of "shall".

Wayne Schlitt wrote:
23:00 <Julian> Motion: No receiver policy shall be formally suggested
               (MAY), recommended (SHOULD), or prescribed (MUST) in the
               definitions of the "TempError" and "PermError" result
               codes. In particular, those result codes' definitions
               shall not explicitly suggest a treatment similar to any
               other result codes. However, formal recommendations for
               the choice of SMTP reply codes shall be included.

So, a strict reading of this says that SMTP reply codes for PermError
shall be included.

Exactly, this is what I meant when I worded the motion.  I do think that 
rejecting on PermError is the right thing to do, but making the PermError 
definition explicitly saying this was _not_ the _intent_ of that motion, 
even if it is unquestionably its _effect_.

In order to understand what the intent of the motion was, I think one must 
read these parts of the chat session:

22:35   <Julian>        3 - Receivers may treat PermError like FAIL, and 
TempError
22:35   <Julian>        like SOFTFAIL, SMTP offers error codes 5xx and 4xx resp.
...
22:38   <grumpy>        Ok, so the first part of Frank's point 3 has been 
already
                  decided.
22:39   <Julian>        grumpy: Right.
22:39   <grumpy>        The second part is that TempError and SoftFail should 
get
                   4xx SMTP codes?
22:40   <grumpy>        I agree with TempError, but certainly not SoftFail.
22:40   <Julian>        We definitely shouldn't RECOMMEND or REQUIRE that.
22:40   <MarkK> certainly not softfail, no
22:40   <MarkK> that is really receiver policy
22:40   <Julian>        Also, I don't think we should "SUGGEST" it, but we might
                  "suggest" TempError --> 4xx.
22:41   <Julian>        It _might_ not be obvious to do 4xx on TempError.
...
22:47   <grumpy>        [So,] do we need to vote on this?
22:48   <Julian>        Do we want a motion confirming the current wording?
22:48   <Julian>        I'll word one...
22:48   <Julian>        (to satisfy Frank's third review request)
...
22:54   <Julian>        Motion: No receiver policy shall be formally suggested
                  (MAY), recommended (SHOULD), or prescribed (MUST) in the
                  definitions of the "TempError" and "PermError" result
                  codes. In particular, those result codes' definitions
                  shall not explicitly suggest a treatment similar to any
                  other result codes.
22:55   <Julian>        (I fear this is not entirely compatible with "if ... 
SHOULD
                  use an SMTP reply code of 451", though... Ugh.)
22:56   <Julian>        (Any suggestions on how to make an exception for these 
SMTP
                  reply code recommendations in the above motion?)
...
22:59   <Julian>        Ok, one more try:
23:00   <Julian>        Motion: No receiver policy shall be formally suggested
                  (MAY), recommended (SHOULD), or prescribed (MUST) in the
                  definitions of the "TempError" and "PermError" result
                  codes. In particular, those result codes' definitions
                  shall not explicitly suggest a treatment similar to any
                  other result codes. However, formal recommendations for
                  the choice of SMTP reply codes shall be included.
23:00   <Julian>        (I added the last sentence.)

So the intent of the motion was to confirm the wording as of -02pre2 with 
regard to not specifying receiver policy in the definitions of TempError 
and PermError.  This is what the first two sentences of the motion are 
about.  However, I didn't want to remove the recommendation of SMTP reply 
and DSN codes from the definition of TempError, so I added the last 
sentence.

Unfortunately, I made a small mistake by saying "shall" instead of "may" in 
that last sentence.  Nobody noticed this mistake.

[...]
So, what is in the draft remains unchanged.  This may not be the
letter of the motion, but it appears to me to be the intent.
[...]
So, unless the other SPF council members object, I am going to assume
that Julian just wasn't as clear in the wording of his motion as he
intended to be.

Right.  We should treat the resolution as if its last sentence said "may" 
instead of "shall".  Any council member who objects to this should raise 
their voice ASAP.

Julian,
SPF Council Member.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCpKQnwL7PKlBZWjsRAlO1AJ944eJSosJk/y/quaqng0e8tR1sOQCfX9aP
JB4zOkuRmg/3GV5N+a0i5DY=
=fWrl
-----END PGP SIGNATURE-----