Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt

From: [email-masked]
Date: Tue, 26 Jun 2012 22:19:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the SPF Update Working Group of the IETF.

	Title           : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
	Author(s)       : Scott Kitterman
	Filename        : draft-ietf-spfbis-4408bis-01.txt
	Pages           : 54
	Date            : 2012-06-26

Abstract:
   E-mail on the Internet can be forged in a number of ways.  In
   particular, existing protocols place no restriction on what a sending
   host can use as the reverse-path of a message or the domain given on
   the SMTP HELO/EHLO commands.  This document describes version 1 of
   the Sender Policy Framework (SPF) protocol, whereby a domain can
   explicitly authorize the hosts that are allowed to use its domain
   name, and a receiving host can check such authorization.  This
   document obsoletes RFC4408.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-01

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 27 Jun 2012 01:22:23 -0400

Since there have been a fair number of changes already since the 00 draft and 
I'll be offline most of tomorrow, I wanted to leave you with the current state 
of the work to consider.  In addition to the updated draft, there's an rfcdiff 
at http://kitterman.com/spfbis/draft-ietf-spfbis-4408bis-01-from-0.diff.html.

I made a few minor changes beyond the ones discussed on the list.  Mostly to 
try to make idnits happier.

Scott K

On Tuesday, June 26, 2012 10:19:27 PM [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the SPF Update Working Group of
> the IETF.
> 
> 	Title           : Sender Policy Framework (SPF) for Authorizing Use of
> Domains in Email, Version 1 Author(s)       : Scott Kitterman
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Jun 2012 08:18:23 -0700

Small typo:

> 	This alternate, is not intended to save further queries, which MUST	
> 			be done according to RFC 2308, but to return a permanent negative	
> 			completion reply code to the client, instead of a transient one,	
> 			thereby shortening the queue time of messages that cannot be	
> 			accepted.

remove the first comma.

Howevever, for better readability and clarity, it would be a bit cleaner 
to break the sentence up, along the lines of:

    This alternative is intended to shorten the queue time of messages 
that cannot be accepted, by returning a permanent negative completion 
reply code to the client, instead of a transient one.  Saving queries is 
accomplished according to [RFC2308].

(side point:  there's no real need for a normative MUST here; it's not 
really specifying basic DNS behavior, but instead pointing to a spec 
that does.)

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: SM <[email-masked]>
Date: Wed, 27 Jun 2012 10:08:51 -0700

Hi Scott,
>of the work to consider.  In addition to the updated draft, there's an rfcdiff

I'll raise a few points to start the discussion.  Some of them might 
be outside the scope of the charter.  I suggest opening them as new 
issues if you consider it as appropriate.

In Section 2.5.5:

    'The domain owner wants to discourage the use of this host and thus
    desires limited feedback when a "softfail" result occurs.  For
    example, the recipient's Mail User Agent (MUA) could highlight the
    "softfail" status, or the receiving MTA could give the sender a
    message using a technique called "greylisting" whereby the MTA can
    issue an SMTP reply code of 451 (4.3.0 enhanced status code) with a
    note the first time the message is received, but accept it the second
    time.'

The SMTP reply code is incorrect.  It should be a 450.

In Section 5.0:

   "When any mechanism fetches host addresses to compare with <ip>, when
    <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
    address, AAAA records are fetched.  Even if the SMTP connection is
    via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
    2.5.5) MUST still be considered an IPv4 address and MUST be evaluated
    using IPv4 mechanisms (i.e. "ip4" and "a")."

The reference for RFC 3513 should be updated to RFC 4291.

In Section 5.4:

   'Note regarding implicit MXs: If the <target-name> has no MX records,
    check_host() MUST NOT pretend the target is its single MX, and MUST
    NOT default to an A lookup on the <target-name> directly.  This
    behavior breaks with the legacy "implicit MX" rule.  See [RFC5321],
    Section 5.  If such behavior is desired, the publisher should specify
    an "a" directive.'

This should also cover IPv6 as RFC 5321 kept the implicit MX rule.

Section 5.5 lists "ptr" as deprecated.  That's issue #27.  As a 
stylistic comment, this could be moved to an appendix.

In Section 8.1:

   "i p = the validated domain name of <ip> (deprecated)"

The should be p.

In Section 9.3:

   "Note that due to the 63-character limit for domain labels,
    this approach only works reliably if the localpart signature
    scheme is guaranteed either to only produce localparts with a
    maximum of 63 characters or to gracefully handle truncated
    localparts."

That should be 63-octet limit.  "63 characters" should be "63 octets".

Section 1.2 should be removed.  I suggest leaving Section 12.2 until 
the issue is resolved.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Wed, 27 Jun 2012 17:46:07 -0400

SM wrote:
> Hi Scott,
> I'll raise a few points to start the discussion.  Some of them might be 
> outside the scope of the charter.  I suggest opening them as new issues 
> if you consider it as appropriate.
> 
> In Section 2.5.5:
> 

Incorrect would be incorrect. If it was, than you would be suggesting 
a MUST I believe.  I agree the text can be cleaned up, perhaps also 
add examples of both should be provided. 451 is already in play 
(especially for non-extended-code SMTP deployments) and at the end of 
the (SPF WG) day, backward compatibility is more important.  Stating 
something (like this) as incorrect leads to (invites) throwing the 
SPF-BIS book at people who in my view, will take a while before they 
pencil in the time to update their wares with the presumption there is 
not going to be any breakage or labeling of non-compliance.

I just wanted to point out I am not expecting that the update to SPF 
to become a requirement nor becomes an venue to make existing SPF 
systems non-compliant.

-- 
HLS

---

From: SM <[email-masked]>
Date: Wed, 27 Jun 2012 16:24:37 -0700

Hi Hector,
At 14:46 27-06-2012, Hector Santos wrote:
>Incorrect would be incorrect. If it was, than you would be 
>suggesting a MUST I believe.

No, I only make suggestions.  As I mentioned previously, it's to 
start the discussion.  I don't have a strong opinion about the points raised.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 27 Jun 2012 20:01:56 -0400

> The reference for RFC 3513 should be updated to RFC 4291.

Agreed.  Done locally.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 27 Jun 2012 20:25:40 -0400

> This should also cover IPv6 as RFC 5321 kept the implicit MX rule.

Agreed.  I changed A to A or AAAA locally. I think that's sufficient.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 27 Jun 2012 20:32:57 -0400

> stylistic comment, this could be moved to an appendix.

We aren't removing this (that would be outside the scope of the charter, since 
it's in use.  I think moving it away from the rest of the text about mechanism 
just reduces understandability.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Jun 2012 17:49:19 -0700

On Wed, Jun 27, 2012 at 4:24 PM, SM <[email-masked]> wrote:

>> Incorrect would be incorrect. If it was, than you would be suggesting a
>> MUST I believe.
>>
>
> No, I only make suggestions.  As I mentioned previously, it's to start the
> discussion.  I don't have a strong opinion about the points raised.
>
>
I agree that 450 is the correct code, per RFC5321 Section 4.2.2.  We should
change it.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 27 Jun 2012 19:55:56 -0400

> The SMTP reply code is incorrect.  It should be a 450.

I disagree.  This is exemplary text and one could do that.  However, since we 
have a shiny new RFC about greylisting, it would probably be better to refer 
to it instead of trying to re-explain greylisting here.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 27 Jun 2012 21:47:19 -0400

But it won't reflect reality per its GREYLISTING mentioning.  In 
addition, the grub was the usage of incorrect - it is not incorrect to 
use any 45z temporary failure code - there are recommendations which 
MUST also consider the reality not all systems support extended-code 
responses.  Changing it is to add the recommendation for consistency, 
not to make any current system non-compliant.

Thanks

'Murray S. Kucherawy wrote:
> ------------------------------------------------------------------------
> 

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 00:01:12 -0400

> not to make any current system non-compliant.

It's not normative text.  No change to it can make something compliant or non-
compliant (whatever that means in these terms).

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 27 Jun 2012 22:17:17 -0700

Hello,

I'll comment to provide a perspective of what questions might be 
raised during reviews from outside the working group.  I have done 
that type of review for other drafts.  If the reviewer is diligent, 
he or she might raise the SMTP codes as an issue.  The argument that 
it can be done because it is "exemplary text" might not be strong 
enough unless it represents the view of a working group.  The 
interoperability argument is better as long as it can be explained clearly.

