Subject: [spfbis] Rejecting mail on SPF Fail as a requirement

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Aug 2012 14:13:24 -0700

Hello,

There has been a lot of discussion about rejecting mail on SPF 
Fail.  I read RFC 4408.  Quoting from Section 2.5.4:

   "The checking software can choose to mark the mail based on this or
    to reject the mail outright."

It is my understanding that the choice is left to the software in the 
above text.

   "If the checking software chooses to reject the mail during the SMTP
    transaction, then it SHOULD use an SMTP reply code of 550 (see
    [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
    (DSN) code (see [RFC3464]), in addition to an appropriate reply text."

The normative text quoted above states what the software should do if 
it chooses to reject the mail.  I could not find any normative text 
that states that mail SHOULD or MUST be rejected on SPF Fail.

I strongly suggest not to pursue further discussion about rejecting 
mail on SPF Fail as a requirement.  Please post a message to the 
SPFBIS mailing list if you have any objection to the above.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 20:10:26 -0400

S Moonesamy wrote:

> I strongly suggest not to pursue further discussion about rejecting mail 
> on SPF Fail as a requirement.  Please post a message to the SPFBIS 
> mailing list if you have any objection to the above.

No one has ever stated that Rejecting Mail on Fail was a requirement. 
However, it is part of the protocol for implementation to design 
software for to satisfy section 2.5.4 and section 2.3:

See RFC4408 section 2.3

    2.3.  Publishing Authorization

    An SPF-compliant domain MUST publish a valid SPF record as described
    in Section 3.  This record authorizes the use of the domain name in
    the "HELO" and "MAIL FROM" identities by the MTAs it specifies.

    If domain owners choose to publish SPF records, it is RECOMMENDED
    that they end in "-all", or redirect to other records that do, so
    that a definitive determination of authorization can be made.

This is important and can be read many ways!  Now, lets look at the 
pertinent rev 06 changes:

    2.3.  Publishing Authorization

    ...

    SPF results can be used to make both positive (source is authorized)
    and negative (source is not authorized) determinations.  If domain
    owners choose to publish SPF records and want to support receivers
    making negative authorization determinations, then they MUST publish
    records that end in "-all", or redirect to other records that do,
    otherwise, no definitive determination of authorization can be made.

Some can reasonable state this makes the argument stronger for the 
PROTOCOL for rejection or classifying mail in a negative way IFF when 
the DOMAIN publish a strong policy using -ALL.

But no one has ever stated that REJECTING was a requirement. Section 
2.5.4, as you point out, clearly makes that point.  There are two 
"can" options:

   - REJECT
   - ACCEPT WITH MARKING (Receiver-SPF, see section 7)

However, in fact, by RFC4408 section 7, a 3rd option is available:

   - ACCEPT WITH NO MARKING

Since adding a Receiver-SPF is an recommendation but not a MUST.

Yet, the advocates who have decided to reinforce the idea of 
ACCEPT+MARKING in the name of reporting and feeding unknown advanced 
message eval systems, a valid concept, need to also be aware there are 
repercussions with an ACCEPT+MARKING that are not negatively handled 
as RFC4408 section 2.3 states and in rev-06 makes it more clear.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Aug 2012 17:33:32 -0700

Hi Hector,
At 17:10 24-08-2012, Hector Santos wrote:
>No one has ever stated that Rejecting Mail on Fail was a 
>requirement. However, it is part of the protocol for implementation 
>to design software for to satisfy section 2.5.4 and section 2.3:
>
>See RFC4408 section 2.3
>

I could not find any normative text that states that mail SHOULD or 
MUST be rejected on SPF Fail in the text quoted above.

Is this an objection to message posted at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html ?

>message eval systems, a valid concept, need to also be aware there 
>are repercussions with an ACCEPT+MARKING that are not negatively 
>handled as RFC4408 section 2.3 states and in rev-06 makes it more clear.

With all due respect, the message I posted at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html was 
about rejecting mail on SPF Fail as a requirement.  It is not related 
to "accept with marking" or accept with no marking".

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 20:45:55 -0400

S Moonesamy wrote:

> about rejecting mail on SPF Fail as a requirement.  It is not related to 
> "accept with marking" or accept with no marking".

What other options does an implementator have to offer deployments?

Based on my reading on RFC 4408 (and still with rev-6), there are 
three option in the technical programming extracted from functional 
specification:

Per Section 2.5.4
   - Reject
   - Accept, Add Receiver-SPF (and/or Auth-Res with rev-6)
Per Section 7
   - Accept, do not add Receiver-SPF or Auth-Res

The point is that there was never a requirement for Rejecting on SPF 
Fail. It was just one of the options for handling a -ALL.  The 
semantics are provided in Section 2.5.4 and in 2.3.  The domain is 
providing a "HINT" to the receiver on how to handle the mail and in 
the case of -ALL policies, it is shooting for a negative 
classification. That could be rejection or accept+marking per section 
2.5.4

What I am missing here?

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Aug 2012 18:00:10 -0700

>What other options does an implementator have to offer deployments?

The message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html was 
not about discussing options.  Rejecting mail on SPF Fail as a 
requirement is outside the scope of the SPFBIS WG Charter ( 
https://datatracker.ietf.org/wg/spfbis/charter/ ).

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 21:16:39 -0400

> https://datatracker.ietf.org/wg/spfbis/charter/ ).

SM,

There was a note for any objection to be posted:

    Please post a message to the SPFBIS mailing list if you
    have any objection to the above.

I was not objecting. I was basically pointing out it is a moot point, 
never was an exclusive requirement and I don't know where it started 
or anyone getting the idea that is was the only exclusive requirement.

I might have stated that for a specific implementation, Rejecting on 
SPF fail may be their only feasible, practical and most protocol 
secured method of operation that will both follow and spirit and 
intent of an -ALL policy. The DOMAIN will not complain for a reject 
and it will not be in violation of the protocol specification by no means.

But as an exclusive mode of operation?  Of course not, so I am not 
sure why we are going there with this.  Just trying to understand why 
the hammer is coming down.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Fri, 24 Aug 2012 18:54:11 -0700

Hi Hector,
At 18:16 24-08-2012, Hector Santos wrote:
>I was not objecting. I was basically pointing out it is a moot 
>point, never was an exclusive requirement and I don't know where it 
>started or anyone getting the idea that is was the only exclusive requirement.

I'll quote the entire paragraph:

   "I strongly suggest not to pursue further discussion about rejecting
    mail on SPF Fail as a requirement. Please post a message to the"
    SPFBIS mailing list if you have any objection to the above."

I don't see any reason to pursue the discussion as there isn't any objection.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 25 Aug 2012 13:09:49 +0200

Hi SM, WG, chairs,

> SPFBIS mailing list if you have any objection to the above.

It is obviously ridiculous to state that SPF is not concerned with the
possibility to reject mail.  IMHO, it is an hysterical second best to
consider receiver policies as casually related to SPF, rather than an
integral part of it.  The acrobatics that the RFC 4408 exhibits,
albeit valuable, seem to be a consequence of the MARID climate.

Have we cooled down?  Then let's put a MAY or whatever, for the sake
of a clearer spec.  OTOH, if we're still unable to discuss this
subject constructively, I accept SM's suggestion as quoted above.  In
the latter case, however, I'd appreciate if the reasons to ban such
discussions are explained in more depth:  Such analysis may also be
useful whenever further work on SPF will be taken into consideration.

---

From: S Moonesamy <[email-masked]>
Date: Sat, 25 Aug 2012 09:37:08 -0700

Hi Alessandro,
>albeit valuable, seem to be a consequence of the MARID climate.

I gather that the above is an objection to the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html  I 
mentioned in that message that I could not find any normative text 
that states that mail SHOULD or MUST be rejected on SPF Fail.  I do 
not see any arguments in the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02344.html 
about normative text that states that mail SHOULD or MUST be rejected 
on SPF Fail.

I do not have any opinion about whether RFC 4408 exhibits any 
acrobatics or what might have caused that.  I read both RFC 4408 and 
draft-ietf-spfbis-4408bis.  If I notice a change, I find out whether 
it is according to what is in the SPFBIS Charter ( 
https://datatracker.ietf.org/wg/spfbis/charter/ ).  Whether I like 
the change or not is immaterial.  My task is to see that the WG 
deliverable is completed according to the guidance I received.

>useful whenever further work on SPF will be taken into consideration.

I consider any addition of a MAY, SHOULD or MUST as a substantive 
change as such a change can have an impact on existing 
implementations.  The "for the sake of a clearer spec" is not one of 
the better arguments in my opinion.

In a moderator note dated April 20, 2012, Andrew Sullivan mentioned 
that the topic of "reject on fail" was closed ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01340.html 
).  A quick glance through the archives will show that the topic 
resurfaced.  A thorough read of the archives will show that there 
hasn't been any new arguments.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Stuart Gathman <[email-masked]>
Date: Sat, 25 Aug 2012 21:16:22 -0400

> https://datatracker.ietf.org/wg/spfbis/charter/ ).
I don't think we really care whether mail with SPF Fail is rejected or 
not.  I think what we are looking for is something along the lines of, 
"Don't blame (alleged) sender".  I.e. whatever the recipient does with 
the email, any reputation should not accrue to the MAIL FROM, and no 
emails should be sent to abuse@mailfromdomain.  No DSNs or other bounces 
should be sent to the alleged MAIL FROM.  The no bounces part is 
actually the original motivation for SPF.  The rejecting, not so much.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Aug 2012 12:32:52 +0200

On Sat 25/Aug/2012 18:37:08 +0200 S Moonesamy wrote:
> https://datatracker.ietf.org/wg/spfbis/charter/ ).  Whether I like the
> change or not is immaterial.  My task is to see that the WG

Hi SM,

I appreciate the work that you're doing for the IETF in general, and I
thank you for co-chairing this WG in particular.  However, I object to
the excess of aseptic formalism that at times you seem to entrench
yourself within.  How come you have no opinion?  Why wouldn't it
matter whether you like something or not?  I'm happy of your openness
and respect, but would prefer you making use of your personal taste
and skills, rather than abstain.  After all, this is a WG, not a High
Court...

> the better arguments in my opinion.

About changes in the I-D, IMHO the "clarifying language" that the
charter mentions includes such things as adding or removing any 2119
terms as we see fit, as long as doing so doesn't invalidate existing
implementations and deployments.  In that respect, the only change up
to date is to remove the SPF RR type, and I don't think there will be
more.

> http://www.ietf.org/mail-archive/web/spfbis/current/msg01340.html ). 
> A quick glance through the archives will show that the topic

I now realize I should have kept most of that discussion off-list and
only post conclusions.  Anyway, that discussion shows that current
practices are well different from what is (not) documented in either
the I-D or RFC 4408.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 27 Aug 2012 08:56:11 -0700

Hi Alessandro,
>the excess of aseptic formalism that at times you seem to entrench

That's an unusual objection.  :-)

>matter whether you like something or not?  I'm happy of your openness

I would have to review the document to form an opinion.  I am lazy to 
do that.  Likes or dislikes do not matter; it's the arguments that matter.

Regards,
S. Moonesamy