>>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.
Okay, that's crystal-clear, but what I'm asking is *why* you'd have
the limit set in IMGate higher than that in IMail, if you know that to
cause problems?
>>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.
Again, my question is: Why not just set it in IMGate, per-message, to
512 to prevent the whole problem? Is there some other link that's
missing here--have you seen situations where a non-hacker would send
commands over 512 bytes but less than 600, and you absolutely *must*
let them through instead of telling them to fix their--broken--side
(as we so often do in our anti-spam tactics)? Is this kind of broken
traffic treated as a minor part of a security checklist, as opposed to
being flagrant evidence of *either* wrongdoing *or* major
misconfiguration that demands a fix? Or does IMGate autonomously send
oversize commands that break IMail, whether or not the incoming
transaction to IMGate is filtered for oversize commands? Please
clarify your views on this, the 512- vs. 600-byte question, etc.
> 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.
As you point out, and I agree, you should *certainly* shut it off with
IMail taking messages from an non-throttling MX that does not itself
block at the same 512-byte threshold, or which exceeds the threshold
in outgoing messages for some unavoidable reason.
And I do understand your general preference for turning off a
dangerous feature, given the prevalence of IMGate in your rollouts
(that is, 100%!). Yet I think the number of times this setting has
been discussed on this Forum (very, very few) means that it isn't a
powderkeg in general terms; the majority of IMail servers are MXs, and
there have been, relatively speaking and AFAWK, an infinitesimal
number of complaints.
I also agree that the feature needs fixing, though I don't have a huge
problem with the per-IP auto-blacklist, as long as it is logged with a
really verbose explanation ("SMTPD-ERR server 1.2.3.4 sent an oversize
SMTP command and has been blocked. RTM, Chapter 7.3 for details.") and
times out after a configurable expiry; admins should be ready to look
at their logs from day one. If someone behind a NAT firewall is
sending bad commands, I'm not comfortable just saying "Sorry, hacker,
try again in a moment from the same IP."; I'm willing to take a phone
call from an admin so I can say "Yep, you were blocked for an hour
because one of your users is abusing their privileges on both your
network and ours. The connection came in from port 11244 at 3:24 p.m.
Look at your logs and find a NAT putup/teardown for that port at that
time, and find out which private IP was the culprit." (That may be
just me--I think certain hardlines are rewarding for both sides, while
others are not, and this is one I'd prefer to enforce. I feel that
security concerns in general get a *lot* more cooperation from remote
admins than anti-spam concerns.)
-Sandy
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/
