----- Original Message ----- From: "Steve Atkins" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, July 26, 2006 4:28 PM Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy options
> That's not a reason not to add support for this to SSP, though, > as long as you recognize that it's just adding a redundant > way of saying the same thing at the cost of a small increase > in complexity and risk of contradictory policy messages > via different communication channels. I'm sorry, did you think I was suggesting to add SPF to the DKIM/SSP mix? If so, I was not. I think DKIM/SSP should be an independent payload technology with only one common ingredient 822/2822 + DNS and for the most part 821/2821. How ISV and operators will augment separate ideas is up to them. AltaVista.com illustrates this with support for SPF and MX 0 to cover a "No Outbound Mail Expected" and a "No Inbound Mail Expected" policy, respectively. Keep in mind that the current SSP checks calls for only checking an SSP iff the signature fails. Although, I believe the more efficient model for the verifier who will need to deal with the DKIM blitz of high potential failures is to check for SSP immediately, I suggested that this logic be changed, at a minimum, to a failed 3rd party signature. But that could be an ISV implementator detail and not necessary part of the specs. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
