Quite simply, they are seeking advice on the variables to measure and
guidelines for deployment and evaluation of such tests.
The big concern brought up to me was that the bandwidth used by these checks
could be more than the bandwidth saved by refusing unwanted mail. So I would
look for these data:
* Total SMTP traffic in bytes, or bytes/second, or bytes/message
* Total MARID traffic in bytes, or bytes/second, or bytes/message
Some things can't be measured directly, such as the traffic between DNS
servers as names get resolved and forwarders do their jobs, but it is
possible to measure one's own DNS traffic.
If possible, I would try to receive all SMTP traffic anyway, so one could
accurately determine any bandwidth saved if a MARID query resulted in a
refusal. I've been told a break-even scenario would be acceptable, barely,
because of the more visible effect of less mail. But I think our chances of
considerable savings (like 20% or more after MARID overhead) are good.
If doing checks after the entire message is received, you'll want to measure
CPU usage, both analyzing and waiting for disk access, or processing a check.
My prior impression was that network speeds were orders of magnitude slower
than CPU and disk speeds, so they didn't make a difference. After reading
these documents however, I would pay more attention to them. I'm sure we
could get a proper feel for that by running MARID on a Pentium 133 running NT
4.0 and the old EMWAC IMS mail server, for instance.[1]
[1] Don't laugh. They're already writing MARID plugins at
ims-users(_at_)rockliffe(_dot_)com(_dot_) And I used to host a 2500-user mail
server on that
kind of machine very comfortably. If you want to impress me, run MARID with
low overhead on that kind of machine.
--
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>