[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: The Value of Reputation
From:       Douglas Otis <dotis () mail-abuse ! org>
Date:       2005-12-28 16:46:00
Message-ID: 22FDDD3D-C3A4-4099-8583-68EAF16BBA67 () mail-abuse ! org
[Download RAW message or body]


On Dec 27, 2005, at 5:20 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> The response was specifically against the use of "authorization."   
>> With respect to SPF/Sender-ID or SSP, these are indeed email- 
>> address "authorization" schemes.
>
> There's no "burden shifting".  If you have a PASS you know that the  
> Return-Path is no random garbage, you can bounce or challenge  
> without hitting innocent bystanders.

The email-address domain owner bears the burden when email-address  
authorization is considered "weak" authentication and used to accrue  
reputation.  The burden is shifted when the email-address  
authorization does not indicate the actual sender.  In shared  
environments with millions of compromised clients, these public  
authorizations will act as invitations.  Most email-address domain  
owners will suffer harm well beyond their control, as only a few  
administer their own private servers.  Repairing exceptions only  
increases these exposures when this involves open-ended  
authorizations (by any name).

> ...
> Back to SPF PASS, I'm free to say "v=spf1 +all".  If that backfires  
> with whatever you do it is my problem, it's not your problem.  A  
> bogus SPF record is as bad as bogus MX records, that's no "burden  
> shifting", it's a fact of live.

This back-scatter problem can be resolved by implementing BATV at the  
cost of two additional wafer-thin packets.  (This would be far less  
overhead than looking up SPF records.)  Unlike the (defunct) SPF  
scheme aimed at qualifying the return-path, BATV does not wait for  
wide adoption before benefits can be derived.  The BATV signatures  
should be obfuscated upon delivery, and the same obfuscation could be  
common practice for DKIM, as described the in the options draft.  : )

-Doug 
  

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
[prev in list] [next in list] [prev in thread] [next in thread]