Subject: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly

From: Alessandro Vesely <[email-masked]>
Date: Sat, 20 Apr 2013 11:56:17 +0200

Appendix H.2 should be merged into Section 8.4, as the reason to keep
them separate was beaten out by Murray's reorganization.  I mentioned
that in my review.

In addition, the combined text is not explicit in describing how
reject-on-fail works when enabled.  H.2 says "rejection can be done
before the SMTP content is transferred."  Explicit would be to to say
that the negative response can be given to either the MAIL or the RCPT
commands.

Of course, it is also possible to reject after receiving the content.
It is not typical of SPF implementations to do so.  Early rejection may
conflict with DMARC and similar policies, and the point of this issue is
that an explicit note can save readers the time to puzzle it out
themselves, and possibly avoid some misunderstanding.

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2013 14:40:54 -0000

>them separate was beaten out by Murray's reorganization.  I mentioned

No.  If anything, the second and third paragraphs of 8.4 should move
into H.2, since they're beyond the scope of what SPF actually does.

>that the negative response can be given to either the MAIL or the RCPT

No.  This draft already gives more gratuitous advice than it needs to.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 20 Apr 2013 11:32:52 -0400

> into H.2, since they're beyond the scope of what SPF actually does.

I believe the opposite is true. In fact, I believe BIS tries very hard 
to beat around the bush to relax the original goal, intent and purpose 
of a SPF FAIL policy  which is Rejection.  I believe BIS is more harmful 
to the community in this way (if indeed SPF FAIL policies are relaxed or 
its handling is relaxed) because of relaxation of statements and 
increased unnecessary verbosity.

> No.  This draft already gives more gratuitous advice than it needs to.

SMTP session level rejection is all that is required to be said. It can 
happen at HELO/ELHO, MAIL, RCPT (as SMTP 8321 offers a suggestion, see 
section 5.4) or DATA state machine points.   There is nothing gratuitous 
about this. Its the SPF Protocol intent and goal of the FAIL policies. 
The title of the doc even implies it. The abstract of the doc implies it 
as a method to find authorized machines and by authorization 
implication, you can do the opposite, easily find expected fault in the 
system and thus reject the unauthorized machines.

As stated a number of times, the only system that CAN/DOES NOT HONOR a 
SMTP  level rejection of a SPF failed policy transaction is one that can 
afford and performs the Message Separation at the USER level. Otherwise 
you have a pure and simple security loophole - period.

I wish we don't lose the key focus of this SPF FAIL policy. As it always 
bother the same folks still today, it was about rejecting unauthorized 
machines.  That said, it doesn't mean it (negative replies) can't be 
done at DATA EOD after other integrated considerations are made.  That 
is an implementator design option that it can offer to administrators 
and operators - all you can program it yourself. Those can only come in 
as augmented ideas and suggestions, hints. But despite all that, it (SPF 
FAIL) is still a REJECT concept.

--
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 20 Apr 2013 11:49:06 -0400

Small Correction, the reference to RFC 8321 Section 5.4 below should be 
instead a reference to section 3.3 [1]

    3.3.  Mail Transactions

    .... Despite the apparent
    scope of this requirement, there are circumstances in which the
    acceptability of the reverse-path may not be determined until one or
    more forward-paths (in RCPT commands) can be examined.  In those
    cases, the server MAY reasonably accept the reverse-path (with a 250
    reply) and then report problems after the forward-paths are received
    and examined.  Normally, failures produce 550 or 553 replies.

This is a CRITICAL SPF/DNS Optimization factor that SHOULD NOT be 
included from the BIS "protocol" description.

--
HLS

[1]https://tools.ietf.org/html/rfc5321#section-3.3

On 4/20/2013 11:32 AM, Hector Santos wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>
>

---

From: Hector Santos <[email-masked]>
Date: Sat, 20 Apr 2013 12:13:01 -0400

darn it, I meant Excluded!

This is a CRITICAL SPF/DNS Optimization factor that SHOULD NOT be
excluded from the BIS "protocol" description.

