There's no "typical log size" for exchange as this is dependant on activity, not the product itself.
There's an interesting discussion on the microsoft support site here which might be relevant (extract follows).
i had the same issue, and it turned out to be 2 users with android phones in a sync loop on contacts. I basically ran reports showing the top 10 mailboxes by item count (as opposed to size), and was able to narrow it down to the 2 problem users that way (their item count was incrementing very quickly compared to everyone elses. Running the report every 3 minutes let me find the trend
The poster suggested running the following powershell script as their "report"
Get-Mailbox -database databasethatkeepsgrowing | Get-MailboxStatistics | Sort-Object ItemCount -descending |Select-Object DisplayName,ItemCount,@{name="MailboxSize";exp={$_.totalitemsize}} -first 10 | Convertto-Html | out-File c:\temp\report.htm
I reckon you could see this issue from any device that might have problems, including outlook itself if a user or two have messed up OST files or badly behaved plugins - keep in mind that transaction logs aren't just a list of mail but a list of, well, transactions which includes mail but can also include anything that changes the properties of an object in your message store, which can be any number of things. I'd suggest that the high CPU you've noticed could be very relevant, and worth checking out at least.
In addition to that lot, I'd be checking for things like spam relaying and the like, but I'm sure you're all over that.
From the command line of your Exchange transport server, initiate a telnet session to port 25 of whatever server the remote domain's MX record points to, and manually transmit a message to the recipient. If it accepts the message,but they do not receive it, this is NOT your problem.
EDIT: How to do this can be found here http://support.microsoft.com/kb/153119
Best Answer
Check your IIS logs to see if that reveals anything.
Of particular interest in the logs might be the HTTP status code, however the URLs they are browsing could be interesting in case there is some issue where your users are being incorrectly bounced between servers and the authentication isn't being passed through correctly, or even at all.
I haven't really looked much at the Exchange 2010 IIS logs, but if your users are being directed to a page similar to
you-put-your-password-in-wrong-you-numpty.aspxthen that would probably be your definitive answer. In all seriousness though, if you purposefully authenticate incorrectly and see what that looks like in the IIS logs, you might see a similar pattern for other users (I'm thinking being directed to the logon page with some specific parameters in the query string likelogin.aspx?reason=xxx).