----- Original Message -----
From: "Jon Callas" <jon(_at_)callas(_dot_)org>
To: "Damon" <deepvoice(_at_)gmail(_dot_)com>
Damon:
Even if my policy states that it must be signed?
Whoa, whoa. Hang on. A signing policy is something that exists for
the *receiver*. If you get a message that has no signature, your
policy doesn't come into play. The *sender's* policy comes into play.
[Horses Pulled Back! Ducking under flying wrench! :-)]
Isn't DKIM is about the signer, not the sender? Doesn't this mix 2821 ideas
into the picture? Ok, then we do have mixed lookup ideas for bare minimum
(not signature) headers lookup rules?
Why can't we look at the 2822.From: domain?
Ignoring the DNS overhead, should a system look at both?
2822.From:
2822.Sender:
Why bother with the fall back to Sender? How that help support 2822.From?
You are permitted to go out and look at their policy. Heck, you're
*encouraged* to.
We are? Whose policy then? The 2822.From: domain or 2822.Sender: domain?
Jon,
I don't think you really answered Damon's question. We all know local
policy implementations have the final say. That's not the issue. Heck, it
might not even support DKIM at all.
You have a baseline condition of a non-signed message that has to be worked
out. The point is what value does DKIM offer if DKIM-compliant receivers
are not expected to honor the domain's digital signature expectations.
In the absence of DKIM, you have a responsibility to deliver
that message.
No I do not. In a DKIM world, it raises the bar for a new level of
expectation.
In other words, if expect want verifiers to even bother to invest in DKIM,
to consider the scalability and overhead to do DKIM validation processing,
then need to illustrate a payoff, a reason.
What is the payoff?
Now, there is no reason why your mail system can't have a setting
that says to put messages failing SSP in a special maildir. Or to do
some other thing, too.
Yes that's possible, but that has nothing to do with the fundamental
question of how or where do you extract SSP policy information in a legacy
world of mail transactions where there might not be any signed messages.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html