I'm out of here. Later

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 20 Apr 2013 12:30:10 -0400

> them separate was beaten out by Murray's reorganization.  I mentioned

I'm about half way through your long set of comments.  Thanks.

In my opinion, that would have additional side effects.  If H.2 goes away, then 
H.1 and H.3 are in an odd position and we'd end up reorganizing the document 
again.  I think we reached rough consensus on the organization and we 
shouldn't redo it (there are many things I'm not happy with about the 
organization, but I think we got to a place the group could support and I 
don't want to mess with it again).

Let's see if there's support for another reorganization?

> that the negative response can be given to either the MAIL or the RCPT

Do we need to be that specific?  It can also be done after HELO/EHLO if the 
rejection is based on the HELO identity.  Except for connect, SPF reject might 
happen at any stage in the SMTP process, so I'm not sure what additional 
specificity would add.  Note that 8.4 goes into detail about exactly how to 
reject, so I think that's not an issue.

> themselves, and possibly avoid some misunderstanding.

I'm not sure what's unclear.  Would it help if it said before DATA instead of 
"before the SMTP content is transferred"?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 20 Apr 2013 12:32:19 -0400

> FAIL) is still a REJECT concept.

Since how to give a 550 reject is right in the fail definition, I don't think 
your argument is consistent with the text.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 20 Apr 2013 12:36:26 -0400

Please propose specific text for evaluation.  I have no idea what it is you 
want changed in the draft.  Personally, I doubt we need to repeat things from 
RFC 5321 into the draft (they are already incorporated by reference 
effectively), I'd like to understand better what it is you think needs 
changing.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 20 Apr 2013 10:19:58 -0700

> them separate was beaten out by Murray's reorganization.  I mentioned

I don't agree.  What's in H.2 discusses local policy development which
cannot be normative.  It's strictly pedagogical.  Section 8 contains purely
definitions and normative material.  I don't support mixing them.

I also agree with what John said about this.

> that the negative response can be given to either the MAIL or the RCPT

I would be fine with changing H.2 to make that very explicit, although I
think we can rely on people understanding SMTP already since it's a
normative reference, so I'm also fine with leaving it as-is, and at this
late stage that is also my preference.

> themselves, and possibly avoid some misunderstanding.

We should absolutely not discuss DMARC or other layers here.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 21 Apr 2013 12:26:56 +0200

I gather there are better means to signify requirement than to spread a
subject across multiple places.  But then I'm almost 60 and I won't earn
any more or less money if the spec will be more comprehensible, so I'll
keep rather dispassionate on that topic.

> We should absolutely not discuss DMARC or other layers here.

That's what I want to clarify.  SPF does not separate algorithm from
policy in the same way that DKIM is separated from ADSP.  How can DMARC
specify an interface to the SPF layer if SPF does not provide for one?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Apr 2013 07:53:49 -0700

> specify an interface to the SPF layer if SPF does not provide for one?
RFC5451 is a perfectly good interface.  It works fine for OpenDMARC, for
example.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 22 Apr 2013 10:33:49 +0200

> RFC5451 is a perfectly good interface.  It works fine for OpenDMARC, for

Hm... RFC 5451 has phrases like 'if, for example, [SPF] returned as
"pass" result'.  It is not clear whether that refers to the result of
the check_host() function rather than, considering Section 4.2 "Local
Policy Enforcement", the combined result of check_host() and local
policy up to that point in the processing.

As a further example, Section 7.3 of RFC 5518 is formally ambiguous
too, because SPF could produce a "pass" result by validating the
"HELO" identity, and then VBR would be checked against a possibly
spoofed <reverse-path>.

Notwithstanding the loads of gratuitous advice we write, it seems
we're still missing crispy definitions of SPF results :-(

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 22 Apr 2013 11:20:44 -0700

> policy up to that point in the processing.

That's a bit off topic here, I think.  That draft (or the -bis version of
it) is in discussion on apps-discuss if you want to open the topic there.

