On Fri, 2006-09-22 at 07:48 -0400, Hector Santos wrote:
>
> I would rather use direct correlations and real operational history
> based on similar concepts such as SPF, to have enough insight to see
> history will repeat itself here with DKIM using neutral policies or NO
> SSP (therefore NEUTRAL by default).
Most major ISPs request neutral handling when their SPF records do not
match the client. For some this was not good enough, and they even
requested positive handling.
While reasons for a DKIM signature failure will be different, they will
persist just as they have with SPF. If history offers guidance, it
would be to NOT request handling except in exigent situations.
When approaching such policy, offer a 100 foot pole. Allow exigent
situations to be clearly asserted such as "I sign all messages and avoid
services that might break signatures," and the 100 foot pole that
asserts "I sign all my messages, but my users take advantage of services
that are likely to break these signatures."
Even when the 100 foot pole often induces neutral handling, some may
attempt to condition handling based lists of unfriendly services. If
history is to offer any guidance, expect most to avoid delivery issues
that require continuous support to resolve.
One area that seems missed is that the 2821.MAIL_FROM would be benefited
by being able to assert a policy separately from that of the 2822.From
or perhaps even a 2822.Originator. This is where policy can play two
roles. One that offers associations, and the other that might illicit
negative handling.
To associate with any number of domains:
query-label = base32(sha(signing domain) + crc(signing domain));
The reason for two hashes may be overkill. This is to ensure an
extremely low possibility of a collision. The query domain will be
asserted within the resource record, so even an unexpected collision
will be properly resolved unless there is a desire to publish a policy
for both. : (
The query would be:
query-label._dkim-xx-policy.<domain of email-address in question>
The synthesis of the response could be:
*._dkim-xx-policy.<adr dom> RR "a:adr dom; f:A:O"
_default._dkim-xx-policy.<adr domain> RR "a:adr dom; f:A:O"
query-label._dkim-xx-policy.<adr domain> RR "a:adr dom: sig dom; f:A:O"
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
