----- Original Message ----- From: <[EMAIL PROTECTED]>
> 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
