Quentin, well said, I back you up on that, this forum is the most
useful group I subscribe to, there are many players 'earwigging' that
readily jump to peoples aid however minor the problem may seem. Keep
up the good work ...
Anthony, go and vent your spleen somewhere else .....
Friday, April 07, 2000, 1:52:14 PM, you wrote:
> Hey, Anthony I don't think it was a waste of time. It might have helped someone out
>if not yourself.
> The Imail Forum is where users and customers go to try and get help on the problems
>that they are experiencing not to vent their anger out on anyone because they are not
>getting the answers they're
> looking for or because the problem may not be that easy to fix or diagnose!
> At least I did try and help!
> ----- Original Message -----
> From: Anthony Santen
> To: [EMAIL PROTECTED]
> Sent: Thursday, April 06, 2000 6:24 PM
> Subject: Re: [IMail Forum] Eudora SMTP AUTH ISSUES
> Holy cow Quentin, Nice work, but what a waste of time.
> Apologies? ARE YOU KIDDING?
> NOTHING THIS MUNDANE SHOULD BE ABLE TO CLOSE DOWN A MAIL SERVER
> You've obviously missed the point.
> The fact that there is a bug, or thousands of bugs in Eudora should NEVER have the
>effect that it can hang the COMPLETE mail server. That's ridiculous, and obviously
>falls under the category of
> DoS exploit.
> Let's see..... if I wanted to shut down all the IMAIL servers, All I had to do is
>install 1 copy of Eudora. and send mail through my little 2400baud modem to the IMAIL
>server.
> Let me repeat again.
> MS-EXCHANGE WORKS FINE WITH EUDORA
> SENDMAIL 8.10 WORKS FINE WITH EUDORA
> I'm sorry, but I'm trying to get through the cotton wool in your ears
> Anthony Santen
> ----- Original Message -----
> From: Quentin Baker
> To: [EMAIL PROTECTED]
> Sent: Thursday, April 06, 2000 4:23 PM
> Subject: [IMail Forum] Eudora SMTP AUTH ISSUES
> Ok, someone decided to do a little bit of research for all those users who blame
>IMail for Eudora's bugs!!!
> 1) Look at Eudora's release notes.
> Here is a clip:
> Complete machine names are now always sent in the SMTP HELO and EHLO
> commands. Some SMTP servers require this in order to send mail.
> Did anyone check their sys.txt logs in IMail Administrator and see how Eudora
> combines the client and server host name on it's EHLO command line.
> This is an obvious bug and it states above that servers require this "in
>order to send mail"
> Now what if the host name is invalid with the two combined like that?
> I'll explain in issue 4!
> 2) Now check this clip out from their knowledge base:
> Note: Known issue in 4.2 - If your server supports multiple methods of
>authenticating, Eudora only checks the first one listed. If the first method
>supported is something other than CRAM-MD5,
> Eudora will not send the AUTH command even though the server may support this
>authentication method. This will be fixed for version 4.2.1.
> Back to their release notes:
> SmtpAuthBanished [default is none banished]
> The value should be a comma-separated list of SMTP authentication
> schemes whose use is to be disallowed. Users who are especially
> concerned about security should set it to "LOGIN,PLAIN", as this
> ensures that your SMTP server password will always be strongly
> encrypted when it goes over the network. Users of IPSWITCH's Imail
> SMTP server should set it to "CRAM-MD5" so as to avoid a bug of
> theirs.
> Now, based from their own knowledge base they said that they will fix their AUTH
>problem in
> version 4.2.1 now here it is in their release notes for 4.3.1 and they blame
>Ipswitch because they didn't fix their own bug!!!!
> 3) back to the release notes:
> AlwaysConnected 0
> Setting this to 1 tells Eudora that there's a permanent network
> connection (e.g. LAN, ISDN, DSL, cable modem). Ordinarily Eudora
> detects this, but in some of these cases Windows may tell Eudora
> there's no network connection when in fact there is.
> Now, if Windows tell Eudora there is no network connection, can you possibly
>send mail.
> Let alone is IMail to blame for something that Windows does and Eudora didn't
>adjust to?
> 4) Refer back to issue 1.
> Read RFC 1123 Section 5.2.5
> To sum it up it basically says that the mail client MUST ensure that the
>domain parameter
> in the HELO or EHLO command is a valid principal hostname for the client
>host.
> The smtp server may verify that parameter to see if it really corresponds to
>the IP address
> of the client host. This will take a considerable amount of time if the
>parameter is invalid
> because it requires a domain name lookup;the server will have to perform a
>MX resolution
> on this name in order to validate the EHLO parameter.
> Now, this may be the problems that users are experiencing. Because the EHLO
>parameter
> is bad the mail server takes time to look it up and after a while I believe
>that the error message you get in Eudora is that Eudora decided to give
>up because it was taking to
> long.
> Even though the EHLO parameter is invalid the server "can not" refuse to
>accept a
> message from the email client even if it fails verification.
> The other error in Eudora error 550 or 501 .....not a gateway or what not....
> So, even though that the server must accept the message it does not mean
>that it will be
> able to RELAY the message.
> 5) Eudora may have fixed their SMTP AUTH problem somewhat because I've gotten
> it to work relaying for addresses and authenticating without adjusting my
>.ini file.
> But if they really did fix it, why put that gesture in their release note
>as a workaround.
> Now who wants to talk to Eudora about SMTP AUTH, EHLO, and Windows problems.
> P.S. After reading this, who wants to be man enough to write the first apology
>note
> to Ipswitch for blaming IMail for Eudora bugs???
GT Online Tech Team
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
