RE: Sendmail white paper

Sorry,  Seem to have gotten S/MIME stuck in the on position.  Fixed now.

Scott Kitterman

-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Scott 
Kitterman
Sent: Tuesday, November 23, 2004 12:49 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Sendmail white paper


Since the S/MIME signature apparently caused problems for some people,
here's the message again without the signature.

Scott Kitterman

-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Scott 
Kitterman
Sent: Tuesday, November 23, 2004 12:02 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Sendmail white paper

-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of David 
Woodhouse
Sent: Tuesday, November 23, 2004 11:39 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Sendmail white paper


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?


CSV does not do everything SPF does.  CSV checks the HELO/EHLO argument
and compares it against an SRV record (it does other stuff too, but

that's

the part that's congruent with SPF).  Since I don't operate an MTA, my
domains never appear as a HELO/EHLO arguement.  CSV doesn't have anything
to do with me.

CSV operates on behalf of the MTA operator.  SPF operates on behalf of

the

domain owner.  My guess is that there is a large overlap between these

two

groups.  The overlap is not, however, a unity.

I've got nothing against CSV.  When it's deployed I think that will be a
good thing.  I believe that there will be synergy between CSV and SPF.

If

CSV has already given the HELO/EHLO a pass, I think that ought to be
counted as an SPF HELO/EHLO PASS.  In many cases, that can possibly be
leveraged into an SPF pass where the CSV and SPF identities are the same.
I think that this would be a good thing to work on.  This would allow SPF
to take advantage of what's already known through CSV's authentication of
the channel.  This ought to limit the DNS impact of SPF in the long run.
Once CSV is stabilized and deployed, we need to work on this synergy.

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.


If you 'volunteered' them, they may welcome the mail getting rejected
because of SPF ;).  If they agreed to take that mail from you, then they
ought to whitelist you from SPF checking if their MX checks SPF.  It is

an

additional complexity, I agree, but I believe it to be manageable.

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.


Actually, that's only part of the answer.  As one of the "Toy" domains
that you often refer to, I have a very good idea of where all my mail
acutally goes.  None of it gets forwarded.  I realize that larger
organizations can't know that, but I do.  For some demographics,
forwarding will be a big issue.  For some it won't.


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.

I get a lot fewer than I used to.  I don't keep statistics, so I can't
give you anything more than a qualitative answer.  They weren't really a
major concern for me anyway.

 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?


Nothing is inherently wrong with CSV, but it's not deployed yet and it
doesn't relate to my particular problem.


It's not breakage I object to per se -- sometimes you have to break
things. It's the _pointless_ breakage which bemuses me.

 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.

Which of these alternatives am I able to deploy now?

The reason I came to SPF wasn't bounce reduction, it was forgery
prevention.  In my business, my name is my brand and so it's important to
me.  SES doesn't help me there.

IIM/DK aren't really ready for me as far as I can tell.

I could PGP sign my mail, but that only tells people what I have sent.

It

doesn't give me a way to repudiate what I haven't.  Same with S/MIME.

I'm

going to sign this message with S/MIME, but I expect it will come up
invalid because I didn't get it from one of the main Certificate
Authorities (it will also come up as a US government certificate, but

it's

not, it's so I can communicate with them).

What other than SPF is ready to help me solve my problem today?

SPF is certainly not perfect, but I believe it to be better than nothing.
Those are my choices today.

Scott Kitterman