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

[Len Conrad]

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.

and quite frankly you're propagating misinformation.

oh, BS!  "Imail's ADPHA response is broken", what's misinformation about that?

I find it unfortunate that for all your fearsome and condescending

... what's condescending about that???

The preceding two questions are strictly rhetorical, needing no nit-picking response.

words about  whether  it  is or is not broken, you seem to have never tested
this feature.

Not directly, but I have been called in to several situations where Imail has starting refusing all mail from IMGate. "Field experience" here suffices, no deep research or testing is needed.

Postfix's  setting  'header_size_limit'  has  absolutely nothing to do
with  IMail's ADPHA.

no, it doesn't.

Postfix's max_line_length is closer, though still
basically irrelevant.

yes, that deals with DATA lines in the msg body.

This  is  a  totally  reasonable  regulation,  given  RFC 2821 4.5.3.1
(seconding 2821):

As I said in my previous message, the idea of a limit on any parameter is just fine, what's broken in Imail ADPHA is the response to the violating the limit. Instead of just returning an STMP error, even hanging up on the violator, or rejecting any msg that triggers ADPHA, IMail blacklists the sending ip until manual intervention. Really bad idea. "broken"

>    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

I don't think that at all. I know the difference between lines in an SMTP DATA command, length of header lines in the DATA command, and lines in other SMTP commands.

when in  fact it combats overlong COMMAND lines sent in standard SMTP mode.

I know that, the Imail doc states that. But I'd really like to know why ADPHA is triggered when receiving from postfix, because I assume paranoid, hyper-cautious postfix doesn't violate any SMTP COMMAND length limit, so what's going on? Because, turning off ADPHA solves the problem for postfix (and other MTA's). I know of no param that will cause postifx to violate RFC SMTP command length limit.

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

Your frustration is your problem (watch more Dr. Phil or Tony Robbins), "This feature of IMail is broken" still stands.

and your brief mention of header_size_limit has finally enlightened me as to your mistake.

right, my mistake. I confused, in this thread, header_size_limit with SMTP command length, which clearly not the same. No need for you to freak out and lose sleep over it, as you report. It doesn't change my statement of indisputable fact that ADPHA is broken.

I  do  not  have  a  ready  explanation  as to why/how/whether PostFix
triggers  this feature in IMail.

Nor do I, and why phrase it that way? You and others here have said plain old NATted MTA's, or any MTA anywhere, will be blacklisted by ADPHA. Postfix is just like any other MTA. In no way does postfix, only and specifically postfix, "trigger" ADPHA.

ah, wait a minute, postfix can return longish 4xx/5xx SMTP lines, eg ("out" from postfix):

Out: 450 <[EMAIL PROTECTED]>: Sender address rejected:
undeliverable sender address: host applg-1.aareal-bank.com[193.31.203.193]
said: 551 Sorry, I don't allow unauthorized relaying. Please use another
SMTP host to mail from <[EMAIL PROTECTED]> to
<[EMAIL PROTECTED]> (in reply to RCPT TO command)

Here is where postfix is echoing the other MTA's response PLUS postfix's own text. But that's still a ways from 512.

Neither the IMail nor IMGate archives reflect  a high profile for this issue

Exactly. It took us some time in the IMGate list to figure out WTF Imail was refusing, extremely intermittently, to talk to IMGate, (ie, Imail refusing all of inbound Internet mail, a major problem that gets peoples' attention pretty quickly ) when postfix was as an ip in Imail relay_for_addresses.

The rareness of the occurrence of such a command combined with the broken ADPHA response and with very likely only one MTA at a time, makes ADPHA very difficult to troubleshoot.

so I'm led to believe that you attempted to escalate its importance for anti-Ipswitch reasons

I am not anti-ipswitch at all, which falsely accusatory "belief" BS from you is like Dick Cheney and Ari Fleischer calling anti-war/anti-shrub people un-patriotic.

I'm not escalating anything, I didn't start this thread, I'm stating clearly what's broken in Imail and how to work around it.

which is  not  playing  fair  on a vendor-supported forum.

codswallop

You need to prove that IMail is mistakenly rejecting legitimate ESMTP long commands

I don't need to prove that (or anything else), I've never claimed it. 512 is legitimate in an ESMTP session.

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.

Here's the comment of the postfix developer:

"SMTP extensions allow for commands in excess of 512 bytes.

For example, RFC 2554:

(5) an optional parameter using the keyword "AUTH" is added to the
MAIL FROM command, and extends the maximum line length of the
MAIL FROM command by 500 characters.

So, software that simplistically limits input command lengths to 512
is broken.

Wietse"

So not only is the ADPHA response broken, the developer of a major MTA package claims Imail�s ADPHA the detection is broken and non-RFC compliant.

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.

bravo! So proving anything to yourself has exactly what to do with anything in this thread?

In the  future,  could you do some similar legwork *before* the
flame war?

You spend your nights how you want, I'll spend mine how I want.

And what flame war? If YOU don't like the posting of unpleasant-to-you facts, the poster is flaming? And WTF appointed you judge/jury/executioner/forum moderator/arbiter?

Through the IMGate project, I have the very useful, illuminating perspective of working with IMail intensively "from the outside" as another MTA.

(In fact, it has been my repeated experience that my installing IMGate into a system illuminates all kinds of other hidden problems (DNS, bandwidth, security policies, connectivity weakness, router config faults, bad switches, under par performance, etc. ) that get fixed and overall system quality consequently increases. IMGate just did this two weeks ago. An IMail/IMGate user's WAN died (pings to his upsteam took 900 ms) every time a list was sent out on Saturday. It turned out that the T-1 local loop was actually incapable, as admitted by the LL provider, of no more that 256 Kbits/sec. The local loop provider is providing the IMGate client with $credit for the local loop charges.

On another site, the IMail server, totally overwhelmed but the admin didn't know why, had flaky ATA mirroring that slowed Imgate delivers to Imail. The Imail admin had no clue, which was finally provided by IMGate's terrible performance, fixed the Imail disk, and off we went.)

Of course, if Imail and IMGate don't work together perfectly, we got big problems. The response of ADPHA is one of the few, remaining broken parts of Imail but we now know how to work around it easily. And when Imail ADPHA does its dirty deed to an IMGate box, guess who typically gets called in to analyze it?

There have been a couple of other broken parts of IMail that IMGate has illuminated and that I've worked with Ipswtich to fix, so calling me unfair or anti-ipswitch is pure ad hominem BS.

So, my last comment in this thread:

ADPHA is a broken idea, above all in an ESTMP session, and the response is broken. (In fact, it's really too bad that Imail is not full of other dynamic, defensive features like ADPHA, only implemented correctly.)

In practice, 512+ SMTP command bytes of "PHA" seems to be a minuscule occurrence in the wild, so Imail�s ADPHA feature, twice broken, actually offers very little protection, especially as long as Imail is immune to this RFC-legal "attack".

However, the 512+ bytes "PHA" does occur, but so rarely that any Imail admin will probably be seriously stretched, and delayed, trying to track down why Imail refuses all mail from just one ip, perhaps one that is relay-from-addresses as is IMGate, that it has been receiving mail from, and worse, and the event triggering the shudown is not in today's log file.

Checking ADPHA offers no protection to Imail (which at this point MUST be immune), but it can really screw you up, and requires manual intervention to clear, after you've figured out what is going on. The ADPHA "cure" (permanently shutting down an MTA for a single, one-line "transgression") is worse than the completely innocuous, RFC-legal PHA "disease".

The wrongness can be made innocuous and brokenness is easy to fix, so unchecking ADPHA is the only recommendation for every IMail installation.

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/