In
<C6DDA43B91BFDA49AA2F1E473732113E5DBE0A(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
Another example where SPF syntax comes unstuck.
[out of order reply:]
I don't think anyone can fairly claim that the spf ad-hoc syntax is going to
cope with this. OK you can define ad hoc extensions, but the number of
degree of freedom are huge.
On the contrary, I think that these are cases that can easily be
handled directly with the current SPF syntax.
I don't see any difference between defining extensions as SPF
modifiers and defining new labels in the XML markup.
A domain uses S/MIME authentication [...]
The following information is needed:
* express statement 'all mail is signed'
use the modifier: smime=always
* express the message digest of the signing certificate
use the modifier: smime.certdigest=<location>
* express the algorithm supported.
use the modifier: smime.alg=rsa
Or, just use: smime-info=<location>
Now consider the following complications:
* Also support pgp message format
Use the modifier: pgp=allowed
* express different signing policies 'mail signed when extension
offered'
I don't understand this one.
* handle the TLS protocol
that is handled just fine with the MTA isn't it?
* encryption
use the modifier: encryption=
* different key distribution structures - web 'o trust, xkms, domain
key
use the modifiers: webotrust=<location> xkms=<location> dk=<location>
One could argue that this should be handled by a separate record. But then
we are back to the two parsers option anyway.
No, because the MTAs would not be *required* to support two (or more)
parsers. Many of these options wouldn't require a new parser anyway.
-wayne