On Sun, Nov 12, 2006 at 01:12:22AM +0000, K.J. Petrie (Instabook) wrote:
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?
You still don't explain why you would want to use DNS for this. Sure,
there may need to be a standard way for customers to modify local lists
such as this forwarders-whitelist, there's no disagreement on that, but
why public DNS ? If I understand your proposal, the only people interested
in the data are (1) the customer and (2) his ISP (or forwarding service, or...).
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.
I don't need administrative access to modify httpd.conf at my provider.
(as far as my config is concerned, and as far as allowed by my ISP).
Why would I need administrative access to modify smtpd.conf ?
(same restrictions).
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?
SPF works on RCPT TO. If RCPT TO is not preserved, but is changed into
a local mail address (such as with SRS), no problem for SPF. If RCPT TO
_is_ preserved, then according to SPF the host is a forger, or it should
be internal forwarding and no other SPF cheching should occur downstream.
SPF is not interested in who is writing the message. SPF is interested
in who's sending it, and where bounces will end up. If you are some site
sending messages (e.g. a greeting card site) and if you mess up, you should
receive the bounces, not I.
Dito for forwarding services. If I deliver a message at the MX, and if
such a forwarding service messes up the next round of delivery, it's their
problem, not mine. They have a business relationship with their customer.
Why would I need to pay for fixing their errors?
If you require to look at "To", "Cc" and similar, you require
listening to the message:
HELO
MAIL FROM <--- SPF could work here, could reject now, processing stops.
RCPT TO
DATA <--- If you allow this command, the entire message is sent
<headers, including "To"> <-- Your proposal works here, but...
<empty line>
<message contents>
<single dot alone on line>
<--- ...you can reject here, not sooner.
The difference: the message size. The overhead is present in both cases.
If your proposal makes it, SPF can only work at the same place where your
RPF works. Not good IMHO.
OTOH, if my remarks are taken into account, there will be a list of know
forwarders (known, because the customer altered this list). SPF is not
processed, and the receiver could still look at "To" etc. For all other
incoming email, SPF works as usual, rejecting forgeries.
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