Len, > by default, in postfix, it's 2048. and since it's a 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...
In the words of one of America's proudest exports, hold your nose, 'cause here goes the cold water. You don't understand what 'Auto-Deny Hack Attempts' (ADPHA for short) actually does, and quite frankly you're propagating misinformation. I find it unfortunate that for all your fearsome and condescending words about whether it is or is not broken, you seem to have never tested this feature. Postfix's setting 'header_size_limit' has absolutely nothing to do with IMail's ADPHA. Postfix's max_line_length is closer, though still basically irrelevant. >From the venerable IMail manual, here for 7.0: > 'Auto-deny possible hack attempts': If more than 512 characters are > sent during anything but the SMTP DATA command, the remote IP > address is temporarily put in the �deny access� (Control Access) > file until you stop and restart the service and then disconnects. > Sending more than 512 characters in anything but the SMTP DATA > command would look like an attempt to �hack� in to your server. You > will not see the address in the �deny access� list, but it is > reported in the log file. This is a totally reasonable regulation, given RFC 2821 4.5.3.1 (seconding 2821): > command line: The maximum total length of a command line > including the command word and the <CRLF> is 512 characters. SMTP > extensions may be used to increase this limit. Now you'll get why I was fighting tooth and nail about security, whitelisting, and so on: you think ADPHA detects long TEXT lines, when in fact it combats overlong COMMAND lines sent in standard SMTP mode. Such command lines will not be accepted in any case, even if ADPHA is not checked--ADPHA just adds in the auto-blacklisting part . (IMail will accept text lines beyond the RFC limit; it knows that there are broken mailers out there.) Since I've been armed with the knowledge of what ADPHA actually does, it's been frustrating when you use language like "This feature of IMail is broken," and your brief mention of header_size_limit has finally enlightened me as to your mistake. > but it's not logged verbosely, Imail doesn't log verbosely. This shows again your inexperience with ADPHA. A sample log line is "Possible hack attempt from 192.168.1.12, address will be denied future connections until restart." Not as verbose as a pointer to the manual, but pretty darn self-explanatory. I do not have a ready explanation as to why/how/whether PostFix triggers this feature in IMail. Neither the IMail nor IMGate archives reflect a high profile for this issue, so I'm led to believe that you attempted to escalate its importance for anti-Ipswitch reasons, which is not playing fair on a vendor-supported forum. You need to prove that IMail is mistakenly rejecting legitimate ESMTP long commands, miscounting bytes, or that the feature is otherwise operating in a fashion outside the documentated behavior. More likely, you will find that PostFix sends broken command lines under certain circumstances beyond IMail's control and can be tweaked around. One area to look into might be PostFix erroneously pipelining, even though IMail does not announce PIPELINING (IMail would thus be acting in the same way as PostFix's own 'reject_unauth_pipelining' setting--very strange for Wietse's software, but there have been related patches--see http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&th= a86e7af77426cd22&seekm=ai4kle%242dp7%241%40FreeBSD.csie.NCTU.edu.tw# link1.) Len, I won't pretend to be an expert in Postfix, let alone SMTP, but I will stay up all night to prove to myself that I know IMail inside and out. In the future, could you do some similar legwork *before* the flame war? -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/
