Re: Exchange 2003 SMTP not conforming RFC?

• Previous message: BEDZ12: "smart host"
• Messages sorted by: [ date ] [ thread ]

Date: Wed, 31 Mar 2004 15:06:15 -0800

Exchange is conforming to the RFC.

AUTH LOGIN is not a challenge based auth mechanism. If you base64 decode
"334 VXNlcm5hbWU6" you get "Username:" A server could reply with practically
anything encoded in that string and it would not affect the client's next
transmission. (Most servers use "Username:", base64 encoded, by convention
because some SMTP clients do not handle bare server responses such as "334"
or were incorrectly implemented to require the string which is in contrast
to both LOGIN and PLAIN)

In challenge based auth mechanisms, a client must apply some form of
operation or hash on the challenge and the result of this operation would
affect the content of the next client transmission. This is why it is not
possible for these auth mechanisms to use the initial-response argument. As
an example NTLM and GSSAPI are challenge based auth mechanisms. Exchange
2003 cannot use the initial-response argument in these cases.

Exchange 2003 is taking advantage of the initial-response argument (as
allowed by the RFC) in order to cut down on protocol round trips. There is
use of BDAT and Pipelining as well to improve efficiency.

Unfortunately the problem still exists. How can you configure Exchange 2003
to connect to a relay server that does not implement the initial-response
argument? There is no easy answer because no configuration setting changes
this behavior. I am also aware of some problems where some servers require
the initial-response parameter so clients have trouble doing it the other
way. http://www.eudora.com/techsupport/kb/2354hq.html

Conventionally in cases such as this for maximum interoperability, the
server side is updated to be more flexible to handle multiple clients. The
RFC violation is also on the server side in this case. Therefore, the best
fix would be on the side of the ISP. Note that Exchange 2003 can accept AUTH
LOGIN both ways.

It is possible to request a fix with Product support; however, there are
several problems with a client side fix. There is still the issue of the
reverse interoperability case noted above. Secondly, a retry mechanism that
uses both approaches is rather problematic and could introduce more
interoperability issues.

-- 
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jens Mander" <jens.mander@donotspam.com> wrote in message
news:%23Nnmd0xEEHA.3336@TK2MSFTNGP12.phx.gbl...
> We have a problem with an Exchange 2003 server, actually an SBS2003
server,
> that should send all it's outgoing mail via a smarthost configured in an
> SMTP Connector. This worked in many cases so far und Exchange 2000.
>
> The  SMTP Connector is set up to send using the login credentials for the
> relaying smarthost. We checked on the same machine using Outlook Express,
> that relaying mails through this smarthost works. OE can send without
> problems.
>
> But the mails sent via Exchange do not go out. Instead we get an error
with
> AUTH in the mailque for this mail (and after the timeout an NDR).
>
> We sniffed the network traffic using network monitor and it came out that
> outlook uses a diffrent SMTP AUTH procedure. Outlook Express does it
> (correctly) this way:
>
> 220 mail.myprovider.com MYPROVIDER ESMTP MailService V2.00
> EHLO myserver
> 250-mail.myprovider.com
> 250-PIPELINING
> 250-SIZE 20971520
> 250-ETRN
> 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN OTP
> 250 8BITMIME
> AUTH LOGIN
> 334 VXNlcm5hbWU6
> fhfFDGf456GFGcc4fddFG==
> 334 UGFzc3dvcmQ6
> bghfrDHGFFE=
> 235 Authentication successful
>
> Exchange 2003 instead puts the BASE64 encrypted login name directly behind
> the AUTH LOGIN. This, according to RFC2554
> (http://www.ietf.org/rfc/rfc2554.txt) is only allowed for login mechanisms
> with an empty challenge from the server. This is not the case here, as can
> be seen in the 334 reply starting VX...
> (The encoded login credentials are fictios in this example)
>
> Is there a way to make Exchange 2003 use the "long form", sending AUTH
LOGIN
> and only after the challenge of the smarthost the credentials? We have
> several providers that force to have it that way.
>
> Regards,
> Jens
>
>
>

• Previous message: BEDZ12: "smart host"
• Messages sorted by: [ date ] [ thread ]