As with most service providers caring about their mail hygiene, I'm very much interested in the ongoing initiatives on sender authentication.
Although the number of MSP's that are having difficulties with mail delivery due to SPF/SIDF, they are still out there. So I was actually planning to use DK(IM) in combination with SPF/SIDF verification.
The idea is to block mails that fail SPF/SIDF verification, unless the message gets a pass from DK(IM). That definetely would decrease the number of SPF/SIDF failures, due to mail forwarders..
However, when actually trying this in a live environment, it becomes clear that most service providers are still using DK, rather than DKIM. Now, I'm not willing to start any discussion about DK vs DKIM here- but I would like to understand the reasining behind IronPort not supporting any DK verification on the inbound, while supporting both DK and DKIM signing on the outbound (even simultaneously in the latest AsyncOS releases). And yes, I know- eventually we'll all use DKIM, but that's the future; not the present.
So in other words: what's the reason for supporting DK signing, when AsyncOS does not support DK verification? :?:
Great question. The mismatch (DKIM signing and validation but DK signing no validation) is a historical artifact of adoption timelines. Here's what happened:
In 2005 we supported DK signing and got great support from Dell, PayPal, etc.
Then in 2005 DK merged with Cisco IIM to become DKIM. Everyone in the community agreed DKIM would be IETF standards track and replace DK. At this point we felt it made more sense to focus on DKIM rather than DK validation since it would be depricated.
We implemented DKIM signing and validation, IETF approved DKIM as a standard.
But some ISPs, particularly Yahoo! and all the ISPs they support mail for, are still on DK. They plan to move to DKIM, it's going to happen 'soon' but we expected this in 2006 and then in 2007.
Today I still believe by the time we would implement DK validation and get it rolled out to the customer base DK signing would be a rarity. In addition no one is working much on DK signature reliability since everyone is focused on DKIM quality, interoperability, etc. It's a missing part of our solution but given all the priorities it's hard to invest in a technology that is being deprecated. We are putting 100% of our efforts on DKIM and SPF instead.
That's how we got here. I think if we had realized it would be 3+ years for certain ISPs and therefore certain senders to migrate from DK to DKIM we would have taken a different approach.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :