You may experience some slow load times, errors, and slight inconsistencies. We ask for your patience as we finalize the launch. Thank you.
Welcome to Cisco Support Community. We would love to have your feedback.
I am running 4.5.6.
The MFM numbers seem to be high (even though they are now a little less since my upgrade from 4.5.5 to 4.5.6).
If I click on a domain listed in the detail of MFM I notice that the detail numbers are not the same as what is on the first page.
For example, domain abc.com is listed on the MFM screen as:
15 stopped by Rep
When I click on the domain the domain page reports:
Note these are both for the past hour.
I also noticed the numbers in MFM do correlate to the numbers for the same period via MFC?
I need to give some numbers to management and don't want to overstate the numbers.
A multiplier is used on the overview page for number of messages blocked by reputation. From the ironport manual:
"Notes on Counting Messages in Mail Flow Monitor
The method Mail Flow Monitor uses to count incoming mail depends on the number of recipients per message. For example, an incoming message from example.com sent to three recipients would count as three messages coming from that sender.
Because messages blocked by reputation filtering do not actually enter the work queue, the appliance does not have access to the list of recipients for an incoming message. In this case, a multiplier is used to estimate the number of recipients. This hard-coded multiplier was determined by IronPort Systems, Inc. and based upon research of a large sampling of existing customer data."
There seem to be discrepencies in the reporting based on what report you use. Some of this appears to be due to "messages" that aren't counted for some reports but are for others (example: system alerts, system reports, undeliverable notifications) and the multiplier that IronPort uses on some of the reports.
Also, I would open a case with IronPort if you are having trouble with the reporting.
Supposedly the Stopped by Reputation Filter has been wrong since December last year.
Though I doubt you could ever really call it accurate given the fudge factor...
So Ironport is purposely skewing the numbers to make us think their device is more important and more effective then it really is?
I would just like fairly accurate numbers that don't require me to manually create reports and SQL statements....is that too much to ask?
FYI, I use MFC, but it useless when it comes to summary data.
Hey all, I'm in charge of Reporting here at IronPort and I wanted to try and answer a couple of questions that came up in this thread (last question first):
Regarding the multiplier for "Stopped by Reputation Filter", it is currently set to 3 recipient-messages for every connection rejected. This number was determined based on an analysis of multiple enterprise log files where we found that each blocked connection usually resulted in 1.7 SMTP DATA commands, each with 1.6 SMTP RCPT commands. 1.7 x 1.6 = 2.72 but we had to round the result to avoid floating point math. We've had requests from customers for the ability to change this multiplier (both up and down), and so we're making that possible in our upcoming 4.6.0 release (in final qualification now). I'm unaware of any accounts that "Stopped by Reputation Filter has been wrong since December last year", but if you have specific questions please feel free to contact myself or Customer Support.
Regarding the numbers presented in MFC vs MFM, they currently /are/ different because they are reporting on different things. MFC is counting SMTP DATA commands as a message, while MFM is counting SMTP RCPT commands. We made this change because a number of customers wanted our reporting to more accurately match the accounting for "items" that were going into their backend Exchange and Notes servers. You can retrieve counts of SMTP DATA commands from MFM through the reporting API, but due to the fact that its possible for a single SMTP message to be split and modified in many different ways, our counters for spam and virus detected are all recipient based.
And finally, for the possible discrepancies in the top-level MFM report vs the detailed domain report, these numbers should correlate, so there may be an oddity on your box, or a bug somewhere that we need to fix. Please open up a ticket with Customer Support so we can retrieve the necessary data and figure out what's going on.
When we did a detailed analysis of the average number of recipients per email, our data averaged to 2.86. This was looking at millions of emails per day for a week, so the default of 3 works for me, although, I can see where it would be nice to be able to adjust it. I would love to see a statistic for average recipients per LDAP Invalid Recipients email. From everything I can tell spam has a higher recipient per email rate than valid emails do, and this may be a more accurate way to see what the multiplier should be in your own environment. I’m guessing ours would be closer to 4 or 5 average recipients per spam message.
Also I agree with counting recipients vs. messages. It correlates more accurately to the resultant load on our Exchange systems. And I find myself having to explain the difference between message counts vs. recipient counts. And the way management and the Exchange guys think about it, is how many emails in to every unique mailbox. With 90K+ mailboxes, single instant storage in Exchange databases doesn't buy us enough to even consider it a benefit. So it is always counted as total emails in every mailbox for us.
Regarding the multiplier for "Stopped by Reputation Filter", it is currently set to 3 recipient-messages for every connection rejected. This number was determined based on an analysis of multiple enterprise log files...
I wonder how many other people have re-invented this same wheel? I wonder how close we all got to each other?
some spamware hammers over and over with the same recipient when it gets a 4xx in response to RCPT TO:
We're seeing some odd new behavior where some spamware will also try to reconnect many many times after a TCP Refuse (like we do when blocking connections). Some sites have seen 60 retries in a minute, which has caused their Rejected Connections number to get huge. Has anyone found a good way to explain this kind of anomaly in their graphs?
Regarding the multiplier for "Stopped by Reputation Filter", it is currently set to 3 recipient-messages for every connection rejected. This number was determined based on an analysis of multiple enterprise log files