----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
This is not about a "contract signature" becoming invalid. It is
more like a traffic light changing. Transit is ephemeral, so it
should not be surprising that a mechanism related to transit is
ephemeral.
Should the transit time also cover the message being read and
verified by the MUA, and not just the MTA?
The practical application is to ignore such controls once the message has
been received. The MUA verifier consideration doesn't not apply or fit well
with he current expiration semantics. My proposal to use the Message
Reception Time rectifies this situation.
The transit should include a reasonable time for the message to
reviewed by the recipient. This view is consistent with the Threat
document that considers IMAP and POP part of the transport.
There is a basic rule of thumb in sychronization designs -
Do not use Sleeps, Delay or Time considerations
with fuzzy "best guess" values to sychronize
processes or threads. Inevitably, it will give
you problems. The only place this may work well
is in a world of fixed "time" slicing where each
process has fixed residence times.
The best way to design this mail authentication protocol is to eliminate all
fuzziness. Zoom in on your control triggers and events. This make the
protocol interfacing sound and of high quality.
Adding just a simple header that the MDA considered the message valid
at one point raises questions who added the header and removes the
protection to be obtained by DKIM. Until all MDAs strip such
results, these headers offer a method to dupe recipients and
seriously reduces protections being sought with DKIM.
This is a good point.
I actually think that once a verifier has processed a DKIM, it needs pass
this information along.
In addition, in the case our own decades old mail framework, we have two
mail storage modes:
- MIME preservation (Raw RFC2822 "as received" format)
- Conversion to local format (Pure Text, separate
attachment(s) concept)
MUA based verification, whether online or offline will required MIME
preservation, which is a user preference. Offline users usually set this.
Text-based Online users don't. Web-based online users like to set it too,
but also turn it off to avoid HTML based security exploits.
So, for us, DKIM best applies at the transport level, adding a new piece of
header or field information so that the results can be shown to online
users. We would have difficulty to get this information passed to offline
MUAs without modifying them.
I would think this is general design issue for most systems, not just us.
If the desire is to have signatures remain valid only up to the MDA,
then the MDA should replace these signatures with theirs, listing the
domains that verified. Define a tag in the signature that indicates
MDA ownership. This MDA tag should permit long lived signatures, as
then these MDA signatures could not be used to send messages
elsewhere. This strategy would thwart abusive replay of a message
when the signature is replaced. After all, defending against abusive
replay is the _only_ justifiable reason for including the x= tag.
Agree. But we don't want to eliminate the entrepreneur (including
Intrapreneur, for company hot shots) ambitions to write DKIM plug-ins for
MUAs too. :-)
We might need two things then:
- Some result header (Has this message been verified yet?)
- Specify that the Message Reception Time is the
time to use for expiration comparison.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html