How do any of those messages ever pass IMGate in the first place?
easy, if IMgate
header_size_limit = 600 is set bigger than Imail's 512.
Can't IMGate be set to block per-message using the same criteria?
sure, it's implemented right, it blocks the msg, not the sending ip.
I said you have to defeat it in IMail where it's done wrong, and manage it in IMGate, where it's done right.Not that you'd need IMail's support at that point, but I'm unclear on why IMGate doesn't/can't short-circuit the feature anyway.
Your 100's-of-users-behind-NAT situation is similar to IMGate. One user's msg triggers IMail auto-deny, and the entire NAT is dead until Imail SMTP is re-started.It's the default, so I'd bet just about everybody is using it. We usually deploy with it turned on and have never found support a burden. I think the payoff, as long as the IMail server as the MX, outweighs the risk.
When I've played with header_size_limit feature in IMGate and moved it up and down on high-traffic, high-abuse IMGates, the number of messages this limits blocks is minuscule, insignificant compared to all other defenses.
So the risk of Imail shutting down a high-volume MTA (and it can be very hard for inexperienced mail admins to figure out why) and requiring manual intervention in IMail to fix, far outweighs the benefit of tiny number of rejects. I would say even even experienced IMail admins would have a hard time debugging this one, esp if the trigger occurs infrequently with any given MTA.
So I recommend that Ispwitch fix it, and have it off by default.
Len
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
