On Sat, Nov 11, 2006 at 02:36:20PM +0000, K.J. Petrie wrote:
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.
Let me get this straight. What I think you propose here is:
a) that the message is received, in order to process the content
b) a receiver publishes information in DNS that only this receiver
is going to use, so that it can whitelist forwarders in use by
this receiver
Then, if the message is accepted by your rpf policy (thus: the message
is coming from an authorized forwarder), no spf check is performed at
that host.
A couple of comments:
1) I don't see why you'd want to use public DNS to handle a local,
private, policy. The receiver is going to lookup his own data which
only he is going to use, correct? If domain owners need a way to
communicate to their providers, I doubt that public DNS is the right
tool for it.
2) Indeed one should not perform SPF verification on messages coming
from a forwarder, unless this forwarder is using a semi-transparent
proxy mechanism such as postfix has. However, I don't think this is
the solution to separate forwarded mail from directly incoming mail.
Local policy lists (local to the mail server) seem to be much more
effective. Pseudo-code:
if not connecting_ip in locally_known_list_of_forwarders:
spf_check(ip,domain)
3) Your proposal requires the DATA portion of SMTP to be completed. SPF
does not. In other words: your proposal destroys one of the key benefits
of SPF. You could modify your proposal to work on "RCPT TO:" to overcome
my objection. If you also want to work on the message itself ("to:", "cc:")
then do this in another round of verification.
If I interpreted your proposal the wrong way, please show more examples
using less text.
regards
Alex
-------
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