Re: mailfront on IPv6

--20cf307f363a524baa04a6eebd6a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 30, 2011 at 10:18 AM, John R. Levine <[email protected]> wrote:

>  I would have to review my patches to see how this is handled now, but in
>> practice it doesn't matter: all clients in the wild start TLS before they
>> authenticate.
>>
>
> RFC 4954 suggests pretty strongly that you wouldn't want to do AUTH and
> then STARTTLS.  On the other hand, an entirely valid and occasionally useful
> way to use STARTTLS is for the client to present its own certificate in the
> TLS negotiation which the server uses to authenticate the client.  The
> STARTTLS patches for qmail-smtpd do that, and set RELAYCLIENT appropriately.


My patches send the pre-parsed SSL information over a socket in an
easy-to-use format designed to be imported into the environment, so an
appropriate plugin could make use of this information to automatically
authenticate based on certificate credentials by checking these variables.
 I haven't had a need for this, so I haven't implemented it, but the
architecture allows for it.

 The ability to add EHLO capabilities and new verbs?
>>>>
>>>
> That will be very handy when EAI comes along.  While you're at it, you'll
> want to handle extra parameters on MAIL FROM and (if you support them at
> all) EXPN and VRFY.
>

Support for extra FROM parameters would make the SIZE extension possible as
a plugin too, I think, although it may be too simple to bother with.

-----Scott.

--20cf307f363a524baa04a6eebd6a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 30, 2011 at 10:18 AM, John R. Levine <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:[email protected]">[email protected]</a>&gt;</span> wrote:<br><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
I would have to review my patches to see how this is handled now, but in<br=
>
practice it doesn&#39;t matter: all clients in the wild start TLS before th=
ey<br>
authenticate.<br>
</blockquote>
<br></div>
RFC 4954 suggests pretty strongly that you wouldn&#39;t want to do AUTH and=
 then STARTTLS. =A0On the other hand, an entirely valid and occasionally us=
eful way to use STARTTLS is for the client to present its own certificate i=
n the TLS negotiation which the server uses to authenticate the client. =A0=
The STARTTLS patches for qmail-smtpd do that, and set RELAYCLIENT appropria=
tely.</blockquote>

<div><br></div><div>My patches send the pre-parsed SSL information over a s=
ocket in an easy-to-use format designed to be imported into the environment=
, so an appropriate plugin could make use of this information to automatica=
lly authenticate based on certificate credentials by checking these variabl=
es. =A0I haven&#39;t had a need for this, so I haven&#39;t implemented it, =
but the architecture allows for it.=A0</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">


The ability to add EHLO capabilities and new verbs?<br>
</blockquote></blockquote></blockquote>
<br></div>
That will be very handy when EAI comes along. =A0While you&#39;re at it, yo=
u&#39;ll want to handle extra parameters on MAIL FROM and (if you support t=
hem at all) EXPN and VRFY.<br></blockquote><div><br></div><div>Support for =
extra FROM parameters would make the SIZE extension possible as a plugin to=
o, I think, although it may be too simple to bother with.</div>

<div><br></div><div>-----Scott.</div><div><br></div></div>

--20cf307f363a524baa04a6eebd6a--