Well... here is what is going on... it also is the cause of the issue I have been reporting FOR YEARS about multiple messages having the same Message Id in our SMTP logs.
We have an Antivirus/Antispam box in front of our SmarterMail server.
This box communicates via a batch sending mode that for MOST mail servers is not an issue.
So it basically:
Message --> AVAS Box (process for virus / spam)--> Temp Store message if ok
At regular (and highly frequent) intervals gather up all pending messages to send and queue them up
When communicating with the SmarterMail server that does the following:
CONNECT TO SMARTERMAIL
-- SEND MESSAGE #1
-- ISSUE RSET
-- SEND MESSAGE #2
-- ISSUE RSET
--continue until done with pending messages
DISCONNECT FROM SMARTERMAIL
What SmarterMail does/sees
SMTP-IN CONNECTION ESTABLISHED (Assign Message ID)
-- GET MESSAGE (Apply Message ID)
-- -- Perform size and hop count evaluations for Message ID: End processing if necessary and send notices
-- GET MESSAGE (Apply the SAME MESSAGE ID)
-- -- Perform size and hop count evaluations for Message ID: End processing if necessary and send notices
-- repeat until...
DISCONNECTED
So ALL of the messages sent in that batch from the front-end server end up getting the same Message Id.
This does AT LEAST 2 things:
1) It severely throws off the HOP COUNT processing since this appears to be done per Message Id instead of per actual email.
2) It really screws up the SMTP logs in that all those messages now have the same message Id stamped into them... so if you do standard message analysis in the logs: search for issue, get message id, then lookup message id for that message details... you get ALL those messages returned... not really very helpful.
The hop-count issue started after the upgrade to 8251. Why? Still waiting on an answer for that. I'm guessing it wasn't being "enforced" prior... or it was being calculated differently...but that is just a guess.
The hop-count currently is a BIG issue as it prevents delivery of the message and any subsequent messages in that batch that occur after the HOP COUNT EXCEEDED maximum value is hit.
As a temporary "patch" we have upped our hop-count allowed to a ridiculous number. But that is only temporary as we could potentially get a forwarding loop in there that could spiral out of control.
Still waiting on a solution from SmarterMail for this, have to say Tony S has been very responsive and assisted in identifying the problem.