On Monday 10 November 2008 03:24, Douglas Otis wrote:
On Nov 7, 2008, at 5:25 PM, Scott Kitterman wrote:
On Fri, 7 Nov 2008 16:09:22 -0800 Douglas Otis <dotis(_at_)mail-
abuse.org> wrote:
....
I think it's worth pointing out when considering how much to worry
about Doug's latest "SPF will melt the Internet" theory that shared
MTA concerns are directly addressed in the RFC 4408 security
considerations. This is nothing new that wasn't carefully
considered during the protocol design.
Scott,
Thanks you for the opportunity to respond to this mistaken view.
... snipped repeat of accusations Doug's been repeating for years.
For those of you who haven't been involved in the previous rounds of this
discussion, the SPF project did take Doug's concerns seriously enough to
expend time on a detailed review of his analysis and conclusions. Rather
that rehash all that, I'll just point people here:
http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis
Doug: I know you disagree with that conclusion, but I'm not going to argue it
again.
I think it's reasonable to assume that implementers pay attention to
RFC security considerations. I think there are plenty of protocols
that would have security holes if their security considerations were
ignored.
Unfortunately, adopting security considerations in RFC 4408 is not
enough. Also, SPF combines both IPv4 and IPv6 into a common data-
set. As network address diversity grows, so will the size and number
of SPF related transactions.
Yes. As the internet gets bigger, more stuff happens. This is not a suprise
to anyone and rather tangential to the discussion.
If a DKIM signing shared MTA were to sign a message sent by somone
not authorized to use the domain, the exact some situation arises.
Unlike SPF that requires separate IP addresses to isolate each
customer's traffic, DKIM offers an unlimited number of domain names
per MTA without the need to impose any header field restrictions.
Seldom will a single MTA be assigned more than 8 IP addresses, and yet
many MTAs handle thousands of different domains.
Actually it doesn't require a separate IP. I think your sense of actual
operational options to ensure users don't forge each other is somewhat
limited if that's the only approach you can envision.
It is nonsense to suggest that SPF or Sender-ID authenticates a PRA or
MailFrom domain. It is normal for many domains to share the IP
address of an MTA. There is no way to discern which instance of an
published SPF record represents a unique IP address, or one that
adequately protects or adequately modifies the PRA. Few really do, so
assessments should not be based upon the Sender-ID or SPF authorized
domain, but instead should be based upon the MTA IP address or on a
non-authorized MTA.
I understand that's your view and based on past experience it's clear you
aren't open to changing your mind, so I'll just leave it as I disagree. Your
assumption here is that security considerations are ignored and for purposes
of standards work, I don't think that's appropriate.
A cynic may view the absence of the IP address from the
"authentication-results" header for Sender-ID or SPF as an effort to
shift blame toward hapless domain owners, and away from email
providers. Not including the IP address discourages recipients or
filters from checking with their trusted public IP address reputation
service at least. Most of the abuse seen today is introduced through
compromised systems. For Sender-ID or SPF, compromised systems are
best tracked by the MTA IP address.
That's just a way of saying 'don't use SPF'. You've been claiming that SPF
will make the internet melt for years now and I just don't agree with it one
bit.
The IP address is generally already enshrined in the Received header field, so
I don't see the point in redundant information. How to grovel through the
various Received fields in a reasonably reliable is fairly well advanced.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html