[Top] [All Lists]

Re: [mail-vet-discuss] draft-kucherawy-sender-auth-header and last call draft-hoffman-dac-vbr-04

2008-11-10 15:46:16
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-> 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.


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:

Doug: I know you disagree with that conclusion, but I'm not going to argue it 

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

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 

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 

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