Dave, John, Susan - I'm consolidating my response to your various different
statements, as it helps showing how each of you come up with a different
"approach". That inconsistency alone tells me WHO is right.
>> From: "Dave MacMillan" <[EMAIL PROTECTED]> <<
>> IMail has answered 220 X1 for six years now. <<
Dave - yes, and how many years have you seen people reporting this as a bug.
I know *I* have! The fact that your are in violation for so many years
should be source of embarrassment - it is NOT an argument in your favor! (A
bug doesn't become less of a bug, just because it has been ignored by
programmers for many years.)
>> As the KB article says, the X1 code (in the welcome message from IMail's
services) lets other IMail applications know that they are connected to an
IMail service. <<
Your are white-washing. The KB DENIES that there is a Standards
violation - when it clearly IS. So giving out FALSE information is
objectionable (but fits IPswitch's treatment of this bug over the years.)
>> From: "John Korsak" <[EMAIL PROTECTED]>
>> So, now we are left with each party believing they are correctly
interpreting the RFC <<
There is no room for interpretation. Let's read it together, shall we:
>> An SMTP client MUST determine its actions only by the reply code, not by
the text (except for the "change of address" 251 and 551 and, if necessary,
220, 221, and 421 replies); in the general case, any text, including no text
at all (although senders SHOULD NOT send bare codes), MUST be acceptable.<<
It clearly says **client**. How can one possibly misunderstand this part of
the RFC? It simply instructs, how an SMTP **CLIENT** has to behave. You are
marketing an SMTP (=compliant) ** S E R V E R ** !
At best, this part of the RFC is relevant to our discussion in that is
demands that CLIENTS should be tolerant even if the SERVER (= IMAIL) creates
a malformed 220 response. So any client that has a problem with Imail's
malformed 220 response is itself in violation of the RFC. The fact that
your bug should be tolerated doesn't release you from the responsibility to
bring your SERVER into SMTP compliance (that's what I've been paying for).
>> From: "Susan King" <<
>> We are actually following the RFC. Let me explain why we believe this to
be the case.
In the example you provided below, it shows the "[10.0.0.1]" as an example
of acceptable text. This is comparable to our X1. <<
Susan, at least YOU were able to find a RELEVANT portion of the RFC (one
that actually discusses how the SERVER has to format the 220 response in
order to be compliant.) John, take note!
Let's read that paragraph together.
>> Sometimes the host will have no meaningful name. See 4.1.3 for a
discussion of alternatives in these situations.
For example,
220 ISIF.USC.EDU Service ready or
220 mail.foo.com SuperSMTP v 6.1.2 Service ready or
220 [10.0.0.1] Clueless host service ready <<
Susan, in SMTP, there are TWO formats how you can qualify a host:
a) by using a fully qualified host/domain name
b) by including the IP address in square brackets.
Your "X1" doesn't fit EITHER of those two. X1 is NOT a qualifier pointing to
a valid host. Therefore it is a violation of the RFCs with respect to the
proper format of the 220 response.
Here's what this discussion is showing:
First we have the product manager quote ONE irrelevant section of the RFC
(that refers to SMTP client behavior).
Then we have Susan King from Tech Support quoting get another section of the
RFC as the reason.
Then we have Dave MacMillan post a knowledge base entry that vaguely says
"oh, we are in compliance" (but neither John or Susan can agree on why!)
So VERY clearly: IPswitch really HAS no good reason for violating the RFC -
whoever you ask at Ipswich is simply making up arbitrary answers as they go
along.
Does everyone understand, why I have long since stopped paying my annual
maintenance fee (which I do pay for any other product that I use!). I had
reported various problems over the years and after some information
gathering by Ipswitch tech support, they all ended up in someone's black
hole. No one seems to care - but everyone is quick to justify their
inabilities by making up stories.
Best Regards
Andy Schmidt
H&M Systems Software, Inc.
600 East Crescent Avenue, Suite 203
Upper Saddle River, NJ 07458-1846
Phone: +1 201 934-3414 x20 (Business)
Fax: +1 201 934-9206
http://www.HM-Software.com/
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Please visit the Knowledge Base for answers to frequently asked
questions: http://www.ipswitch.com/support/IMail/
