I believe that the basic disconnect here is that the protocol "protects"
anything.
The running assumption that I've seen the most support for is that the
protocol
*informs" other entities of the way the domain behaves, and the protocol
consumer
may or may not use that information in conjunction with other
information to
"protect" their incoming mail feed. Thus requirements that presumes that the
sender knows the mail transit topology seem rather incongruous with an
information service about the sender itself.
Mike
Damon wrote:
I understand that it is not a reputation service, however, I am now at
the mercy of my ISP's reputation and not mine. In fact, they are full
of bots and spammers.
Consider:
I never sign email coming from Holiday Inn where 50% on my workforce
lives out of suitcases but Holiday Inn does sign (inconsequential)
I always sign email coming from the home office in Walla Walla.
Therefore my rule says that I sometimes sign. But what good did that
do me? My ISP is the issue, not Holiday Inn. So, if I was able to say
I sometimes sign my email and I always sign from the home office, it
would be too much of a DNS load to describe where I might sometimes
sign. It would be better if I could specifically just distrust my ISP.
Regards,
Damon Sauer
On 8/1/06, *Hector Santos* <hsantos(_at_)santronics(_dot_)com
<mailto:hsantos(_at_)santronics(_dot_)com>> wrote:
----- Original Message -----
From: "Michael Thomas" <mike(_at_)mtcc(_dot_)com
<mailto:mike(_at_)mtcc(_dot_)com>>
To: "Damon" <deepvoice(_at_)gmail(_dot_)com
<mailto:deepvoice(_at_)gmail(_dot_)com>>
> There has been suggestion in the past of the desire for a policy
> for "I sign everything, don't accept a message with *any*
> third party signatures". I've yet to see why anybody would
> want to set such a policy in real life though.
hmmm, Isn't this "highly exclusive" policy just happens to be the most
powerful protection the DKIM protocol has to offer?
If made available, the highest protection, will be the most likely
policy
used... in real life.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com <http://www.santronics.com>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
<http://mipassoc.org/dkim/ietf-list-rules.html>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html