RFC 4408 has not been reviewed by the IETF.  I would only pass such a 
document to the Responsible Area Director with a disclaimer that it 
represents working group consensus.  My opinion is that there would 
be a number of issues raised during IESG Evaluation.  The working 
group will have to resolve those issues.  It will be more work for everyone.

Regards,
S. Moonesamy

---

From: Commerco WebMaster <[email-masked]>
Date: Wed, 27 Jun 2012 22:34:15 -0600

I tend to agree with your point of view on this issue.  But, when you 
think about it, 450 or 451 pretty much both describe an appropriate 
response to mail servers wanting to defer reception of a message.

RFC 821 describes 450 and 451 responses as follows:
450 Requested mail action not taken: mailbox unavailable
    [E.g., mailbox busy]
451 Requested action aborted: local error in processing

Thinking further about it, I think that 451 seems probably the better of 
the two, but both appear fine to use.  Though, if I were running a huge 
email server farm for a large client base, I'd probably want the 451 
used as it could be taken as a more systemic return from a receiver over 
the 450 return, which is clearly mailbox focused.  Polite senders 
probably would want to respect the 451 as systemic and back off on 
sending any other messages to that receiver which they might have to 
send when the receiver issues the 451.  That probably would make the 
grey listing routines on the receiver a bit happier (or minimally the 
network admin, as it also implies reduced traffic from junk retries by 
the sender until the greylist period on the receiver ends).

Also, as Scott K mentioned in another response, the new RFC regarding 
greylisting should probably become the place pointed to for the 
authoritative answer on the matter going forward.

Alan M.

On 6/27/2012 7:47 PM, Hector Santos wrote:
> responses. Changing it is to add the recommendation for consistency, not
> to make any current system non-compliant.
>
> Thanks
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jun 2012 07:09:55 -0700

On Wed, Jun 27, 2012 at 10:17 PM, S Moonesamy <[email-masked]> wrote:

> I'll comment to provide a perspective of what questions might be raised
> during reviews from outside the working group.  I have done that type of
> review for other drafts.  If the reviewer is diligent, he or she might
> raise the SMTP codes as an issue.  The argument that it can be done because
> it is "exemplary text" might not be strong enough unless it represents the
> view of a working group.  The interoperability argument is better as long
> as it can be explained clearly.
>

The working group should expect and welcome those reviews, as they only
strengthen our position once we consider the feedback they provide.  I
would even seek some of them out.  Without those reviews, the IESG would be
within their rights to ask more questions.  We always have a stronger
position if we can show that the document has had more broad review than if
it has not.

> represents working group consensus.  My opinion is that there would be a
> number of issues raised during IESG Evaluation.  The working group will
> have to resolve those issues.  It will be more work for everyone.
>
>
That's not a disclaimer, it's a requirement.  We can't send documents from
working groups to the IESG that don't have at least rough consensus.  The
stronger that consensus is, and the more it's clear we've done due
diligence on all major points in the document, the easier the ride is
through IESG evaluation.  Thus, we should resolve those issues before they
get to the IESG, not after.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jun 2012 07:17:58 -0700

> 451 Requested action aborted: local error in processing

RFC5321 is the current SMTP specification.

Operationally, I'm sure they're identical.  But by the specs, 451 is
wrong.  An SPF failure or a decision to grey list result in policy actions,
not local errors.

The greylisting RFC (RFC6647) also recommends 450 if the MTA is not going
to drop the connection.

I think the idea that people have implemented an expectation of 451 to mean
"SPF failure" would be a hack, because (a) it's wrong and (b) does anyone
actually look at the third digit, much less the second?  (Except maybe
passing the whole thing to atoi(), and then checking if it's between 400
and 499.)  We don't need to write RFCs to support things like that.

Or are we saying that people actually treat 451 specially?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 11:22:35 -0400

> Or are we saying that people actually treat 451 specially?

I don't think they do and I agree that if they do, they are wrong.  Since RFC 
6647 already tells us which color to paint the bikeshed, here's the change I'm 
made locally.  Are there objections:

    example, the recipient's Mail User Agent (MUA) could highlight the
    "softfail" status, or the receiving MTA could give the sender a
-   message using a technique called "greylisting" whereby the MTA can
-   issue an SMTP reply code of 451 (4.3.0 enhanced status code) with a
-   note the first time the message is received, but accept it the second
-   time.
+   message using greylisting, [RFC6647], with a note the first time
+   the message is received, but accept it the second time.

