Re: [ietf-dkim] A more fundamental SSP axiom

[Michael Thomas <[e-mail]>]

John L wrote:

>>> I don't see the point.  That last suggestion is, to the recipient, 
>>> the equivalent of a useless "I sign some mail" since you're telling 
>>> the recipient it's OK to accept some amount of both signed and 
>>> unsigned mail.
>>
>
>> For us, the amount of mail that is in the false positive quandry is 
>> really really small, though the people it would effect primiarly are 
>> people who could make it a living hell in IT. A policy which is more 
>> relaxed could, however, say that it's well worth the effort be 
>> extremely cautious about such mail -- a far higher barrier to entry 
>> than the current one-size-fits-all filters.
>
>
> But you're talking about your own mail here, for which I expect that 
> you have all sorts of special treatment.


No, I'm concerned about how others will treat it. I don't have to publish a
policy to differentially treat that mail for myself.

>
> I'm trying to think about what I'll do when DKIM is in wide use, I get 
> mail from thousands of sources that publish SSP info.  If SSP says "I 
> sign everything" I have trouble figuring a use for it other than a 
> flat reject of unsigned messages or at least 4.9 points in a five 
> point scoring spam filter.


That's the problem: if you do that, domains like Cisco -- or anybody else
who uses mailing lists -- will *never* publish a "we sign everything" policy
even though we do. I hardly think that Cisco is a outlier here, and in fact
I expect that we'd be pretty similar to just about any medium to large
sized business.

>   I REALLY do not want an SSP that says "I sign everything, and here 
> is my estimate on a 0 to 10 scale of how much you should care."

I assume that you'd complain if it boiled down to a single bit?

0: "mail from this domain may transit manglers, adjust accordingly"
1: "the signature should always be intact"

       Mike
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html