David Woodhouse wrote:
On Tue, 2004-11-23 at 11:26 -0500, Scott Kitterman wrote:
You are convinced beyond any possibility of reconsideration that the
forwarding problem is a deal breaker for SPF. You are welcome to your
opinion. I don't think anyone is confused at all about your opinion.
Like I said, it's not so much that you want to force the world to
'upgrade'. It's that you want to force the world to upgrade without
actually _needing_ to. CSV does everything that SPF does, without the
breakage. What do you have against CSV?
It is a nice format for exchanging spreadsheet files in, but irrelevant
to this list. OH, you mean "Client SMTP Validation"? Well, that is just
a fancy-schmancy name for SPF+trusted-forwarders.org as near as I can
tell. It doesn't "solve" any problems that aren't already solved except
for the lack of notoriety of its authors.
I said that forwarding is a problem for the receiver because it's the
receiver that establishes the forwarding relationship.
But it's not. It's the _forwarder_ that establishes the forwarding
relationship. I may go on holiday for a week or two and I may add a rule
to my Exim filter file which forwards mailing list moderation requests
to somebody whom I have 'volunteered' for the task in my absence. That
isn't even established by the recipient, let alone anyone at the
recipient's ISP who is involved with the decision as to whether to check
SPF.
Or even to ensure that their spam filter doesn't drop such messages
on the floor. You talk like SPF is the ONLY thing that breaks such
forwarding arrangements, when in fact it is the only one that does so
in a way that allows for them to be fixed. Spam filters reject and
drop messages all the time for perfectly arbitrary reasons (like
having "thank you!" in the subject line). SPF is a predictable and
correctable "problem" where forwarding is involved.
I understand it's difficult for the ultimate destination to know of _all_
forwarding relationships. It is, in fact, impossible for the sender to
know. It is incumbent on receivers to not kill their customers e-mail (or
accept that they will lose a certain fraction of their customer base). When
implementing SPF on the receive side, one ought to not be stupid about it.
Indeed. That's presumably why you've seen so few rejects -- there aren't
that many sites of any reasonable size who are careless enough to
actually reject.
Or polite enough to reject instead of silently dropping stuff on
the floor. You seem to think that rejecting e-mail is a BAD thing.
It isn't. It is a necessary part of the system that allows
problems to be detected and corrected.
You didn't answer the question about how many bounces you still get to
mail you didn't send. You're offering only half the statistics.
As are you. How many "self spams" do you get?
Or do you use a local rule that excludes them that you aren't
polite enough to share with the world?
I mean, if it is good enough for your server to know that e-mail
that claims to come from you that didn't can be dropped/rejected,
why not share that information so that others can benefit?
Every transition has some pain and you need to take time to work
through the corner cases.
Now, I think all this is reasonable and doable. You are no doubt already
composing your response to explain how this proves once again that SPF is
broken. Don't bother.
No, I'm composing a response to ask, yet again, why you think this
breakage is preferable to the other schemes which don't have such
problems. What's wrong with CSV? What's wrong with the other schemes I
spoke of recently?
How are they significantly better?
It's not breakage I object to per se -- sometimes you have to break
things. It's the _pointless_ breakage which bemuses me.
Moving breakage from the invisible to the visible is far from pointless.
Naive forwarding is broken. It needs to be fixed. SES is one way to
fix it, SRS and Database Backed Forwarding are others.
SPF simply moves the breakage to the visible world so that we can
see it.
There really isn't anything you can say that you
haven't said several times already.
Like "what is wrong with the alternatives which do _not_ have the same
problem", perchance? Nobody really seems interested in answering that.
How are they better really?
SPF works quite well, you have to present a case better than "it doesn't
break forwarding" before you can reasonably expect advocates of SPF
to seriously consider your alternative du jour.
--
Daniel Taylor VP Operations Vocal Laboratories, Inc.
dtaylor(_at_)vocalabs(_dot_)com http://www.vocalabs.com/
(952)941-6580x203