Scott K

---

From: Commerco WebMaster <[email-masked]>
Date: Thu, 28 Jun 2012 10:29:46 -0600

On 6/28/2012 8:17 AM, Murray S. Kucherawy wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I tend to agree with your point of view on this issue.  But, when
>     you think about it, 450 or 451 pretty much both describe an
>     appropriate response to mail servers wanting to defer reception of a
>     message.
>

True, but I only referred to 821 because it was the base for SMTP and 
over the many years I have observed these working group lists, most all 
of them desire to maintain interoperability with the older RFCs.  Thus, 
my leap back to the very beginning.

RFC 5321 describes 450 and 451 responses as follows:
    450  Requested mail action not taken: mailbox unavailable (e.g.,
       mailbox busy or temporarily blocked for policy reasons)
    451  Requested action aborted: local error in processing

> wrong.  An SPF failure or a decision to grey list result in policy
> actions, not local errors.
>
> The greylisting RFC (RFC6647) also recommends 450 if the MTA is not
> going to drop the connection.
>
> I think the idea that people have implemented an expectation of 451 to
> mean "SPF failure" would be a hack, because (a) it's wrong and (b) does
> anyone actually look at the third digit, much less the second?  (Except
> maybe passing the whole thing to atoi(), and then checking if it's
> between 400 and 499.)  We don't need to write RFCs to support things
> like that.
>

I would also agree that a percentage (perhaps a large percentage) of 
folks may not code to the third digit to address greylisting, but that 
said, I don't know that to be true.  Perhaps I am a bit weird that way, 
but I do look at each send and return as specified in an RFC as discrete 
and different events in anything I code to work with an RFC described 
protocol.  I also depend upon backward compatibility within the same 
protocol.

My point, however, was that a systemic response, rather than a per box 
response, arguably might make it easier on the receivers.  Bottom line, 
I am entirely neutral on what 45x error is used.  RFC 6647 recommends 
450?  So be it (although I think that point requiring the MTA not 
dropping the connection could lead to some foreseeable resource [dos] 
style attacks by forcing a receiver to keep sockets open).

Alan M.

---

From: Commerco WebMaster <[email-masked]>
Date: Thu, 28 Jun 2012 10:44:13 -0600

> +   the message is received, but accept it the second time.

Existing greylisting implementations differ.  Given that reality, I'm 
not sure that one can demand the server arbitrarily accept the message 
the second time it is sent.  That strategy could be abused in 
foreseeable ways, thus effectively defeating the purpose of greylisting. 
  Rather I would submit employing the logic implied in regular mail 
delivery:

Attempt, fail, back off some period of time.

Reattempt, fail, back off some larger period of time.

Reattempt as in the prior step until either the send attempts maximum 
value of the sender applies or the message is delivered.

Perhaps this more vague wording which allows the receiver more latitude 
might suffice:
+   message using greylisting, [RFC6647], with a note when
+   the message is received, but accept on a later attempt
+   as defined by the receiver.

Alan M.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 12:48:38 -0400

On Thursday, June 28, 2012 10:44:13 AM Commerco WebMaster wrote:
> >> mean
> > I don't think they do and I agree that if they do, they are wrong.  Since
> > RFC 6647 already tells us which color to paint the bikeshed, here's the
> > change I'm> 

Keep in mind this is an example.  It's totally non-normative. I'm fine either 
way, but I don't think it merits a lot of discussion.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 14:14:50 -0400

> +   as defined by the receiver.

Done, slightly differently as:

            with a note the first time the message is received, but accept it
            on a later attempt based on receiver policy.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jun 2012 11:26:34 -0700

On Thu, Jun 28, 2012 at 9:44 AM, Commerco WebMaster
<[email-masked]>wrote:

>
>
> Existing greylisting implementations differ.  Given that reality, I'm not
> sure that one can demand the server arbitrarily accept the message the
> second time it is sent.  That strategy could be abused in foreseeable ways,
> thus effectively defeating the purpose of greylisting.  Rather I would
> submit employing the logic implied in regular mail delivery:
>
RFC6647 is an Applicability Statement, which bascially means it's a
consensus statement about how to achieve a particular capability based on a
technical specification.  In this case, it's basically "How to use SMTP to
implement greylisting."  That doesn't mean variations are not allowed; it's
merely a consensus statement.

