On May 28, 2009, at 8:23 AM, Dave CROCKER wrote:
Michael Adkins wrote:
What is the basis for requiring it to be external.
Where the signer wanted reports about the message to go at the time
the
message was sent is not relevant. Where the signer wants the
reports to
go at the time the report is generated is relevant. It is common for
there to be a week or more delta between sending the message and a
user
submitting a report. There is many a slip between cup and lip.
Oh.
Interesting point.
Anyone disagree with it? If so, how and why?
It's a design decision. The approach Michael suggests is exactly what
you're going to want to do for peer IP-based FBLs, and doing it the
same way seems a perfectly reasonable implementation choice for signer
identity based FBLs, but I don't think it's the only reasonable choice
for FBLs based on self-publication by the signer (assuming there's any
value to them at all, which I'm not entirely convinced by).
A counter-argument would be that an FBL is a way of responding to the
sender of an email about that email. It's very siimilar to the Reply-
To: field, the envelope from or the links in the body of the mail, and
they all seem to work perfectly well as values set at the time the
message was sent.
The presence of a header field that is signed does not guarantee
that it
was placed there by the signer, merely that it was present when the
message was signed. It therefore does not provide a mechanism for
verifying that the requested destination address is authoritative for
the domain.
Yup.
It depends on the way a DKIM signer chooses which headers to sign.
If the signer will sign any headers you give it, rather than having a
list of headers it chooses to sign, then you're right.
If, on the other hand, it only signs a list of headers that it knows
about then you would know that if you saw "My-Fun-Header" signed that
it was done so with the knowledge and permission of the domain owner -
as by signing it the signer asserts they know about it, and they're
either adding it themselves or permitting their users to add it.
Unfortunately the DKIM spec is pointedly vague on which approach to
use, so while most of the implementations I've seen use a fixed list
of headers, that's not something you can rely on as a general mechanism.
Oops. Right. I keep raising the same point about whether contents
are validated
by DKIM. Sigh.
So, there's a Pandora's box that this raises, which is how to use
DKIM in a way
that has the semantics of claiming that bits of contents are in fact
valid?
Can't do it as currently specced, I don't think.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html