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