Mailing List Archive: Exempt status for Received-SPF header

In a future SPF version, I'd like to see the "Received-SPF:" header
extended to have an extra "exempt" status.

Adding a "Received-SPF: exempt" header would allow an MTA to say, "I
normally check SPF here. However, I have out-of-band information that
supports the provenance of this particular mail, even though an SPF check
would probably return fail. Any other Received-SPF: headers in this
message are not from me."

This would allow an MUA to always trust the topmost Received-SPF: in
incoming mail. Otherwise, in an "exempt" case, the MTA would add no
Received-SPF:, and the MUA would be confused by any spurious Received-SPF:
header already in the message.

One case where "exempt" could be used is when an ISP has one MTA serving
as both smarthost and MX. Mail from a local user on a dynamic IP to
another local user will probably fail SPF, yet the MTA can be even more
confident in it than in SPF-pass mail from outside.

Another obvious case is any sort of "trusted traditional forwarder"
arrangement.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com

On Sunday 23 September 2007 15:32, Michael Deutschmann wrote:
> In a future SPF version, I'd like to see the "Received-SPF:" header
> extended to have an extra "exempt" status.
>
> Adding a "Received-SPF: exempt" header would allow an MTA to say, "I
> normally check SPF here. However, I have out-of-band information that
> supports the provenance of this particular mail, even though an SPF check
> would probably return fail. Any other Received-SPF: headers in this
> message are not from me."
>
> This would allow an MUA to always trust the topmost Received-SPF: in
> incoming mail. Otherwise, in an "exempt" case, the MTA would add no
> Received-SPF:, and the MUA would be confused by any spurious Received-SPF:
> header already in the message.
>
> One case where "exempt" could be used is when an ISP has one MTA serving
> as both smarthost and MX. Mail from a local user on a dynamic IP to
> another local user will probably fail SPF, yet the MTA can be even more
> confident in it than in SPF-pass mail from outside.
>
> Another obvious case is any sort of "trusted traditional forwarder"
> arrangement.
>

I'd suggest looking at how SpamAssassin decides which headers are trustworthy
and which are not. That would probably be more robust.

There is a comment field in the header that could be used. What I've done is
something like the following:

X-Comment: SPF skipped for whitelisted relay

You could add your own X header and parse based on the presence of that or
Received-SPF.

Your proposal (based on the way the header works) implies adding a new SPF
result and I don't think that would be appropriate.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com