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 <mich...@talamasca.ocis.net> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html