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/
