(This is a re-send of a message originally sent on 5th November 2006, which
seems to have failed to arrive. I have modified it slightly to take account
of recent comments about whitelisting.)
I would like to see a new feature added to SPF which, I believe, would provide
a more attractive option for enabling forwarding than the current SRS (SPF)
or Resent-from: (SenderID) mechanisms. I am not proposing that these other
mechanisms be removed from their respective systems. So far as I know, there
is no incompatibility between my idea and these other mechanisms, though it
might render them unnecessary in some circumstances. I am simply proposing it
because I believe it will provide domain owners with another tool and give
them more confidence in it, by giving us control and removing a very real
fear many of us have.
I have already voiced elsewhere concerns about the effectiveness of SPF at
achieving its intended purpose, but I do not intend to address them here. My
concern here is to see that if SPF is to be adopted, it will be a tool which,
however effective it proves to be, will at least allow domain owners to see
it as something positive or neutral, rather than negative. I have also been
told my idea is not new and has already been rejected, but I find that hard
to believe, partly because I have found no obvious reference to it on this
list's archives (though it is always possible I have missed something), and
also because I cannot understand why anyone would object to it. It does not
take away any functionality a domain owner would want to preserve, and it in
no way affects the core application. It would simply give domain owners as
E-mail recipients more flexibility in how the framework is applied. Why would
anyone object to that?
So, to my proposed addition, which is, alongside the spf record for a domain,
I suggest a second record, which I shall call Recipient Protocol Framework
(RPF). The RPF record would be similar in format to an SPF record as
described in RFC 4408 except that it would begin "v=rpf1" instead
of "v=spf1". It would only support a subset of the fields contained in an SPF
record, however, to prevent a malicious domain owner setting, e.g. +all and
then spamming with a bogus To: or Cc: header. I would recommend forcing -all
and limiting ip4 to x.x.x.x/24 (and other field types to their equivalent
range) and the number of fields in the record to 5 (or 2 or 3 should be
enough) to reduce the attractiveness of such abuse. (I would have no
objection to tightening this further. The aim is to allow a domain owner to
turn SPF checking off in a specific case, whilst ensuring a spammer would not
find it a practical method for widespread disabling of the system.)
(I realised this is quite a major modification and it might be
felt desirable to consider this a new version at the current stage of the
RFC process, but that is not my decision and I shall assume for the sake of
this illustration that the version number remains unaltered.) Matches would
produce the same results as for the SPF record, and the matching algorithm of
the check_host function would remain unaltered. However, check_host would
need an additional <mode> argument, and would be called twice in most cases
using a logical 'OR' on the PASS result.
It would work as follows:
1. check_host would be called and passed:
<ip> The Ip address of the local server performing the SPF/RPF check,
<domain> The domain portion of the address in the To:, Cc: or Envelope-To:
header,
<sender> (in this context a misnomer) Initially the address in the To:, Cc: or
Envelope-To: header,
<mode> The String "rpf1".
The function would then fetch the RPF record for the domain, parse it and test
it in a similar manner to the SPF record in RFC4408, but with the limited
functionality outlined above. If the result were PASS this would be
the output and further testing, that is, of the SPF record would not be
necessary.
2. In all other cases check_host would be called a second time, passed the
arguments specified in RFC4408 and the <mode> "spf1". It would then fetch the
SPF record and proceed as in RFC4408.
Hence, a domain owner could use this new functionality to specify servers
which should not carry out an SPF check on incoming messages for the domain,
thus ensuring that forwarded messages which had reached his/her domain's
forwarding MTA successfully would not be tested again by the (possibly
administratively independent) MRU providing his/her mailbox (where such a
test would have no value and all mail from SPF-enabled domains would fail).
This mechanism, whilst in no way preventing the rewriting proposed in RFC4408,
does not rely on it, and is therefore more satisfactory when servers are
administratively independent. Control is given to the domain owner, such that
if the MRU administrator adopts SPF testing, incoming mail can still be
received even if the forwarding MTA has not adopted SPF/SRS. Surely it is the
domain owner who should be able to control such things, and he/she should not
be at the mercy of different administrator's opinions, especially when
consensus on which system to adopt is lacking within the industry.
I cannot see why anyone would find this proposal problematic. It just puts
control where it belongs and enables domain owners to ensure their incoming
mail will not be disrupted by a process intended to protect their outgoing
identity. It would be fully compatible with existing SPF records if an RPF
result of anything other than PASS MUST result in the standard SPF check
continuing.
K.J. Petrie
-------
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