Lets see it that way. You may use spf as poorly a partial policy
analyzer for spam filter (in which case its not really SPF as it does
not recorgize SPF fail or success and just uses the result in its own
heuristic algorithm). However if you decide to use SPF as its defined
by SPF specification, then expect not to mess around with results and
make it depending on some other specification.
It sounds like you are suggesting the SPF specification dictate what the
MTA should to with the results of an SPF check.
Read SPF spec
I thought exactly the oposite was true, ie, SPF does not dictate whether
the MTA accept or reject.
Wayne, Julian, Mark? Want to take this on?
Also, I thought the reasoning behind the position as I understand it was
that since there are so many forwarders, it's not quite safe to reject
based on FAIL, and since spammers do publish SPF, it's not safe to
accept based on PASS, either.
You've missed the discussions for last couple years, right?
Again I would advice you to see it from the perspective that SPF is not
an anti-spam technology. If you're able to do it you'll understand that
SPF wants/needs to find way to deal with forwarders (that is why there is
SRS) and that it's ok and even good as far as SPF is concerned if spammers
begin to use SPF - they're then identifying themselve and not forging
somebody else's domains for bounce address and that's what matters!
I even proposed a couple of weeks ago a method on how the SPF results
should be used to help with filtering spam. I got a few nods and even
congratulations, so I must conclude that at least I'm understanding ok
that SPF does not directly dictate what the MTA must do.
There is a great misunderstanding as a result of how SPF is being marketed
as to what it's for. As a result number of people came here expecting to
find FUSSP and when they did not and they find that SPF can't even be
safely used for rejection at current stage, then they are listing to
what you and others propose for their spam filter. However I'm not
entirely certain the core of SPF Community (those who believe in rejecting
based on SPF right now, see lots of threads about it...) are even listing
to what you proposed, I only did because you started using name SPF3 in
completely inconsistent specification ideas.
However, I don't see this specific example as a security trap. Instead,
it just makes is more expensive (bandwidth wise) to accomodate one user
who makes extensive use of SPF-challenged forwarders.
There is no specific example as far as SPF is concerned at the moment.
This is a core concept of security systems design - you don't make a hole
in specification by relaying on separate layer, because when you do you
severely weaken your security system and make it possible to break it.
These kind of errors in judgment are the reason why we saw so many
security holes in Internet Explorer in the last 5 years - Microsoft also
did not understand it when it went after user features. Worst of all the
errors and abuse usually does not happen immediately but only after few
considerable time and deployment (that is why I said its hidden trap-door).
And as long as yahoo does not make some serious changes to DK it would
not be good for anything but whitelisting.
They would say the same about SPF with respect to forwarders.
Of course and they would be right. In current situation with email neither
system can safely be used by large number of people for anything but
white-listing.
So perhaps it is wrong for SpamAssassin to be involved in any way, and
to provide any support for SPF? As far as I know, SpamAssassin is a spam
fighting method.
See above as to that while it can be used as part of spam filter, this
would not be according to SPF specification. This is not to say that
its good or bad, its just not what SPF proponents are trying to push
spf for (as far as standards protocol specification and its use).
Ulitimately you would want spamassasin and similar run already after
authentication success (and authentication failure would not cause it
called at all) and not be dependent on it, so spam filter would stay a
spam filter and SPF would stay as email authentication technology.
If this is true, then I would request the SpamAssassin developers to
remove their SPF support, as their use of SPF conflicts with the SPF
specification.
It does not "conflict" and its better then nothing at all, but its also
true that they can't advertise that Spamassassin fully supports SPF or
that if you use Spamassassin you don't need to install SPF checking
extension for your MTA.
"Frames Per Second", "Formal Policy Selection", or "Fictive Protocol for
Security". It's really just SPF backwards, not a real protocol that
exists or is yet planned.
"Fiction in Protocol Specification" ?
Or may I suggest you find a name for what you have in mind fast and for
now call it "RADU1"...
BTW - If you want "open source" equivalent of DK that operates on headers,
I kind of already developed it, see http://www.metasignatures.org.
There would be some additional changes to specification & syntax soon to
address some comments and make its syntax even more externdable for the
future. The implementation will largely depend on some other work, but
at least EDigest library will be released over the summer.
That may be useful one day, especially if it doesn't suffer from the
same drawbacks as DK. Ie, it would be sweet it it didn't use anything
from the DATA phase.
It can deal safely with majority of the cases where DK fails, its all up
to the sender really how "safe" does he/she want his signature to be...
As for the "DATA phase" its all part of that works on RFC2822 message
content (you remember what I told you about not mixing RFC2822 and RFC2821
layers, right?), so it actually needs the content and that means "DATA phase"
However unlike DK, META Signature can be verified immediately after the message
header data has been received, which makes it possible in the future to
separate header data sending from the larger part of message body data.
So, please re-evaluate your response in light that the new protocols I'm
trying to provide for are NOT related to SPF in any way, other than that
they also need to make use of the TXT record space at the top-level.
And would you mind explaining why exactly you want to use same TXT record
space? This question might have to be partitioned into the following:
I suppose the exact same questions should be/were asked of SPF. Then I
could just cut and paste.
Initial SPF specification was being constructed with convenience of initial
user in mind and something that could be used the fastest. These questions
however continue to be raised on the spf-discuss list at regular times as
you can see from discussions about putting spf record in the
prefix/subdomain, using SPF specific record type, using binary
pre-compiled record, etc. So basically its still something that yet to be
addressed in full by SPF community...
1. Why use DNS for such record at all
Easy, effective.
Want a elaborate? How about answering first about what DNS is good for
and what is this type of system most effective and what records it works
best with. Then you can compare that against against record you have in
mind to see if its a good fit for it.
Otherwise I could argue that its better to go with ldap or xml-beep or
xml-soap, etc. Its not as easy decision for any protocol as you think.
2. Why should it be at the "root" of the domain tree (you call it
top-level)
and not subdomain
Because anywhere else would be create "DNS hunting", and thus not a good
idea.
You might not full understand dns if you say something like this. There is
no reason to "hunt" if you specify exact subdomain (prefix). After all
there is no hunting with various SRV records, are there?
3. Why should you not use its own record type
Need fast, wide adoption with minimal work. Just like SPF ;)
:)
4. Why using text as specification for your syntax is not better then
pre-compiled binary specific to your needs
Good one. Why doesn't SPF use a binary format?
Human readability. The question is are you expecting that program must
be used to create the record or do you allow person to do it directly
and is it possible for human to do debugging manually, etc.
For identity records involving cryptography, you would end up using
program anyway so this reason is not relevant there (that is why DK's
(ab)use of text does not make any sense, entering dns records there is
not the same as case of SPF).
BTW - if you call it "mailbox-domain", then you have to also specify
which mailbox, i.e. exactly which mail identity (it can be
rfc2821.mailfrom, rfc2822.sender, rfc2822.from, etc).
That would create more confusion that necesary.
Actually its the most important question you have to answer! And by not
answering its exactly what is creating a confusion!
P.S. Its probably my last post on this thread, I don't have time to
explain some fundamental protocol design concepts or go through SPF
history at the moment. I would recommend learning more about how spf
was created and what for (look though archive, etc) as well as learning
about other proposals under discussion in email area (see ASRG) as well
as just reading security related RFCs, such as ones for S/MIME or IPSEC.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net