Re: [IMail Forum] Eudora SMTP AUTH ISSUES

[Anthony Santen]

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???