On Fri, 2005-06-03 at 22:14 +0200, Frank Ellermann wrote:
Hi, is an op=dkim useful ? It could mean "if you see any mail
claiming to be MAIL FROM user(_at_)domain without DKIM reject it".
For that matter, any other "<something>". This might contribute at a
certain point for people having other extensions, there was a mention of
pgp or habeas in the earlier drafts.
In the current* there is specified an 'unknown-modifier', which does
not get defined in the text, as far as I could find. There is no
'unknown-mechanism' or a description what a SPF client would have to do
with a unknown-mechanism.
"v=spf9 mx habeas pgp -all"
Would only allow mail to pass if they are from the mx, have a habeas
header or validate per pgp verification. The draft does not mention what
to do with the 'unknowns', though one could read between the lines that,
as it does not have a '-' in front of it that 'failing the mechanism',
which is what happens as it does not exist, that it should not drop it.
"v=spf9 pgp -habeas +all"
Would allow anything that is pgp signed, but if it is habeas'd it would
reject it. Habeas+PGP would pass. If the 'habeas' method is unknown it
would also reject everything. Though the above is intended to mean that
only pgp-signed mails with habeas headers should be allowed and not
anything else. But when 'habeas' is not supported, it means a fail and
the mails get dropped, which was not the intention.
(And yes it is a weird example that nobody will ever use, but it could
be that someone find something weird like that useful)
But... can the above be clarified in the draft? As I am assuming the
above and it is not in the ABNF.
The same applies to clients not supporting a certain mechanism for
whatever reason.
Other question, what are SPF clients supposed to do when they don't
recognize the version specified in the TXT/SPF record, should they try
to parse it or simply ignore it?
The SPF RR currently is simply a TXT record with a different type, why
not have a binary RR? Parsing wise this is easier of course, but DNS
packets will be shorter with a binary one:
TXT "v=spf1 a=192.0.2.0/24 -all" would be:
SPF \# 10 01 06 81 18 c0 00 02 00 02 c0
[9 bytes, version = 1, 6 byte mecha {pass + a-ip4, 192.0.2.0/24}, 2 byte
mecha {fail + all)]
26 bytes versus 10 bytes. One can stick way more stuff in the binary
version with ease, at the cost of some expandibility.
First byte is the SPF version, then come the mecha's:
mecha = <pass|fail|neutral in 2bits> <6 bits mecha>
fail = c. | 11......
pass = 8. | 10......
neut = 4. | 01......
unsup = 0. | 00......
6bits, thus 64 mecha's possible
all = mecha #00
a-ip4 = mecha #01 (<pfxlen> <ip ip ip ip>)
a-ip6 = mecha #02 (<pfxlen> <ip ip ip ip .. ip >)
to increase the number of possible mecha's one could maybe move the 2
modifier bits into the length byte.
Unsupported mecha's can easily be ignored etc, though depending on the
draft of course.
Was there any thought on this or?
Greets,
Jeroen
* =
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02pre1.html
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part