Re[10]: [IMail Forum] what a pain!

[Len Conrad]

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?

It's on by default in IMail and some admins just don't touch it. In the IMGate list, the recommendation has been made repeatedly to disactivate this feature in Imail.

Again,  my question is: Why not just set it in IMGate, per-message, to
512

by default, in postfix, it's 2048. and since it's an comparatively ineffective setting, it doesn't get a lot of attention. In the last couple of months, experimentally, I've added it to the IMGate config at 256, and that doesn't seem to cause any problems, but really doesn't have any effect in blocking abuse, either. While the vast majority of headers are under 128, I've found 128 to be too low, for those people who have list of 10 or 15 addresses they dump in the TO: field.

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

sure, lots of times. it's called whitelisting. ime, it's a total waste of effort by IMGate admins to try to get other servers fixed. And since IMGate logging tells us exactly what the block is and has very fine grained params, it's easier and quicker just to whitelist the specific server and let the correspondents, and the IMGate admin, get on with other business.

--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,

Mail admins dominant priority is to let known legit mail through, even if the legit mailserver is broken.

as opposed to being flagrant evidence of *either* wrongdoing *or* major misconfiguration that demands a fix?

BOFH works fine with unknowns, but the overriding policy is to let legit servers and mail through.

Or does IMGate autonomously send oversize  commands  that  break  IMail

This feature of IMail is broken. Imgate doesn't break it. This very point has come several times in the IMGate list, and the standing advice is always to unbreak Imail by unchecking this box.

,  whether  or  not the incoming
transaction  to  IMGate  is  filtered  for  oversize  commands?

mosttly not, postfix has it at 2048 by default, IMGate has recently, experimentally lowered that to 256, to no effect. That particular kind of abuse we simply don't see on IMGate's that have very high levels of abuse of all other types.

I think this kind of crack was popular a few years ago when sendmail, probably, or whatever MTA, was vulnerable to being overflowed with largish headers.

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.

It should be disactivated in IMail in all conditions, and turned on specifically to stop a specific attack of that nature, and then turned off.

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

exactly, because this type of abuse is extremely rare, and the Imail feature is broken, it can be very hard for Imail admin's to determine why they can't receive mail from one MTA simply because somebody over there sent, probably accidentally, a huge header on one msg and Imail blacklisted the entire server.

; the majority of IMail servers are MXs, and
there  have  been,  relatively  speaking  and  AFAWK, an infinitesimal
number of complaints.

but how many times have we seen the syndrome "why can't my Imail receive mail from just this one server, and it receives from all other servers work ok?" And how many more times does it happen in the 10's of 1000's Imail sites whose admins don't follow this list?

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.")

but it's not logged verbosely, Imail doesn't log verbosely.

And, after Imail decides to auto-deny an ip, are repeated rejects of the ip logged, or is just the first, triggering violation that get's logged?

and times  out after a configurable expiry;

I bet this fairly old feature won't be fixed and if it is, it won't have auto-undeny timeout. That kind coding and feature is just not present anywhere in Imail, afaik.

If  someone behind a NAT firewall is sending  bad commands

Try ONE bad header, without malice, purely accidentally, and very intermittantly, and, two days ago, and now today, you can't receive from that server. That's pretty nasty hard place to get out of.

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/