Date: Sat, 13 Jul 2002 17:24:59 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Gregory Neil Shapiro <gshapiro@FreeBSD.ORG> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Mail subsystem defaults, adding authentication. Message-ID: <3D30C4DA.22A255A8@mindspring.com> References: <20020713034725.GB47677@ussenterprise.ufp.org> <3D2FAFB2.E2E9CF36@mindspring.com> <20020713045704.GA49379@ussenterprise.ufp.org> <3D300FD4.7479A8E5@mindspring.com> <15664.47827.844708.151118@monkeyboy.gshapiro.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Gregory Neil Shapiro wrote: > You need to go back and read the RFC's/documentation. > > First, you can limit the AUTH mechanisms offered based on whether STARTTLS > was used or not. Second, after a successful STARTTLS negotiation, a new > EHLO is done and a new set of AUTH mechanisms is given. I see it now. My bad. I was looking at 2246 and 2595, when I should have been looking at 3207. As you say, the race is addresses by the state reset requirement. > You can (and should) use STARTTLS with SMTP AUTH PLAIN/LOGIN and do not > (and should not) use SMTP over SSL as it is non-standard. IMO, this is broken. Here's why: Implementation of SSL in the kernel is a foregone conclusion. It is a matter of "when", not "if", due to work like that of Sam Leffler's recent porting of the OpenBSD crypto hardware interface framework to FreeBSD. Basically, asking for conversion of a socket from one type to another is not something that will necessarily be supportable. The whole "STARTTLS" thing was introduced to kludge around the lack of IPSEC support in IPv4. Even if you argue that it's an issue for IPv4 because IPSEC bloats the hell out of IPv4 even when it's not being used, IPv6 requires implementation of IPSEC for it to be called an IPv6 implementation. This means that the days of transport crypto decisions like this one, and the code to implement it, living in user space are numbered, no matter what. I know the sendmail folks don't like SMTP over SSL, but... there is an IANA assigned number in /etc/services for it, which makes it about as standard as it can be; I don't think SSL RFC policy requires a per protocol SSL usage RFC for SSL to be used (that wouldn't make sense, in terms of promoting the adoption of SSL). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D30C4DA.22A255A8>