I imagine, though, that we're drifting from RFC4408bis quite a bit here.
The right place to discuss this further might be ietf-smtp or apps-discuss.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 16:49:14 -0400

On Thursday, June 28, 2012 11:27:11 AM S Moonesamy wrote:
> Hi Scott,
> 
> At 09:48 28-06-2012, Scott Kitterman wrote:
> >Keep in mind this is an example.  It's totally non-normative. I'm fine
> >either way, but I don't think it merits a lot of discussion.
> 
> The text is part of the specification.  If it was raised as an issue
> after ample discussion, we might be able to get away by saying that
> it is non-normative.  There hasn't be much discussion.  There can be
> a DISCUSS on this and it will block publication of the document.
> 
> The current level of review is quite low.  A document editor also has
> to identify the issues and propose a resolution.  If there isn't
> ample discussion we end up with text which doesn't really address the
> issues.

The issue raised was using 451 instead of 450.  I resolved that by referring 
to RFC6647 instead of specifying it. so I believe that issue is resolved 
locally and will be in -02spfb.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Thu, 28 Jun 2012 16:23:02 -0700

Hi Scott,
>locally and will be in -02spfb.

Could you please post the text changes you plan to make for the issue 
mentioned above?  The message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01667.html has 
a diff for Section 2.5.5 only.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 28 Jun 2012 23:26:18 -0400

On Thursday, June 28, 2012 04:23:02 PM S Moonesamy wrote:
> >The issue raised was using 451 instead of 450.  I resolved that by
> >referring to RFC6647 instead of specifying it. so I believe that issue is
> >resolved locally and will be in -02spfb.
> 

The issue was only posed in reference to 2.5.5.  I have:

             The domain owner wants to discourage the use of this host and
             thus desires limited feedback when a "softfail" result occurs.
             For example, the recipient's Mail User Agent (MUA) could
-            highlight the "SoftFail" status, or the receiving MTA could give
-            the sender a message using a technique called "greylisting"
-            whereby the MTA can issue an SMTP reply code of 451 (4.3.0 DSN
-            code) with a note the first time the message is received, but
-            accept it the second time.
+            highlight the "softfail" status, or the receiving MTA could give
+            the sender a message using greylisting, <xref target="RFC6647"/>,
+            with a note the first time the message is received, but accept it
+            on a later attempt based on receiver policy.

Are there other places you think it should be changed?

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 29 Jun 2012 00:06:40 -0700

>+            on a later attempt based on receiver policy.

Thanks.

>Are there other places you think it should be changed?

As we are going over the SMTP reply codes and the extended status 
codes, here's are the occurrences in the draft:

In Section 2.5.4:

   "If the checking software chooses to reject the mail during the SMTP
    transaction, then it SHOULD use an SMTP reply code of 550 (see
    [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see
    [RFC3463]), in addition to an appropriate reply text."

For Section 2.5.5, see quoted text above.

In Section 2.5.6:

   "If the message is rejected during the SMTP transaction for this
    reason, the software SHOULD use an SMTP reply code of 451 and,
    if supported, the 4.4.3 enhanced status code."

In Section 2.5.7:

  "If the message is rejected during the SMTP transaction for this
   reason, the software SHOULD use an SMTP reply code of 550 and, if
   supported, the 5.5.2 enhanced status code."

I suggest that the working group reviews and comments on all the occurrences.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Jun 2012 14:14:31 +0200

>> +            on a later attempt based on receiver policy.

I like that change.

>    [RFC3463]), in addition to an appropriate reply text."

SMTP defines 550 for policy reasons, while 5.7.1 bears a slightly
different meaning in RFC 5248.  How about defining SPF entries in
http://www.iana.org/assignments/smtp-enhanced-status-codes/ ?

>    if supported, the 4.4.3 enhanced status code."

451 implies a local malfunction, it is probably inappropriate for
timeouts that originate from remote misconfiguration or similar
issues.  Previous question about enhanced codes applies here too.

> I suggest that the working group reviews and comments on all the

Since SMTP is very clear about 550, we could just refer to it, as we
did for greylisting.  If we define SPF enhanced codes, they would have
to go to the I-D's IANA Section.  That way, we could avoid cluttering
those definitions with operational considerations.

