Subject: Re: [spfbis] #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections

From: S Moonesamy <[email-masked]>
Date: Mon, 25 Jun 2012 16:06:49 -0700

At 08:10 21-02-2012, spfbis issue tracker wrote:
>#18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for 
>optional PermError
>rejections

This is the current text in Section 2.5.7 of draft-ietf-spfbis-4408bis-00:

    A "permerror" result means that the domain's published records could
    not be correctly interpreted.  This signals an error condition that
    requires manual intervention to be resolved, as opposed to the
    temperror result.  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 DSN code.  Be aware that if
    the domain owner uses macros (Section 8), it is possible that this
    result is due to the checked identities having an unexpected format.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Jun 2012 20:22:49 -0700

On Mon, Jun 25, 2012 at 4:06 PM, S Moonesamy <[email-masked]> wrote:

>> #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional
>> PermError
>> rejections
>>
>
Just curious: What's the logic behind using a permanent error on an SPF
record interpretation failure?  Isn't this the kind of situation in which a
tempfail makes more sense, allowing the publishing domain an opportunity to
fix a broken record?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Jun 2012 23:37:19 -0400

> tempfail makes more sense, allowing the publishing domain an opportunity to

temperror is for transient problems that will fix on their own.  permerror's 
need operator intervention to fix.  If receivers reject on permerror then the 
receiver is more inclined to notice (I'm not claiming this is a common 
practice, just giving the theory) than they would if a message was delayed.  
Eventually deferred meesages time out of the queue anyway, so temperrors 
eventually turn into rejects anyway.

Scott K

---

From: SM <[email-masked]>
Date: Mon, 25 Jun 2012 23:15:59 -0700

The text mentions "DSN code".  There is a previous reference to RFC 
3464.  The usage of "DSN" is incorrect as the code is being generated 
during a SMTP session.   The appropriate reference is RFC 3463 and 
it's an "enhanced status code".

A question which came to my mind as I read the text is why is a "SHOULD" used.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Jun 2012 09:27:15 -0400

> it's an "enhanced status code".

Fixed.  In section 10.5, Untrusted Information Sources, there is reference to 
DSN as well.  Should that be changed to something else and if not should we 
still have a reference to RFC 3464 (and add it there)?

> A question which came to my mind as I read the text is why is a "SHOULD"

Common use of status codes (normal and enhanced) promotes interoperability by 
making the source of email rejection/deferral more understandable to the 
sender trying to figure out why something failed, so this is something that 
implementations SHOULD do.  I don't think MUST is appropriate since it's to 
support forensics and not normal operation (consistency in SPF results is a 
MUST, but not what status code is sent along with it).

Scott K

---

From: SM <[email-masked]>
Date: Tue, 26 Jun 2012 09:28:09 -0700

Hi Scott,
>still have a reference to RFC 3464 (and add it there)?

DSNs are used for notifications such as failed delivery, delayed 
delivery or successful delivery.  Section 10.5 seems to be about 
"bounces".  You could use the term "bounce".  If we reference RFC 
3464, it would require EHLO and the relevant SMTP extension.  I would 
pick the easy fix unless anyone feels strongly about this.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Jun 2012 15:03:53 -0400

On Tuesday, June 26, 2012 09:28:09 AM SM wrote:
> >Fixed.  In section 10.5, Untrusted Information Sources, there is reference
> >to DSN as well.  Should that be changed to something else and if not
> >should we still have a reference to RFC 3464 (and add it there)?
> 

Thanks.  Changed to bounce locally.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Jun 2012 13:15:46 -0700

On Tue, Jun 26, 2012 at 9:28 AM, SM <[email-masked]> wrote:

> DSNs are used for notifications such as failed delivery, delayed delivery
> or successful delivery.  Section 10.5 seems to be about "bounces".  You
> could use the term "bounce".  If we reference RFC 3464, it would require
> EHLO and the relevant SMTP extension.  I would pick the easy fix unless
> anyone feels strongly about this.
>
>
Section 2.5.4 already references RFC3464. I don't think we actually define
"bounce" in either document, so I suggest we use "bounce" but
parenthetically define it as a DSN with an Action value of "failed".

Interestingly, even RFC5598 avoids defining "bounce".

-MSK

---

From: "John Levine" <[email-masked]>
Date: 26 Jun 2012 20:59:16 -0000

>parenthetically define it as a DSN with an Action value of "failed".

I see a couple of references to bounce address, two uses in sec 9.3
on page 37 where it's confusingly used to mean forwarded, and in
9.5 where it means a nondelivery notice.

I'd be OK using a DSN as an example of a bounce message, but
there are still plenty of MTAs that send bounce messages that
aren't NDN.  Since it's only that one place, how about taking
out the word bounce change "rather than bounced" to "rather
than sending a failure report."

And please rewrite it out of section 9.3:

OLD:
           This means that mail
           bounced from the external mailbox will have to be re-bounced
           by the forwarding service.

NEW:
           This means that mail
           forwarded from the external mailbox will have to be remailed
           by the forwarding service.
R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Jun 2012 17:28:51 -0400

> parenthetically define it as a DSN with an Action value of "failed".

I switched this to RFC3463 already based on SM's comment.  I'm taking John's 
suggested approach of avoiding the word and we can revisit if needed after I 
publish the next update.

> Interestingly, even RFC5598 avoids defining "bounce".

All the more reason not to try and do it here.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Jun 2012 17:35:55 -0400

>            by the forwarding service.

I removed it from both locally.  The term bounce also appears in section 10.5 
(several times).  If someone wants to take a shot at rewriting that, I'd 
appreciate it.

Scott K

---

From: SM <[email-masked]>
Date: Tue, 26 Jun 2012 15:29:03 -0700

Hi Scott,
>(several times).  If someone wants to take a shot at rewriting that, I'd

Please not that I do not have a strong opinion about this.

The last paragraph of Section 10.5 has:

   "As long as the DSN is not redirected to someone other than the
    actual sender, the only people who see malicious explanation
    strings are people whose messages claim to be from domains that
    publish such strings in their SPF records.  In practice, DSNs can
    be misdirected, such as when an MTA accepts an E-Mail and then
    later generates a DSN to a forged address, or when an E-Mail
    forwarder does not direct the DSN back to the original sender."

Suggested text as a starting point (it needs editing):

   As long as messages are only bounced (returned with non-delivery 
notification)
   to domains which publish malicious explanation strings in their 
SPF records,
   the only people affected are those associated with those 
domains.  In practice,
   bounces can be misdirected to a forged email address or when a 
mail forwarder
   does not generate a bounce for the original sender.

Regards,
-sm

---

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

On Tuesday, June 26, 2012 03:29:03 PM SM wrote:
> >I removed it from both locally.  The term bounce also appears in section
> >10.5 (several times).  If someone wants to take a shot at rewriting that,
> >I'd appreciate it.
> 

Thanks.  I updated this section based in part on your input and an input I 
received offlist.

Scott K