On Mon, Sep 27, 2010 at 11:39:43AM -0700, Dave CROCKER allegedly wrote: > > > On 9/27/2010 11:04 AM, Murray S. Kucherawy wrote: > >> From: [email protected] [mailto:ietf-dkim- > >> [email protected]] On Behalf Of John R. Levine > ... > >> It is not my impression that they all do the full DKIM validation while > >> the SMTP session is open. Mine doesn't. > > > > The milter-based ones like OpenDKIM and dkim-milter do. > > > It's been a significant revelation, for me, to realize how common it is for > DKIM > processing to occur during the SMTP session. > > So SMTP issues reduce to finding ways of preventing the cross-net transfer of > data or even of preventing the SMTP session. Oddly, I think the latter is > more > feasible than the former.
So is this a premature optimization discussion? In terms of the big guys, it's a complex question as it depends on what other processing occurs at SMTP time, such as AV and anti-spam and *where* that processing occurs (on the SMTP socket machine or somewhere else). Most big guys will have mail processing distributed across multiple systems during the SMTP session. All the big guys have an ideal location (or the only realistic location in some cases) where they did/or-will install DKIM processing and that will likely vary from player to player. The smart ones might even do some processing in different places dynamically depending on the current load of each piece of infrastructure. Frankly I think that the decision of where a big player does processing will be driven by their infrastructure and internal design far more than any tweaks to a standard or set of recommendations we might make. Even if we knew what they all did today, there is no reason to expect that will remain unchanged for any substantial period of time. As an aside. Just looking at the simple metric of holding times of an SMTP session, the biggest cost typically comes from slow clients rather than the CPU latency of processing a DKIM signature or anti-spam content analysis. Mail from remote ISPs in countries with constricted connectivity can often trickle in at 1200bps-type speeds. Mark. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
