The question of network overhead and impact came up early on. If the cure to
forgery is more network-expensive than the disease of forgery, no one's going
to implement it. Early numbers suggest a considerable savings but bad design
decisions now could reduce that savings or eliminate it.
We need to measure the impact, but what to measure? I wanted to get the
question out early, especially as Meng, Harry and Jim draft a document to
combine their proposals. What can be measured? Where should it be measured?
And how do we measure it?
These things immediately came to mind:
* Outgoing network bandwidth querying MARID
* Outoging network bandwidth responding to MARID queries
* Incoming network bandwidth receiving MARID responses
* Incoming network bandwidth being queried for MARID
* CPU overhead transmitting, receiving, and parsing MARID
* Count of MARID responses (number accepted, number rejected, number unknown)
* Perhaps where in the SMTP conversation a MARID response has an impact? How
often does it stop mail at 2821 or 2822?
* Count of specific entities being queried (a particular network address? A
particular e-mail address? A range of either?)
What else?
With these and other data already collected (or collectable) in the SMTP
conversation we can determine:
* Percent bandwidth cost, or savings, compared to message traffic, leading to
decisions for upgrading or cost-cutting, or changing the spec to reduce
bandwidth
* Percent CPU cost or savings, leading to CPU, RAM or disk space decisions,
or changing the spec to reduce CPU overhead (it's nice to use built-in XML
parsers... if you have them... like assuming everyone has perl.)
* User impact, if we can get the user (notably the sender) to provide
feedback. Maybe it's possible to measure "false positives" - if early
versions allowed sender feedback, as in: "Hey! This should've gone through!"
* Comparison of impact at different stages of SMTP - more 2822 blockings
could mean a problem in 2821 parsing
* if a major forgery run was in progress, or if there is a DNS problem, from
spikes in rejection counts
* If a major forgery run was in progress, the networks or people being
queried about - useful for investigations
Probably lots of other useful stuff.
I know that writing performance counters is an implementation issue, but
pointing out places where they could go and what they should count in the
flow of things would help implementors. In final implementations, sysadmins
really do watch these, especially when users complain.
--
PGP key (0x0AFA039E):
<http://www.pan-am.ca/consulting(_at_)pan-am(_dot_)ca(_dot_)asc>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>