On Apr 11, 2006, at 7:46 AM, Michael Thomas wrote:
Paul Hoffman wrote:
If MUAs are not supposed to be validating messages, then we need
to change the -base spec in many places.
You can't have both ways: either signatures are valid essentially
forever -- which is what would be required for MUA's to reliably
validate signatures -- or they aren't.
Signatures can be verified for as long as keys remain available.
That period must be long enough for recipients to examine their
messages. DKIM evaluation can occur at the MDA _and_ the MUA.
Ensuring verification at the MUA expedites use of DKIM. Otherwise,
DKIM is little better than some header claiming a message is okay.
No MUA can trust such headers without perhaps burdensome out-of-band
assurances about the MDA.
MUA's that happen to be able to read the message within "transport"
time are perfectly at liberty to validate messages -- no
restrictions at all.
But that's a much different proposition than saying that they will
be able to validate them whenever they get around to reading them.
Verification takes place at the MUA as part of the transport period.
Per the threat draft:
,---
| The transmission of messages via SMTP, defined in RFC 2821 [RFC2821],
| and such elements as the envelope-from and envelope-to addresses and
| the HELO domain are not relevant to DKIM verification. This is an
| intentional decision made to allow verification of messages via
| protocols other than SMTP, such as POP [RFC1939] and IMAP [RFC3501]
| which an MUA acting as a verifier might use.
'___
The transport could be to an ocean going vessel connecting via a slow
radio link where communication requires clear weather. DKIM should
operate even with longer transport times, including the transport to
the MUA. Hector suggested expiry evaluation at the MUA should be a
comparison with the Received header time.
That is not the problem we set off trying to solve.
What problems are created by the solution?
Should message acceptance be refused when expired and signed by an
domain that signs all messages?
How does the receiving system ensure a flood of DSNs is not created
up stream as a result of adhering to this policy?
How would an upstream system ensure a down-stream induced flood of
DSNs is not created?
What expiry time should remain before accepting a message, assuming
there may be down-stream handling?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html