[ietf-dkim] Change to Section 6
dotis at mail-abuse.org
Sun Jan 21 14:21:32 PST 2007
On Sun, 2007-01-21 at 17:52 +0000, Stephen Farrell wrote:
> Charles Lindsey wrote:
> > On Sun, 21 Jan 2007 11:57:57 -0000, Hector Santos
> > <hsantos at santronics.com> wrote:
> >> The statement in question, if anything, which applies to the general
> >> case offline or online mail clients, simply states:
> >> "Delayed VERIFICATION is discouraged after reception of a
> >> signed DKIM message."
> > No, it doesn't say that either.
> > I think that, since this wording is being interpreted in different ways
> > by different peopls, it is a clear case of needing rewriting so that
> > _everyone_ agrees what it means.
> I've only seen one person with a contrary view of this so far. Everyone
> else seems to agree about what it means.
DKIM signatures can be verified by email web-based clients offering
basic capabilities, as well as by traditional MUAs running POP3 and
IMAP. There are already products offering this extended capability.
Any DKIM verification done outside the SMTP session is "deferred".
There is NO reason to discourage "deferred" verifications _especially_
when the verification has _not_ been done by the MTA.
Some MTA operators may establish a basis of verification as being done
_only_ when an invalid signature changes the handling of the message.
Signatures that might alter message handling at the MTA may frequently
differ from those signatures used to establish annotations by end user
applications. Mailing-Lists would an example of such a case.
[In particular, deferring verification until the message is accessed by
the end user is discouraged.]
This statement is _wrong_ regardless of intent, or what it is explained
Perhaps this is what is attempting to be communicated:
| Rejection of messages not having acceptable DKIM signatures SHOULD
| occur prior to acknowledging acceptance at the end of the SMTP session
| DATA phase. MTAs will not always verify signatures serving as a
| basis for annotations applied by end-user applications. Signatures
| that establish message annotations SHOULD be verified, whether
| deferred or not.
| Early removal of DKIM public keys may result in messages not obtaining
| desired annotations when applied the end-user applications.
More information about the ietf-dkim