>-----Original Message----- >From: Siegel, Ellen [mailto:[EMAIL PROTECTED] >Sent: Tuesday, January 29, 2008 2:44 PM >To: MH Michael Hammer (5304); [EMAIL PROTECTED] >Cc: [email protected] >Subject: RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to >posting byfirstAuthor breaks email semantics > > > >Just because it is possible to abuse a particular >configuration doesn't mean that the configuration is >inherently invalid. If that were true, then none of us would >be willing or able to send any email at all. > >Yes, it's possible to come up with scenarios that involve >abuse, but there are at least as many that are legitimate, >i.e. where the sender is truly sending on behalf of the author >and with their express consent. >
So where is the problem? The author (account holder) uses that email address at the pleasure of the domain owner. Most domains that provide accounts have some sort of Terms of Service. So unless you are willing to assert that domain owners have no right to decide how accounts at their domains will be used, it is implicit that domain owners have the right to tell a user...you may only send through authorized servers. Many domains may choose not to implement or publish such a strong policy. If the domain owner doesn't have a problem with the author (account holder) sending unsigned email from other domains, why should I...or anyone else for that matter? >The goals behind SSP are laudable, but from where I sit I see >relatively few domains that lock down their email sufficiently >to reasonably be able to deny their individual account holders >the right to use their address as they desire. Yours may well >be one of these, but please don't assume that because it works >for you therefore it should be applied across the board to everyone. > That's the point. For those domains that do want to lock down their email, it works. For those domains that do not wish to lock down their email it works. Nobody has claimed that locking down DKIM signing works across the board for every domain owner or author. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