However, I don't think you're comparing the same things.  The SPF result is
the result of check_host().  What local policy choice is made might be
based on that and it might not, but that doesn't change what check_host()
returned.

> "HELO" identity, and then VBR would be checked against a possibly

RFC5451 includes a mechanism for the consumer to know which mode of SPF was
used.  Why does VBR itself have to care?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 23 Apr 2013 09:59:13 +0200

On Mon 22/Apr/2013 20:20:44 +0200 Murray S. Kucherawy wrote:
>>>> SPF does not separate algorithm from policy in the same way
>>>> that DKIM is separated from ADSP.  How can DMARC specify an
>>>> interface to the SPF layer if SPF does not provide for one?
>>>
>>> RFC5451 is a perfectly good interface.  It works fine for
>>> OpenDMARC, for example.
>>
>> Hm... RFC 5451 has phrases like 'if, for example, [SPF] returned
>> as "pass" result'.  It is not clear whether that refers to the
>> result of the check_host() function rather than, considering
>> Section 4.2 "Local Policy Enforcement", the combined result of
>> check_host() and local policy up to that point in the
>> processing.
> 
> That's a bit off topic here, I think.

Not if we just aim at establishing whether such /kind/ of statements
can be made in a well defined manner.

> based on that and it might not, but that doesn't change what check_host()

Correct, it is possible to refer to the result of check_host() for a
given identity.  But none of RFC 5451, VBR and DMARC do so.  Why?  I
think it would result in a too lengthy wording.  Perhaps, the wording
of Section 2.4 can be improved?  Let me try:

OLD:
 A mail receiver can perform a set of SPF checks for each mail message
 it receives.  An SPF check tests the authorization of a client host
 to emit mail with a given identity.  Typically, such checks are done
 by a receiving MTA, but can be performed elsewhere in the mail
 processing chain so long as the required information is available and
 reliable.  At least the "MAIL FROM" identity MUST be checked, but it
 is RECOMMENDED that the "HELO" identity also be checked beforehand.

NEW:
 A mail receiver can perform two SPF checks for each mail message it
 receives.  Each SPF check tests the authorization of a client host
 for using either the "HELO" or the "MAIL FROM" identity.  The
 possible results of each check are given in Section 2.6.  The
 primary SPF result is the result of of the check associated with the
 "MAIL FROM" identity; this result MUST be obtained if possible.  The
 secondary SPF result is the result of the check associated with the
 "HELO" identity; it is RECOMMENDED that this result be obtained
 beforehand, and it MUST be obtained if it is not possible to get the
 primary.

_Note_ that I'm not proposing that change.  I'm asking if a change
like that would clear this issue.

> RFC5451 includes a mechanism for the consumer to know which mode of
> SPF was used.  Why does VBR itself have to care?

VBR does not refer to RFC 5451.  It just says:

   When SPF is the validation mechanism, VBR's md= MUST be the same
   value as the domain name in the <reverse-path> address that is the
   first parameter to the SMTP MAIL command.

   A domain is valid for use with VBR only when the SPF process
   produces a "pass" result.

Admittedly, it takes a bit of malice to misunderstand that.  However,
someone blindly developing the specs could overlook it.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 23 Apr 2013 05:52:42 -0400

> like that would clear this issue.

I don't see where it helps and it loses the point about doing the check in the 
MTA being better than post-processing, which I think is important, so -1 from 
me.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 23 Apr 2013 18:17:09 +0200

On Tue 23/Apr/2013 11:52:42 +0200 Scott Kitterman wrote:
>>  [...] Typically, such checks are done by a receiving MTA,
>>        but can be performed elsewhere in the mail processing chain
>>        so long as the required information is available and reliable.
>>  [...]
>> 

Yes, I left it off because it has nothing to do with the rest of the
definitions.  I agree it is an important point, but it is covered in
Section 2.5 "Location of Checks", not Section 2.4.

The issue here is that it is not crystal clear what are the SPF
results.  The introduction of the terms primary/secondary is probably
bad.  However, where do we say that the following line is wrong:

   Authentication-Result: spf=pass
      smtp.mailfrom=[email-masked];
?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 23 Apr 2013 11:29:01 -0700

>       smtp.mailfrom=[email-masked];

I don't even understand what problem we're trying to fix here.

I also don't see what's "wrong" with that example.  Are you saying you want
the consumer of this to be able to tell which mode SPF was in (MAIL FROM
vs. HELO) when it reached its conclusion?  If so, I would expect that's
obvious from the result spec; "smtp.mailfrom" means it evaluated the MAIL
FROM command parameter.

What would you think a client would want to do with that information?

If I'm to take your example as indicating the SPF verifier produced mangled
output, then I guess it shouldn't do that.  But again, this is a topic for
apps-discuss, not spfbis.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 24 Apr 2013 10:24:57 +0200

> I don't even understand what problem we're trying to fix here.

That the spec doesn't lend itself well to being used as a building
block for other specs willing to refer to SPF results.

> I also don't see what's "wrong" with that example.

Sorry, I should have said I assumed the client did something like:

   HELO helo-name.example.com
   MAIL FROM:<>

> Are you saying you want the consumer of this to be able to tell
> which mode SPF was in (MAIL FROM vs. HELO) when it reached its
> conclusion?

Yes.

> If so, I would expect that's obvious from the result spec;
> "smtp.mailfrom" means it evaluated the MAIL FROM command
> parameter.

Right, but since that parameter was null, the verifier synthesized a
mailbox composed of the local-part "postmaster" and the "HELO"
identity, as per Section 2.2.

> What would you think a client would want to do with that information?

VBR, for example, is interested in authenticating a mail domain rather
than a host name, because of the granularity it standardizes.

> If I'm to take your example as indicating the SPF verifier produced
> mangled output, then I guess it shouldn't do that.  But again, this
> is a topic for apps-discuss, not spfbis.

Perhaps, 5451bis could word something clever in terms of check_host()
so that other specs can refer to it instead of SPF.  However, if a
message is going to be rejected, the border MTA SHOULD issue an [SMTP]
rejection response to the message rather than adding this header field
with the failure result.  Which brings us back to this thread's subject.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 09:56:48 -0700

> block for other specs willing to refer to SPF results.

DMARC, for example, hasn't found that to be the case.

> identity, as per Section 2.2.

Such synthesis is meant for internal use by the SPF module only.  If that
value is exposed via A-R or some other method, then the module is
distributing false information.  If we're going to anything here, I think a
sentence or two in Section 9 is the right solution.

> than a host name, because of the granularity it standardizes.

But an A-R field would use one or the other (whichever one it verified),
which gives the VBR module the information it needs.

> with the failure result.  Which brings us back to this thread's subject.

But doesn't the bis draft already say that?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 24 Apr 2013 17:43:31 -0000

>DMARC, for example, hasn't found that to be the case.

Nor has the Authentication-Results: header, which was defined after 4408.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 25 Apr 2013 13:15:14 +0200

> DMARC, for example, hasn't found that to be the case.

Nor has VBR, actually.  We can pretend that SPF results are well
defined, 'cause we know what we mean, and live with that loose cannon.

>>> I would expect that's obvious from the result spec; 
> Such synthesis is meant for internal use by the SPF module only.

Would it hurt to say so in Section 2.2?

Better yet, we could entirely remove the sentence:

   When the reverse-path is null, _this document defines_
   the "MAIL FROM" identity to be the mailbox composed of
   the local-part "postmaster" and the "HELO" identity
   (which might or might not have been checked separately
   before).

In fact, Section 4.3 already says:

   If the <sender> has no local-part, substitute the string
   "postmaster" for the local-part.

How come it has no local part?  We don't need to do it twice.  The
former sentence is a "shortcut" to say that checking HELO is required
when MAIL FROM is null.

