On Saturday 11 November 2006 14:59, Alex van den Bogaerdt wrote:
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.
I don't know what commercial models are used in various parts of the world,
but here in the UK service providers tend to operate on the "pile 'em high
and sell 'em cheap basis". They don't have time to make individual
arrangements with individual customers with special requirements. The only
way to ensure such arrangements can be made is to build them into the
protocol. Then I can do it myself without expecting special treatment from my
providers. This seems to me to be the right and obvious way to ensure the
domain owner retains control. I'm talking about SME and home domain owners,
who can only get an affordable service by using the multinational suppliers.
We're simply not in a position to negotiate special arrangements on our
accounts to create a "private policy". Does that explain my concerns?
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)
Maybe, but only if the domain owner has administrative access. Many of us
haven't, as explained above. If SPF does not allow us to control our
forwarding without such access, we will tend to see it as a threat rather
than a help. Result, low take-up.
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.
I take your point, but is "RCPT TO:" preserved in forwarding? It needs to
contain the original domain in order to work. I'm afraid I don't know enough
about SMTP to answer that. I'm just an ordinary domain owner who's scared SPF
will wreck my mail receipt arrangements. In order to have "another round of
verification", though, don't we need the DATA portion to be completed, which
is not much good if the policy applied to an SPF FAIL has already rejected
the message?
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
-------
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