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 will 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."
Ok I understand the above. Q~ Doesn't the new proposed RFC allow up to 1024 characters? Also, ADPHA IMHO doesn't not prohibit all E/SMTP hack attacks but rather a known exploit of weaker email servers. Wasn't this to prohibit client software/hackers injecting multiple DATA command's prior to a 220 response? Also, Is it good or bad to check/uncheck the ADPHA box and why? I've seen the logs fire an event a few times and back tracked the source and found that IMail took the appropriate action 'deny access'. Setting here reading two well respected guru's hash it out over this has got me thinking twice abt this feature. Thanks, ~Rick > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Sanford > Whiteman > Sent: Monday, January 27, 2003 12:55 PM - FamHost > To: Len Conrad > Subject: Re[12]: [IMail Forum] what a pain! > > > Your gratuitous injections of foreign policy debate are ironic, since > you are essentially an expatriate from the IMail world casting doubts > on a place you've left behind (per your own words, "I don't touch > IMail anymore"). I'm glad you have strong viewpoints on political > matters, knock 'em dead over there on February 15th, but let's stay > on-topic. > > >>You don't understand what 'Auto-Deny Hack Attempts' (ADPHA for > >>short) actually does > > > If I don't, then the very-clear-on-this-point Imail .pdf doesn't either. > > That's about as close as you've ever gotten to an retraction, but not > quite there. The PDF makes it very clear that overlong header > lines--which you harped on *repeatedly* in your post, not just when > you mentioned the Postfix header size setting--are completely > unrelated to ADPHA. You write, "I know the difference between lines in > an SMTP DATA command [and] length of header lines in the DATA > command." Sure you do, maybe in your private time, but not when you > were writing your post. Is it so hard to say you screwed up? > > If you'd read my post for content (probably your major weakness is not > reading other people's posts completely--for example, Orin Wells' > question this morning clearly had nothing to do with IMail clustering, > but you decided it was time to show him who's Boss), you'd have seen > that: > > >>[ADPHA] combats overlong COMMAND lines sent in standard SMTP mode. > > That's right, IT DOESN'T APPLY TO ESMTP SESSIONS. I stated this > before, it's easy readin'...but you continue blathering about-- > > > 512 is legitimate in an ESMTP session. > > --instead of sitting down and figuring out what actually happens on > the wire. Of course it's legitimate in ESMTP, and IMail doesn't > regulate ESMTP sessions. > > I continue to maintain, SINCE I KNOW WHAT IT DOES, that 'Auto-Deny > Possible Hack Attempts' is a feature that is perfectly safe to leave > on, unless you have implemented a solution that is *known* not to > cooperate with its implementation (such as IMGate). I'd hope you > realize that the vast majority of people leave this setting on, and > have no ensuing problems. You want to be a fearmonger and tell people > they'll have some myysttteeerrriiioouuusss problems that they'll > neeeevvvveeeerrrr solve, go ahead, but hopefully anyone who hits the > archives will see that you didn't even know what the feature did > (didn't even know how it gets logged by IMail!) and therefore are > pretty far from a trusted source. > > > You need to stop freaking out and taking statements of fact about > > Imail's brokenness as personal affronts that require all-nighters to > > prove to yourself you're some kind of omniscient El Supremo. > > Unlike you, I need to know how a product I recommend actually > functions. You've chosen the reactive approach of waiting for a > catastrophic real-world issue ("field experience"), then leaping to > the conclusion that IMail is broken. > > By the way, you may want to look up "fact" in the dictionary sometime. > Both of our appraisals so clearly fall in the realm of opinion--even > if you understood what was going on--that your insistence that there's > immutable truth makes you seem to be from another planet. I don't go > around saying things are broken, then half-excuse myself when > corrected by saying they're broken *because* they're too hard to > understand, then claim to have understood them all along, then say I > have the "facts" in hand in any case. > > Some time soon, I will analyze a range of PostFix transactions with > IMail and figure out what goes wrong. I will then, as a responsible > technician, post an alternative workaround to use with PostFix to > avoid the situation. In an IMGate setup in which IMail is not > published on the Internet, your recommendation of turning off ADPHA > appears to be a reasonable failsafe--but it is just that, a > preventative for an undocumented situation that may originate at > client or server and does not imply which side is broken. > > And I don't know how you set up your firewalls and anti-spam criteria > to block hack attempts with any degree of efficiency without blocking > by IP. In your own posts on various subjects, you refer repeatedly to > blocking IPs at border routers, at IMGate, at IMail. Yet by the logic > you apply to ADPHA, all of these blocks should just be temporary > session disconnects--ridiculous. There's a place for taking the risk > that a single IP address services legitimate users as well as > hackers/spammers, and I think overlong SMTP commands are suspicious > enough. Maybe when you said, "you only need ONE MSG with >512-bytes in > any header, and you've shutdown all outgoing mail from those 1000 web > customers," you didn't know what ADPHA did, so you were inclined to > believe that ADPHA is likely to be set off by legitimate mail. Wait, > that's right, you've always had a deep understanding of ADPHA, but an > infinite number of monkeys just happened to stomp that out on your > keyboard. > > -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/ > ___________________________________________________________________ > Virus Scanned and Filtered by http://www.FamHost.com E-Mail System. > > ___________________________________________________________________ Virus Scanned and Filtered by http://www.FamHost.com E-Mail System. 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/
