Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joi

On 27 Sep 2010, John R. Levine wrote:
> I hadn't realized how many medium-sized MTAs do their DKIM during the
> SMTP session.  You learn something new every day.  It still sounds like a
> design that *requires* that an MTA do DKIM at SMTP time would present a
> problem for some mail systems too large to ignore.
If DKIM and ADSP had been invented ten years ago, perhaps
post-transaction validation would have become the norm.

But some time ago, spamfighters (who have been driving MTA software
innovation) became deeply troubled by the fact that content-level
spamfilters such as SpamAssassin could only be used in a way that either
generates backscatter or causes false-positives to simply vanish.

So, by lobbying and contribution of coding effort, they've pushed the
dominant MTAs to structure themselves so as to be able to do significant
analysis during the moment between CR LF '.' CR LF and its reply.

It does break the intent of the RFCs, which expressly demand minimal
delay at that juncture to avoid duplicate messages, but we don't care.
Duplicate messages are far less horrible than backscatter.

Anyhow, with that infrastructure in place, DKIM checking is trivial.  At least
message hashing can be streamed.  We don't need to wait until CR LF '.'
CR LF to *begin* analysing.


Oh, and in any ADSPbis, I would like to see a flag that forbids silent
discard but permits in-transaction rejection.

---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html