My dream SMTP server has a GUI reminiscent of the control room at a power plant, with gauges which show every parameter which might be important to the operator, and with valves to throttle or completely shut down any segment of the operation which seems to be getting out of hand.
I'm thinking web-based, but yeah, that would be nice.
Parameters such as the following would have both gauges (and/or warning lights and whistles) and values (operator-settable limits):
total incoming messages/(unit time)
1. This can be a simple mailet... just log the size and time (other info?) of every message that comes through. Then have a reporting tool to pull over some time period.
total incoming connections/(unit time)
2. Hmm, this would need to tweak the SMTPHandler to do this.
total incoming bytes/(unit time)
3. Same as #1
total outgoing ... (the same three as above)
4. Perhaps just another mailet, this time though logging what goes through the outgoing spool.
total volume of mail held in local mailboxes
5. This would have to be (an expensive) query done ad-hoc. I can't see maintaining that as meta data.
total volume of mail held in local spools
6. Same as #5.
ip addresses generating most of the traffic/(recent unit of time)
7. Relates to how #1 is logging and reporting. Shouldn't be too difficult.
ip addresses generating most of the connections/(recent unit of time)
8. Same as #7.
local addresses receiving large quantities of mail
9. Another type of mailet, this time in local delivery spool.
local addresses sending large quantities of mail
10. Extra report on #9.
Also, another approach, I would prefer to have the server return an error upon RCPT TO: <unknownJoe>, rather than accept the message as James does at present. I think Noel said there were plans to change this in an upcoming James.
11. Yes, I think that's something that's coming.
Most of this is only 1 logging mailet that could get plugged into a number of spots in the different spools, and then you'd need a reporting tool to read those logs and give you nice data. Someone had talked about adopting a "standard" logging format for James, which might get much of this done just by relying on existing reporting tools that unstandard that log file format.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
