william(at)elan.net wrote:
On Sun, 17 Apr 2005, Radu Hociung wrote:
william(at)elan.net wrote:
On Sun, 17 Apr 2005, Radu Hociung wrote:
How does this dk= modifier "modify" SPF results, if at all ?
None of the o* modifiers have any effect at all on SPF results. The
SPF client should simply relay their contents to the MTA. If the MTA
knows what to do with them, fine, otherwise, just move on.
SPF can serve as basis for more general list of sender policies, but we
have to be clear that those modifiers in no way effect results of SPF
system itself. As such such modifiers can be introduced with separate
technical documents but MUST NOT be introduced by SPF specifications
Please explain what you base this conclusion on.
SPF defines syntax of the record. It also defines how to distinguish domain
policy for certain identities (mainly RFC2821 mail-from) and decide if
that policie's success or failure. If we have identify that some other
type of specification is using or some other type of algorithm its fine,
but its NOT SPF and its results are on different identify and as such
do not effect results of SPF, so while its ok for it to decide to use
SPF record as policy specification (as long as that does not confilict
with spf record syntax), its not for SPF to specify it, but for some
other type of specification.
This is best I can explain it because you really have to have read
number of protocol specifications to see that is how its done so as not
to create conflicts. And btw - this is generally a technicality that has
to do when you want to separate something into separate different
document, i.e.
its not exactly as if SPF community can not work on something other then
SPF but if we do, we should release such work separately from spf specs.
I see. Thank you.
I'm not 100% convinced, maybe 60%, but I understand your position. I
need to do more of my homework on whether the SPF spec is the best place
for the o.*= modifiers or elsewhere. I'll be sure to make more noise if
my homework points to the SPF spec as being the appropriate place. I'll
be quiet on the topic otherwise.
Nonetheless, I find the discussion here valuable, as it tells me if the
community sees the value in the "others" functionality or not. It's also
a good sanity check for me :)
But for this example, let's say that the domain owner publishes an
odk=yes extension. As I have shown above, it makes no sense the SPF
record to specify the location of the DK record, but perhaps only it's
existence.
In this case, say that the recipient MTA gets an SPF result of FAIL on
their check of the MAIL-FROM. The SPF checker passes the
spf_also_found["dk"]="yes" to the MTA.
In order to decide whether to reject after the SPF fail, or to give it
one more chance using DK, it may use any other information it has
available. Perhaps the RCPT user is known to make heavy use of
forwarders, so a lot of his mail gets FAIL SPF results, even though it
is legitimate.
At this point the MTA may decide to receive the message anyway,
instead of
rejecting it right away due to the SPF fail. Then it would decide
whether the message is authentic if it finds a DK signature and if the
signature checks out.
No, that would be very bad idea. SPF and DK operate on different layers
of mail transmission and failure of one of them is just that failure, it
has nothing to do with failure or success of authentication in another
layer
(unless we agree to change email architecture and restructure separation
of 2821 and 2822 layers). If you allow authentication in one layer to
effect
results of another, you effectively create a security trap which can
have very negative consequences in the future and will be extremely
difficult to fix (a lot more so then when you have problem in only one
layer).
Please explain the nature of the security trap.
In my explanation, DK's result did not affect SPF's result and vice
versa. I recognize that they are different layers and can operate
independently of each other.
I consider a message that that FAILs the SPF check, but passes the DK
signature check a message that should be delivered, subject to
subsequent the spam evaluation.
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.
I thought exactly the oposite was true, ie, SPF does not dictate whether
the MTA accept or reject.
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.
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.
As far as security trap, in general sense it makes it possible for
somebody to invent an attack on security system and such attack would
compromise both layers. Result is that if you begin to trust "pass"
result of such system when one of the layers is failure, the bad guys
would eventually find way around it and it would cause more damage.
You're partially
In the case I showed, allowing a second chance for some messages means I
consume more bandwith by allowing the SMTP conversation to go into the
DATA phase.
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.
Can you give another example where using more than one policy input in
the decision making is causing a security trap?
This is the typical case of a genuine message from Yahoo that goes
through a forwarder.
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.
SPF IS NOT SPAM FIGHTING METHOD
SPF can be used as means to prevent spoofing, but that does not mean
that
success of spf has any implication that message is spam or not.
Thank you for reminding me what I hadn't forgotten.
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.
But personally I don't believe this to be true. More opinions on this
issue would be welcome. :)
Where the usefulness of the extension is most clear is when SPF3 gets
published and starts being adopted. Let's assume that SPF3 operates on
the message headers.
Lets not assume that unless you have reasons to believe that it would.
Here's where you started an irrelevant monolog.
I did not say that SPF3 is a successor to SPF1, nor that it replaces it.
Yet, the spirit of your following comments makes this assumption.
Actually if you call it SPF3 that is exactly what is implied - that SPF3
is successor to SPF1. Now that you clarifed that it would not be in the
way you saw it, I ask you to stop using the name "SPF" for whatever you
have in mind and call it something else in all your posts (which is
exactly what you do below, thank you).
You should either address my comments under the assumption I have
stated, or prove my assumption wrong. Otherwise we're not talking about
the same thing.
In hindsight, I should have used FPS1 instead of SPF3, to indicate a
future standard that is largely unrelated to SPF. I thought my
assumption that it operates on headers and that it publishes some
signing key was enough to make this clear. Mea culpa.
Thank you for clarification. I hope you don't mind but to make it clear
we're not talking about future SPF, I added "[FPS]" as part of subject
line. I would appreciate if you do the same when you write additional
posts on this list which have largely to do with "FPS".
Ok.
BTW - what does FPS stand for?
"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.
The FPS1 protocol may very well be the open-source equivalent of DK.
I don't know what the future holds, and I'm not willing to make the
assumption that only an SPF-like protocol is possible.
Good assumption :)
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.
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.
1. Why use DNS for such record at all
Easy, effective.
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.
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?
I call "top-level TXT record" the TXT record at the mailbox-domain
level. This is the equivalent to the TXT record at %{o}. Perhaps
"mailbox-domain TXT record" would be a better name?
I think most of us understand what you meant by "top-level TXT record".
Personally I usually call it root of the domain tree for given domain.
Ok, I'll stick to "top-level TXT record" then.
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.
Thanks,
Radu.