ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Blocking improperly signed messages

2006-12-11 13:20:34
On 12/11/06, Steve Atkins <steve(_at_)blighty(_dot_)com> wrote:
(Just background for Damon, and anyone else in the same frame of mind,
nothing SSP or DKIM specific here).
Were you around for the fiasco that was SPF?
That's where a lot of our operational experience of throwing away
perfectly good mail, simply because it wasn't transmitted in a way
that followed the dogma of the message signers came from.

I don't think it was a fiasco. I believe that it was the first attempt
at doing ~something~ meaningful. There were many intelligent people
involved, many are still here and still involved. (Nods to Dave,
Hector, Scott, Douglas, and others).
Please note the date on this post (an interesting historical read :) -
http://www1.ietf.org/mail-archive/web/asrg/current/msg00334.html
DK wasn't even around yet. The real death knoll came with MS decided
to license our next step just as we were getting there (PRA).
All in all I believe that it was an excellent learning experience. Too
bad many of the lessons from it are still not learned.

It was, basically, a failure, in that the SPF policies (which are very
much equivalent to SSP) that are published are almost "?all",
which is pretty much equivalent to "I sign some things" in SSP
speak.

And ?all is/was supposed to be temporary. But I do know many domains
that protect themselves with SPF. If an admin inadvertently posts a
bad SPF, it can be fixed. You are missing the point. You are pointing
to the fact that valid mail is thrown away and saying SPF is broken. I
point to it and say- It is working exactly as it should! It is an
administrative issue, not a technical fault.
SPF was NOT supposed to block spam, it was an attempt at validating
where the email is/should be coming from. The real issue as I see it
is admins discovered they really don't know the extent of their own
infrastructure. Hence all the ?ALL's.
I believe that I remember a thread asking what we are going to
recommend people do when sig validation fails. From an operational
side, I would say that it would be nice if I got a rejection
notification but only from email that ~also~ passed the SPF check. SSP
does not do what SPF does. SPF isn't dead or even sick, just
misunderstood. SSP lets admins have granular control over their rules.

People wouldn't tolerate mail being thrown away for
no good reason, nor were even the developers of SPF prepared
to modify the way in which they forwarded email around in order
to work around the flaws of SPF.

As those involved will tell you... this was because it was watered
down and good suggestions from people like Hadmut Danish were not even
considered. Hadmut finally got tired of it all and stopped
participating... which is too bad. Have not heard from him since.

There seems to be some belief that if SSP does exactly the same
thing as SPF then we'll pull the phishing-proof, spam-resistant
mail architecture out of the hat this time.


I am going to get my knuckles rapped again by the chairs for this trip
down memory lane so I will stop here. Since Base is closed to the type
of modification I would have hoped to see, I am looking forward to
debate on SSP.

Regards,
Damon Sauer
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>