We are looking for a way to require SMTP AUTH for our users submitting
mail for relay from their Outlook clients. It seems that the only way
to avoid exposing plain text passwords in Outlook is NTLM encryption,
but sendmail doesn't support that. In fact, looking at:

http://www.sendmail.org/~ca/email/mel/SASL_ServerRef.html 

it seems that Vopmail is the only server with NTLM support, but
Vopmail isn't available anymore, and probably wasn't for Unix anyway.
Are there any MTAs supporting NTLM? Is there another way to avoid
exposing plain text passwords?

We have thought of SSL, but we have Eudora users also, and there seems
to be a conflict between STARTTLS (Eudora) and SSL (Outlook).

Daniel Feenberg
feenberg isat nber dotte org

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.

--=_mimegpg-ny.email-scan.com-5576-1080957438-0006
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Daniel Feenberg writes:

> We are looking for a way to require SMTP AUTH for our users submitting
> mail for relay from their Outlook clients. It seems that the only way
> to avoid exposing plain text passwords in Outlook is NTLM encryption,
> but sendmail doesn't support that. In fact, looking at:
> 
> http://www.sendmail.org/~ca/email/mel/SASL_ServerRef.html 
> 
> it seems that Vopmail is the only server with NTLM support, but
> Vopmail isn't available anymore, and probably wasn't for Unix anyway.
> Are there any MTAs supporting NTLM?

NTLM is a proprietary Microsoft protocol.  Even if someone reverse-engineers 
it (and it's been mostly reverse-engineered already, from what I 
understand), Microsoft can easily change it at any time.  Also, it's almost 
a given that Microsoft probably holds some key patents necessary to 
implement NTLM.

For those reasons, I doubt the existence -- to any significant degree -- of 
NTLM support outside of Microsoft's own software.


--=_mimegpg-ny.email-scan.com-5576-1080957438-0006
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQBAbhn+x9p3GYHlUOIRArmWAJ9OKsNnUKuDF2C8jwBf4+gdjE3iJQCeMErR
2huomJBDT1DXCF4U3X5UfEM=
=82UO
-----END PGP SIGNATURE-----

--=_mimegpg-ny.email-scan.com-5576-1080957438-0006--

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

drfremove@nber.org (Daniel Feenberg) writes:

>We are looking for a way to require SMTP AUTH for our users submitting
>mail for relay from their Outlook clients. It seems that the only way
>to avoid exposing plain text passwords in Outlook is NTLM encryption,
>but sendmail doesn't support that. In fact, looking at:

Wrong on two counts.

  1:    You can build sendmail with STARTTLS support.  In that case
	the session is encrypted, so it is safe to use plain text
	passwords in the encrypted channel.

  2:	Sendmail-8.12.x can be built with SASLv2, which does support
	NTLM.

As far as I can tell, this all works fine with Outlook Express.

In my tests, I couldn't get Outlook (the version that comes with
Office-XP) to authenticate at all.  Apparently it is looking for the
proprietary microsoft authentication procedure, and does not
recognize RFC-compliant auth.  I think it is looking for the server
to say "AUTH=LOGIN" instead of "AUTH LOGIN".

>We have thought of SSL, but we have Eudora users also, and there seems
>to be a conflict between STARTTLS (Eudora) and SSL (Outlook).

You can build sendmail to use direct SSL.  I configure my servers to
offer STARTTLS on ports 25 and 587, and to do direct SSL on port
465.  Outlook Express seems to be able to use STARTTLS only if the
port is 25.  It can use direct SSL on other ports.  As best I could
tell, Outlook only does direct SSL.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (SunOS)

iD8DBQFAbjhUvmGe70vHPUMRAnffAJwP1Vm7YDNalgsucjsV3utxvCWpiwCgh5Ux
iobR3tqlJWr9y4ECaVDdVpw=
=TXaI
-----END PGP SIGNATURE-----

> We are looking for a way to require SMTP AUTH for our users submitting
> mail for relay from their Outlook clients. It seems that the only way
> to avoid exposing plain text passwords in Outlook is NTLM encryption,
> but sendmail doesn't support that. In fact, looking at:

SMTP AUTH (e.g. PLAIN method) is quite standard these days, and although I 
don't use Outlook I would be very surprised if it did not support SMTP 
AUTH. Often such features don't have an explicit checkbox, but maybe the 
mail client will detect the feature automatically from the EHLO information 
banner.

> We have thought of SSL, but we have Eudora users also, and there seems
> to be a conflict between STARTTLS (Eudora) and SSL (Outlook).