To wit, only an idiot can think that, irrespectively of whether the
HELO identity had been checked separately before, he or she MUST
--i.e., it is an absolute requirement of the specification to-- check
the thereby defined "MAIL FROM" anew.  Such an idiot will probably
report that result as smtp.mailfrom.  But why do we use a formal
language if implementers will have to do what we mean rather than what
we write?

> If that value is exposed via A-R or some other method, then the
> module is distributing false information.  If we're going to
> anything here, I think a sentence or two in Section 9 is the right
> solution.

IMHO it is more elaborate than it needs to.  To spell "check HELO" is
shorter and clearer than "define MAIL FROM to be the mailbox composed
so and so".  What am I missing?

Furthermore, a result is exposed via A-R or some other /header/ method
only in some cases, which depend on local policy, as I tried to

> But doesn't the bis draft already say that?

Which bis?  I copied the middle sentence from RFC 5451.  It says there
is no A-R in that case, hence one cannot refer to it.  A third spec
would have to refer to the SPF result that /would have been/ exposed
in case the local policy had provided to accept the message...

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Apr 2013 06:57:54 -0700

> defined, 'cause we know what we mean, and live with that loose cannon.

We could also concede that in fact the results are well-defined enough for
all practical uses, absent actual evidence to the contrary.

> Would it hurt to say so in Section 2.2?

No, but it doesn't appear to be necessary either.

