OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: [PATCH] Documentation hints for SASL
From: Matthias Andree (madt.e-technik.uni-dortmund.de)
Date: Fri Dec 15 2000 - 08:50:22 CST

Daniel Roesen <droesenentire-systems.com> writes:

> On Fri, Dec 15, 2000 at 02:34:06PM +0100, Matthias Andree wrote:
> > ! Reportedly, Microsoft Internet Explorer version 5 requires the
> > ! non-standard SASL LOGIN authentication method. To enable this
> > ! authentication method, specify ``./configure --enable-login''.
>
> This is wrong. All M$ email products (Outlook, Outlook Express,
> Exchange) do that. IE5 has no email client AFAIK, it's a browser only.

Beware, this is a context diff. The original text that is subject to be
changed through the patch also has exclamation marks in the first
column.

> > ! BROKEN CLIENTS: Reportedly, Microsoft Outlook Express Version 5
> > ! requires the non-standard SASL LOGIN authentication method. To enable
> > ! this authentication method, specify ``./configure --enable-login''.
>
> See above.

I don't see your point. I changed the text from Internet Explorer to
Outlook Express.

> What is needed for Outlook Express 4 (not 5) is a hack for the ESMTP
> greeting. Standard is:
 
> 250-AUTH GSSAPI PLAIN LOGIN DIGEST-MD5 CRAM-MD5
>
> OE 4 needs:

> 250-AUTH=GSSAPI PLAIN LOGIN DIGEST-MD5 CRAM-MD5
> note the non-standard "=" it there.

Is not OE 4 younger than RFC-1869 (Nov. 1995)? RFC-1869 is explicit:

     ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF
                    / ( "250-" domain [ SP greeting ] CR LF
                        *( "250-" ehlo-line CR LF )
                           "250" SP ehlo-line CR LF )

     greeting ::= 1*<any character other than CR or LF>

     ehlo-line ::= ehlo-keyword *( SP ehlo-param )

     ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")

     ehlo-param ::= 1*<any CHAR excluding SP and all
                         control characters (US ASCII 0-31
                         inclusive)>

So 250-AUTH=ABC EXPLICITLY and DELIBERATELY violates a five-year-old
standard (STD 10). I recommend against breaking STD 10 conformance to
get compatible with a broken and discontinued product.

It's not to be like "Microsoft can dictate how broken standards must be
implemented", but rather "They could have implemented it correctly if
only they had wanted to". Note that they didn't even fix the MIME bugs
present in OE4 for OE5, so expect similarly sluggish "response" to
problems and incidents throughout all of their mail/news products.

Don't let broken, discontinued clients interfere with a current mail
transfer agent.

MIME bugs := OE cannot indent quoting properly when the original was
base64 or quoted-printable encoded.

> Freemail Provider GMX hacked their SASL implementation to present
> both:

Not a good example, not desirable for Postfix. Broken clients will stay
around forever if they are looked after in this way.

> Not "to _a_" but "to _the_ FQDN of the host running Postfix".
> I'm not sure wether it has to be the FQDN of the primary IP of the
> host or whatever FQDN. This will be checked.

Who will check what?

[chroot]
> /etc/sasldb is sufficient, at least here (on Red Hat 6.2).

SuSE 7.0:

$ ldd /usr/lib/postfix/smtpd
        libsasl.so.7 => /usr/local/lib/libsasl.so.7 (0x40023000)
        libdb.so.3 => /lib/libdb.so.3 (0x4002f000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4006d000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40084000)
        libc.so.6 => /lib/libc.so.6 (0x40093000)
        libdl.so.2 => /lib/libdl.so.2 (0x40176000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4017b000)
        libpam.so.0 => /lib/libpam.so.0 (0x401a8000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Will check if a copy of /usr/lib/sasl/lib* is needed inside the chroot
(not sure if libsasl.so does dynamic loading on its own, probably will.) 

-- 
Matthias Andree