Personally, I hate that wording "If the message is rejected", as it is
an indirect way to insinuate that it could make sense to devise a
conforming policy, without ever taking the responsibility of telling
how to behave in order to get what results.

Much of SPF folklore hinges on rejecting messages in order to refrain
abuse of domain names.  However, the domains that deploy such behavior
seem to be <2%.  Hence, if we are consistent with what we did with
RRTYPEs, we could as well avoid to standardize unqualified suggestions.

Why don't we talk about that in Vancouver?

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 29 Jun 2012 09:36:23 -0400

> On Fri 29/Jun/2012 09:06:40 +0200 S Moonesamy wrote:
...
> http://www.iana.org/assignments/smtp-enhanced-status-codes/ ?

It's true that 5.7.1 is different, but the enhanced status codes have more 
detail in them (that's why the are enhanced).  Being different is to be 
expected.  

>From RFC 5321 Section 4.2.2:

550  Requested action not taken: mailbox unavailable (e.g., mailbox
      not found, no access, or command rejected for policy reasons)

>From RFC 3463 section 3.8:

      X.7.1   Delivery not authorized, message refused

         The sender is not authorized to send to the destination.  This
         can be the result of per-host or per-recipient filtering.  This
         memo does not discuss the merits of any such filtering, but
         provides a mechanism to report such.  This is useful only as a
         permanent error.

I think these are sufficiently consistent and there is no evidence that I recall 
being discussed in the working group from these codes that they should be left 
unchanged.  In general, receivers are reluctant to get into detail about why 
the accept or reject messages for fear that senders will use the information 
to game the system.  I don't think defining additional status codes for SPF is 
necessary, within the scope of the charter, or likely to get much deployment.

It is also completely unnecessary to define a new status code to let senders 
know that this is an SPF related rejection (or deferral).  This is precisely 
what the exp= modifier is for.  If you look at the last example in Section 6.2 
or RFC 4408 (the one with why.html in it) you'll find that is actually 
supported by a web service of openspf.org:

http://www.openspf.org/Why

Exp= can convey far more information than a status code.

> issues.  Previous question about enhanced codes applies here too.

No.  It doesn't.  RFC 5321 Section 4.2.2 says:

451  Requested action aborted: error in processing

It says there's an error.  It says nothing about where or why.  Reviewing that 
section, I certainly don't see a better one.

For the enhanced status code, RFC 3463 Section 3.5:

      X.4.3   Directory server failure

         The network system was unable to forward the message, because a
         directory server was unavailable.  This is useful only as a
         persistent transient error.

         The inability to connect to an Internet DNS server is one
         example of the directory server failure error.

Given that temperrors are all DNS errors of some kind, I think this is 
reasonable.  Rather than repeat myself, I'll point to the comment about that 
there's nothing broken here to fix.

> those definitions with operational considerations.

I'm not sure what you're suggesting about 550.  Please provide text so I can 
better understand your point.

I think defining new codes is out of scope as discussed above.

> how to behave in order to get what results.

We were very careful to avoid defining receiver policy in RFC 4408 (Section 
2.5.2 is the only exception to that).  Given that decision, "If the message is 
rejected ..." is a perfectly reasonable way to describe how to approach a 
given receiver policy if a receiver chooses to select that policy.

I did not sense much traction from the group with the idea that we should 
define receiver policy in 4408bis.  Even if the group did favor it, I think 
that it would be out of scope for the current charter.

> RRTYPEs, we could as well avoid to standardize unqualified suggestions.

I think the SPF RR Type is completely orthogonal to this discussion.  Having 
consistency in how one does rejection has a value for interoperability so it's 
reasonable to specify it.  It's not folklore.  It is more suitable for some 
domains than others.  A lot of small domains do it.  I've distributed software 
for about half a decade configured to reject by default and never gotten a 
complaint about it (I did get complaints about defer on temperror by default, 
so I've got experience that says when my defaults cause people problems, I'll 
find out).  In the scheme of Internet mail volumes they may not add up to a 
large percentage, but they do exist.

For larger organizations getting SPF deployment right is hard, both for 
senders and receivers.  There are ongoing developments that will make it 
easier to do this, but I'm not surprised large organizations don't reject.

> Why don't we talk about that in Vancouver?

I don't think there's anything to discuss.

Scott K