>    (which might or might not have been checked separately

If you really want to make a change, I suggest changing "this document
defines..." to "an SPF verifier acts as if..." or words to that effect.
But I don't agree that it's necessary.

> former sentence is a "shortcut" to say that checking HELO is required

What about macro evaluation?

> so and so".  What am I missing?

They're orthogonal issues.

> in case the local policy had provided to accept the message...

The sentence "However, if a message is going to be rejected, the border MTA
SHOULD issue an [SMTP] rejection response to the message rather than adding
this header field with the failure result" is strange, because issuing an
SMTP rejection response is the very definition of a rejection; adding a
header field is not a rejection, it's a delivery.

Section 8.4 of this document talks about what SMTP codes to return when
rejecting a message.

If that doesn't answer your question, then I remain completely confused by
this thread.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Apr 2013 10:05:04 -0400

> What about macro evaluation?

Macro evaluation is precisely why that's there.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Apr 2013 11:30:35 -0400

> If that doesn't answer your question, then I remain completely confused by

Confusion is exactly my concern with this BIS can create for new 
implementators and operators on the FAIL policy.  I know it is hard for 
the long time opponents of this SPF policy to get, but rejection was the 
very essence and intent of the SPF FAIL policy. The 
SENDER-ID/SUBMITTER/PRA integrated SPF protocols is proof of that intent 
when all this was developed during MARID. I know we don't wish to rehash 
this, but it is what it is.  You can not eliminate these expensive 
design considerations that took place.   You can not ignore the 
integration efforts performed by original adopters of all the early 
LMAP-like experimental protocols, including SPF, CALLER-ID which morphed 
to SENDER-ID/SUBMITTER/PRA.

The Sender-ID/SPF integrated framework has clear normalized language:

    If these tests indicate that the connecting SMTP client is not
    authorized to transmit e-mail messages on behalf of the SUBMITTER
    domain, the receiving SMTP server SHOULD reject the message and when
    rejecting MUST use "550 5.7.1 Submitter not allowed."

    If the receiving SMTP server allows the connecting SMTP client to
    transmit message data, then the server SHOULD determine the purported
    responsible address of the message by examining the RFC 2822 message
    headers as described in [PRA].  If this purported responsible address
    does not match the address appearing in the SUBMITTER parameter, the
    receiving SMTP server MUST reject the message and when rejecting MUST
    use "550 5.7.1 Submitter does not match header."

    If no purported responsible address is found according to the
    procedure defined in [PRA], the SMTP server SHOULD reject the message
    and when rejecting MUST use "554 5.7.7 Cannot verify submitter
    address."

It would be totally strange for someone to suggest that full, total 
complete SMTP + Addons integrators will program a two paths reject and 
Accept logic that would be different for a SPF fail message:

  FAIL via MAIL FROM domain     --> ACCEPT (plus expected Separation)
  FAIL via SUBMITTER/PRA domain --> REJECT

My key point as always stated, FAIL (-ALL) is a special condition that 
really SHOULD NOT have ambiguity behind it. IMV, it never did until SPF 
BIS and even if there are systems that claims SPF support but still 
accept the message, I pointed out that it must be a separation otherwise 
we have a clear security issue (loophole) if a system does not separate 
it.  Fortunately, SPFBIS does cover this security condition, but don't 
you find that strange that a SECURITY alert is not part of the natural 
SPF protocol logic and for this specific FAIL case, a reject is done.

I would like to see the FAIL functional description to be streamlined 
and reduced.

Right now, BIS makes all sound like there are other ideas that SHOULD be 
used/coupled with SPF and that includes for fail results.  If true, what 
is that?  If SPFBIS can not specifically spell out that extra component 
is, then it SHOULD still to the basics and be very explicit on how a 
receiver should handle a SPF fail as to not reduce the payoff and 
expected powerful spoof protection for DOMAINS publishing a strong and 
exclusive -ALL mail network policy.

There should be two clear protocol logical paths described that is 
possible for a SPF failed transaction:

     FAIL->REJECT
     FAIL->ACCEPT+SEPARATION

What SHOULD NOT be deployed is a:

     FAIL->ACCEPT+REPORT

with a reliance on MUA or agent outside the backend or any other MFA 
(Mail Filtering Agent) unless it is 100% described and existing in the 
market place to be used by receivers.  The power of SPF FAIL is that it 
doesn't really need anything else.  We have seen a 20% effectiveness of 
SPF rejections on our system.

To do anything else, in my view, the receiver is not SPF compliant.

I should note, for implementators that currently REJECT and which to 
consider the SPFBIS relaxtion to offer an ACCEPT, it would an expensive 
design change to offer this deployment option.

As a side note, I don't think SPFBIS has enough Reporting examples. It 
should have an example and description of all possible SPF results.

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Apr 2013 11:37:50 -0400

> to SENDER-ID/SUBMITTER/PRA.

I think it's reasonably safe to say I don't fall into the category of "long 
time opponents of this SPF policy" and I don't understand your objections 
either.

>     and when rejecting MUST use "554 5.7.7 Cannot verify submitter

What document are you quoting from here?

> design change to offer this deployment option.

There's nothing in 4408bis that says you HAVE to change anything about 
receiver policy if you don't want to. 

> should have an example and description of all possible SPF results.

Provide text and I'll see about including them.

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Apr 2013 12:42:03 -0400

> What document are you quoting from here?

SUBMITTER rfc4405, section 4.2 Processing the SUBMITTER Parameter:

http://tools.ietf.org/html/rfc4405#section-4.2

It is even stronger language and clearer in SENDER-ID section 5.3

http://tools.ietf.org/html/rfc4406#section-5.3

> receiver policy if you don't want to.

You're right. I am saying it is advocating this approach (opening the 
door) and developers who follow this stuff take it all into account.

Part of the issue is that according to either one person or a few, the 
norm is:

     SPF FAIL --> ACCEPT

Again, what I am not hearing is whether they are separating it or not.

I'm saying they MUST and therefore should be an explicit statement in 
8.4 and not divert it to the security section.  Just a flow chart and 
see if make sense to not naturally CODE what the security section 
recommends should be done or else.

> Provide text and I'll see about including them.

I did Scott, a number of different ways of the year or so.

