----- Original Message -----
From: <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
Sorry,
Should have been clearer.
Bad guy sends a message purportedly from cox.com with a header
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=cox.com
The non dkim compliant mta who hasn't deployed dkim yet or knowing
much about it places a rule stating that signed messages should be
allowed to travel inbound without further checking because dkim is
new and safe.
A dkim compliant mta will do a dip on my dns records and find no
ssp or dk record and drop the message as non compliant.
I suspect that in the beginning there will be a lot more of the
former than the latter.
I agree, and history has already proved this with SPF and it migration
recommendations which suggest that SPF policies can be defined first
(for others to use) before the SMTP servers actually support it for
inbound mail. This is a big part reason for the SPF forwarding and
alias mail problem.
I also suspect the same with happen with DKIM. There is no reason to
suspect otherwise. But it can worked out with a sound DKIM migration
recommendation based on its EXPIRATION concept (which SPF lacks).
But I agree with you overall. Policies will most likely be defined
first.
This is especially the case with DKIM since software requirements is a
bit more complex.
With SPF, the implementation issues was clearly highlighted with POST
SMTP (easier to plug and play) vs. DYNAMIC SMTP operations (some skim,
hook system required).
The easier POST SMTP implementation promoted bounce attack issues for
SPF. This is alleviated with a DYNAMIC SMTP response system.
Same with apply with DKIM implementation decisions - post vs. dynamic.
From my perspective, the concern with POST SMTP systems is that it
promotes a higher level of unreliable deliverables; i.e. POST SMTP
analyzers are not sure what to do with the "suspicious mail." But to
avoid bounce attacks, it dumps it.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org