Subject: Re: [spfbis] STTN: "CAN" vs "MAY" (was : Bug - Conflict between 2.5.4 and 2.3 [was SMTP level rejection])

From: Arthur Thisell <[email-masked]>
Date: Wed, 22 Aug 2012 03:57:30 -0700 (PDT)

First, let me say that I have reviewed all changes since RFC4408.

> I believe BIS has been watered down with this increase obvious emphasis on > local policies (DUH!).

No it hasn't.  If the new wording makes you see what has always been there, then the new wording is good.

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Aug 2012 11:00:40 -0400

> No it hasn't.  If the new wording makes you see what has always been there, then the new wording is good.

Then lets get back to basic and address the original issue 29 by 
adding a new security section 10.7.

10.7 Marked Failed Mail Exposure

    Section 2.5.4 and 9.3.2 reinforces the local policies concept
    that SPF receivers have no formal protocol requirement to
    enforce rejection of mail which were detected using -ALL policies.
    Section 2.3 highlights the domain intent and expectation for
    such negative classification.  However, the receiver is under
    no technical obligation to take any action for SPF failed results.

    If the alternative marking is done, it is conceivable local backends
    will still pass the mail to users with no additional red flags or
    indicators of SPF fail. This will require more advanced MUA to 
understand
    the Receive-SPF headers.

    Thus under such cases, there is a possibility users can be exposed
    to harmful mail when the backend added the Receiver-SPF but did not
    further separate the message from the user's normal everyday mode of
    reading/accessing mail.

    Backends needs to take precautions of marking messages resulting
    from SPF -ALL failed transactions but were not rejected as prescribed
    in section 2.5.4.

-- 
HLS