Take a look at how PRA describes it in 5.3 and try to mode this in SPF 
terms. I believe I had suggested that before.  This is whats in PRA, it 
covers it clearly for both REJECT and ACCEPT logical paths:

    5.3.  Fail

    When performing the Sender ID test during an SMTP transaction, an MTA
    that chooses to reject a message receiving this result SHOULD reject
    the message with a "550 5.7.1 Sender ID (xxx) yyy - zzz" SMTP error,
    where "xxx" is replaced with "PRA" or "MAIL FROM", "yyy" is replaced
    with the additional reason returned by the check_host() function, and
    "zzz" is replaced with the explanation string returned by the
    check_host() function.

    When performing the Sender ID test after accepting an e-mail message
    for delivery, an MTA that chooses to reject a message receiving this
    result SHOULD NOT deliver the message.  Instead, it should create a
    DSN message, consistent with the usual rules for DSN messages.

Look at how this helps Murray's work with Auth-Res for reporting. I 
personally do not believe in this path (reporting and bounce) and 
therefore reject at SMTP to avoid the bounce requirement/expectation.

I can't be any more clearer as I have been and that's because there is 
pressure to use USER-LEVEL policies or one that is embedded ACCEPT PLUS 
SEPERATE.  That is what I am saying it should be PART of the protocol, 
and not needed to be stated as a SECURITY ISSUE in order for one to do 
what must be done anyway - not deliver the message.

Keep in mind that the POV is not just a tree-like folders display of 
separated messages, but the idea of how the USER gets access to his 
mail.  As I stated at the very beginning, if a system offers a POP3 
server, I highly recommended that this ACCEPTED failed mail IS NOT made 
part of the POP3 download process which is a single stream. It is not 
like IMAP where there are multiple viewing streams and possible for a 
separation to take place.  The POP3 user will be victims of an 
FAIL+ACCEPT deployment - period.  There is no ambiguity about that.

Folks using Web Mail and IMAP have a separation - I hope.

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Apr 2013 12:58:28 -0400

> http://tools.ietf.org/html/rfc4406#section-5.3

This is the SPFbis working group, not the Sender ID working group, so I think 
it's off topic.

> Again, what I am not hearing is whether they are separating it or not.

What you've heard is correct for many large providers.  Send an SPF fail mail 
to gmail and see if it gets rejected.  It's common.

> Folks using Web Mail and IMAP have a separation - I hope.

I meant text for examples.  I think we've had this discussion before and, in 
my, I'm not the chair, but I read every message on the list, opinion, the body 
of the text ~represents the consensus of the WG

I'm certainly against copying text into 4408bis from any of the SenderID 
documents.  

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Apr 2013 12:13:55 +0200

> Macro evaluation is precisely why that's there.

I still cannot figure out how it is possible to get a sender with no
local part (except malformed MAIL FROM).  Both Section 5.2 and 6.1 say:

   The <ip> and <sender> arguments remain the same
   as in the current evaluation of check_host().

So it seems that if <sender> has a local part initially, it will never
go away.  Any example to the contrary?

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 08:38:21 -0400

> go away.  Any example to the contrary?

If mail from is null, you substitute HELO for mail from.  Mail From has no 
localpart.  You need to have something to use in case there is an "l" macro 
expansion in the record.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 27 Apr 2013 09:18:17 +0200

On Fri 26/Apr/2013 14:38:21 +0200 Scott Kitterman wrote:
> If mail from is null, you substitute HELO for mail from.

Yeah, right.  Well, nearly:  One should use postmaster@HELO, according
to the definition, no?

We already had this discussion in [1], where you said that removing
that ridiculous definition is a "protocol change".

[1] http://www.ietf.org/mail-archive/web/spfbis/current/msg03021.html

---

From: S Moonesamy <[email-masked]>
Date: Sat, 27 Apr 2013 07:17:29 -0700

Hi Alessandro,

I read the messages on the thread at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03369.html 
The issue of "8.4. Fail: rejection is not described explicitly" may 
be related to other issues.  It may be better to try and get the 
other outstanding issues resolved first and then get back to this 
one.  I'll try and provide a rough summary of this issue after 
that.  The SPFBIS WG can then decide what it wants to do about it.

Regards,
S. Moonesamy (as document shepherd)

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03374.html