Re: [ietf-dkim] Replay isn't the problem, spam is the problem

On Aug 9, 2005, at 7:34 AM, Amir Herzberg wrote:

> Douglas Otis wrote:
> > On Tue, 2005-08-09 at 01:17 +0200, Amir Herzberg wrote:
> >
> > Here you break one of the better features of DKIM.  The ability to
> > change the recipient when forwarding the message.
> I do not propose that DKIM should specificy receivers MUST discard  
> messages received without replay protection (and recipient  
> identification). I just propose we give recipients the ability to  
> distinguish between messages with replay protection and recipient  
> identification, and messages without these capabilities. So  
> forwarding still works, but degrades the security of the message -  
> to the level we have with DKIM without replay protection. What's  
> the problem?
I imagine you are suggesting that the RFC2821 RCPT TO: be compared to  
the content of
the RFC2822 To:?

Assuming this could be made to work, then there would be no means to  
known when this mechanism would create a problem, as you claim this  
breaks forwarding.  This would negatively impact the integrity of  
email delivery, and create serious support issues.  Those that opt to  
disable this constraint would remain powerless at preventing a replay  
attack.  Not a very good choice either way.

> > The DKIM already includes a date header and a expiry option.
>
> > Why would a CRL not address a replay problem?
> CRL is a mechanism to revoke certificates, how is it relevant?
> ...
From the perspective of maintaining one's reputation, having an  
ability to demonstrate a response to a complaint is important.  If  
you receive a legitimate complaint, the problem should be made to  
stop.  If using S/MIME, a CRL, or if using DKIM, the revocation- 
identifier mechanism, permits the domain to halt any abuse anywhere  
in transit, including replay abuse, that may be occurring.  If abuse  
meets a sure and rapid response, this mode of abuse should be greatly  
discouraged.  From a reputation standpoint, the offending domain  
would be able to demonstrate their cooperation.
> > How does one rate limit when a message can be copied and sent through
> > any server where the recipient can also be changed?  I assume you  
> > want
> > to remove the feature where the recipient field can be changed.
> No. A mail server can rate control the messages that it sends. It  
> cannot control what happens to them later. So that caps the  
> responsibility of the server, for reputation/accreditation/ 
> compensation services. Recipients can still decide, of course, they  
> are willing to accept messages without replay protection, possibly  
> based on their source (e.g. a particular trusted, moderated mailing  
> list).
Now we are back to maintaining white-lists for every possible account  
that may provide forwarding?  As many of these domains that permit  
forwarding are large, white-listing would expose the recipient  
substantially.  It seems you want to impose a restriction that is  
sure to make forwarding email practically impossible.  I am also sure  
this will also reveal all those cases where the RCPT TO changes for  
other reasons.
-Doug

_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim