Hallam-Baker, Phillip wrote:
Another example where SPF syntax comes unstuck.
A domain uses S/MIME authentication in addition to IP based auth. This
S/MIME != MTA Authorization. S/MIME only deals with DATA contents, which can
be identical from authorized and unauthorized MTAs. There is no reason that
MARID should have anything to do with S/MIME. Thus, there's no problem with
SPF syntax not supporting S/MIME.
allows a mail message from a bank to display the logo of the bank in a
privilleged part of the display by means of the X.509 logotypes extension.
The following information is needed:
* express statement 'all mail is signed'
* express the message digest of the signing certificate
* express the algorithm supported.
Someone should definitely write a standard for expressing that in the DNS.
However, that doesn't appear to be in scope for this group. I haven't read
the Yahoo DomainKeys proposal, but isn't that exactly what it deals with?
Now consider the following complications:
* Also support pgp message format
* express different signing policies 'mail signed when extension
offered'
PGP and content-signing have nothing to do with the MTA, same as S/MIME.
* handle the TLS protocol
TLS is the only piece of this that I can see as being related to MTA
authentication or authorization. How about a new mechanism in SPF syntax,
'tls', that specifies the fingerprint of the certificate that the sending
MTA will present, or of a CA cert that signed it? Then SPF doesn't need to
specify IP addresses any more, since you could express "all mail sent by a
server with this cert is from my domain, regardless of where it is
connecting from".
If you meant "the connecting IP is part of a given set, and it uses TLS with
a certain certificate", then I don't think any of the existing proposals
cover that. Even if they did, what is the use-case for it?
* encryption
Whether it encrypts or not has nothing to do with authentication or
authorization.
* different key distribution structures - web 'o trust, xkms, domain
key
Again, not relevant.
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.
Many of us opposing a heavily extensible syntax want to limit that freedom,
for simplicity of implementation and ease of deployment. Very simply, I
don't want SPF ad-hoc syntax to deal with this, because it's not relevant to
the goal we're trying to reach of authorizing the MTA, and not the data the
MTA is sending.
This is not a theoretical proposal. The use of signed mail is already under
serious discussion in anti-phishing forums.
Good, but it should be independent of protecting domains from MTA identity
forgery.
One could argue that this should be handled by a separate record. But then
we are back to the two parsers option anyway.
Two parsers, yes, but neither dependent on the other. One could check that
the connecting MTA is authorized without checking the signature on the
message it sends, or vice-versa, or both.
It took me less than half an hour to write a schema for this application in
XML. I don't think anyone could claim to write a parser for a corresponding
SPF syntax in the same time.
No one needs to write that parser for SPF, because it's already written. In
Perl, C, Java, and Python. From implementation code that I've looked at, one
needs to be able to make a single function call into any one of those
languages to check whether a connection is authorized or not.
Philip Miller