[Oberon] Re: 2: Have we got email send authenticate ability ?

[W B Hacker]

Roger Keller wrote:

>>Since the highest technical specification is that "it must work 
>>with today's flavour of WINxx" I/we need to know what type
>>of send-authentication Outlook uses ?
>>
>>I had another look at TextMail.Mod [which now I remember I
>>previously modified to handle my (given to me) ID of > 16 chars]
>>The code is well structured for modifying/extending.
>>And if I could find out which type of send-authentication
>>Outlook uses, the appropriate RFC could make it doable.
> 
> 
> there's no magic with the authentication used by outlook. in fact it's using
> the standard as described in 
> RFC 2554: http://www.ietf.org/rfc/rfc2554.txt
> 
> --roger
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 

smtp-after-pop was not 'driven' so much because of MUA 
limitations, but simply 'coz it was 'easier' in the 
once-very-common:

Qmail+Vpopmail+MySQL+Courier-IMAP/POP+Squrrelmail+QmailAdmin,
+ (whatever other 'language' overlooked).

There is no problem supporting several other forms of AUTH with 
most MUA's, MTA/MSA's and IMAP/POP daemons.

IIRC, at least current versions of Lookout and OE both do plain, 
SSL and/or TLS, and with plain or CRAM-MD5, and probably have 
done for some years now. Not always 'correctly' in all respects.

Dialup *is* still useful, and is usually encrpted in a ppp 
tunnel between workstation and ISP point-of-presence, but then 
'en clair' again from there to the mx server unless SSL is 'forced'.

TLS, OTOH, does reveal some information 'en clair' during the 
EHLO/HELO handshake before STARTTLS encryption is is set up.  IF 
it is even selected or 'fallback' denied so it is set up at all...

HTH,

Bill