Careful about the ports! STARTTLS is a command that goes over port 25 
(connects in cleartext first) while a fully SSL/TLS encrypted SMTP 
communication is purely over port 465, all encrypted. You might want to try 
out my JBMail app ( http://jbmail.pc-tools.net/ ) to test the various forms 
of SSL with and without SMTP AUTH, as a debugging tool. I use OpenSSL.

There is a big difference between SMTP AUTH and SSL/TLS alone. While 
SSL/TLS provides encryption and therefore some (and password) privacy, it 
does not give you access control which is really what you're after. So 
SSL/TLS alone won't help you; rather, you need SMTP AUTH to make sure that 
only authorized customers are relaying mail via your server.

The beauty of authenticated SMTP sessions is that in case of abuse (virus 
outbreak for instance) you can also easily track down exactly which 
customer is causing the problems.

-- 
Jem Berkes
http://www.sysdesign.ca/

Neil W Rickert <rickert+nn@cs.niu.edu> wrote in message news:<c4ld8p$nl3$1@usenet.cso.niu.edu>...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> drfremove@nber.org (Daniel Feenberg) writes:
> 
> >We are looking for a way to require SMTP AUTH for our users submitting
> >mail for relay from their Outlook clients. It seems that the only way
> >to avoid exposing plain text passwords in Outlook is NTLM encryption,
> >but sendmail doesn't support that. In fact, looking at:
> 
> Wrong on two counts.
> 
>   1:    You can build sendmail with STARTTLS support.  In that case
> 	the session is encrypted, so it is safe to use plain text
> 	passwords in the encrypted channel.
> 
>   2:	Sendmail-8.12.x can be built with SASLv2, which does support
> 	NTLM.
> 
> As far as I can tell, this all works fine with Outlook Express.
> 
> In my tests, I couldn't get Outlook (the version that comes with
> Office-XP) to authenticate at all.  Apparently it is looking for the
> proprietary microsoft authentication procedure, and does not
> recognize RFC-compliant auth.  I think it is looking for the server
> to say "AUTH=LOGIN" instead of "AUTH LOGIN".
> 

I am not sure what you are recommending here. I take it that if we
build sendmail-8.12.x with SASLv2 we can support STARTTLS, which will
combine with AUTH LOGIN or AUTH PLAIN to support roaming users with
Eudora or Outlook Express at port 25. But what do we do for Outlook
users? Doesn't the warning about AUTH[=| ]LOGIN apply to AUTH[=| ]NTLM
also?

I wouuldn't suggest it in comp.mail.sendmail, but does anyone just
patch sendmail to offer AUTH=LOGIN and run it at some alternate port
for the benighted Outlook users? That sounds a lot easier than reverse
engineering NTLM, and once the entire session is encrypted, there
doesn't seem to be much need for NTLM.

Is SPA mentioned in the Outlook client properties menu the Microsoft
name for the MS variant of SMTP AUTH with method LOGIN?

As I parse the various answers to my posting I get the impression that
Outlook offers no combination of options that will keep passwords
encrypted, and require authorization for roaming users to relay, but
that all other clients just work.

Daniel Feenberg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

drfremove@nber.org (Daniel Feenberg) writes:
>Neil W Rickert <rickert+nn@cs.niu.edu> wrote in message news:<c4ld8p$nl3$1@usenet.cso.niu.edu>...
>> drfremove@nber.org (Daniel Feenberg) writes:

>> >We are looking for a way to require SMTP AUTH for our users submitting
>> >mail for relay from their Outlook clients. It seems that the only way
>> >to avoid exposing plain text passwords in Outlook is NTLM encryption,
>> >but sendmail doesn't support that. In fact, looking at:

>> Wrong on two counts.

>>   1:    You can build sendmail with STARTTLS support.  In that case
>> 	the session is encrypted, so it is safe to use plain text
>> 	passwords in the encrypted channel.

>>   2:	Sendmail-8.12.x can be built with SASLv2, which does support
>> 	NTLM.

>> As far as I can tell, this all works fine with Outlook Express.

>> In my tests, I couldn't get Outlook (the version that comes with
>> Office-XP) to authenticate at all.  Apparently it is looking for the
>> proprietary microsoft authentication procedure, and does not
>> recognize RFC-compliant auth.  I think it is looking for the server
>> to say "AUTH=LOGIN" instead of "AUTH LOGIN".

>I am not sure what you are recommending here. I take it that if we
>build sendmail-8.12.x with SASLv2 we can support STARTTLS, which will
>combine with AUTH LOGIN or AUTH PLAIN to support roaming users with
>Eudora or Outlook Express at port 25.

STARTTLS are two different things.

If you build with SASLv2, you get NTLM support.

If you build with '-DSTARTTLS', then you can additionally
use '-D_FFR_SMTP_SSL' to have direct ssl support.

>                                      But what do we do for Outlook
>users? Doesn't the warning about AUTH[=| ]LOGIN apply to AUTH[=| ]NTLM
>also?

I assume so.  I concluded that Outlook was worthless non-standard
conformant software, before I got that far.

>I wouuldn't suggest it in comp.mail.sendmail, but does anyone just
>patch sendmail to offer AUTH=LOGIN and run it at some alternate port
>for the benighted Outlook users?

Why?  It is far simpler (and wiser) to tell the Outlook user that
Outlook is broken by design.  These users can always switch to OE
which does work with standards compliant software.  If they don't
like that, they should bitch to Microsoft.

>Is SPA mentioned in the Outlook client properties menu the Microsoft
>name for the MS variant of SMTP AUTH with method LOGIN?

I have no idea.  I don't spend my life psycho-analyzing microsoft.

>As I parse the various answers to my posting I get the impression that
>Outlook offers no combination of options that will keep passwords
>encrypted, and require authorization for roaming users to relay, but
>that all other clients just work.

That's my impression.  As best I can tell, Outlook is only fit for
use in a private network that uses Microsoft proprietary protocols.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (SunOS)

iD8DBQFAb0QLvmGe70vHPUMRAlCxAJ9qTrtXFbHmH/9eKFNxl9w8msEHxQCg5hfa
hKemo9AI46jC0w2n55X6Fk0=
=3X/P
-----END PGP SIGNATURE-----