Re: mailfront on IPv6

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

On Wed, Jun 29, 2011 at 5:28 PM, Bruce Guenter <[email protected]> wrote:

> On Wed, Jun 29, 2011 at 02:02:40AM -0400, Scott Gifford wrote:
> > My original patch also adds this support to pop3front and imapfront.  I
> > assumed they provided a similar plugin mechanism to smtpfront, but maybe
> > not?
>
> No, there are no plugins for pop3front or imapfront, and they don't make
> sense for that neither since the existing plugin architecture only
> handles accepting messages.
>
> Incidentally, handling TLS in-process for the latter two is particularly
> problematic, as they end up exec'ing a child process after
> authentication.  Either the parent would need to hang around handling
> the SSL/TLS translation (thus negating the value of in-process
> translation), or all the information about the translation would need to
> be handed off to the child so it could continue uninterrupted.
>

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.


> > The ability to add EHLO capabilities and new verbs?  I personally
> probably
> > wouldn't use it for anything else, but to speculate on some possible
> uses:
> >
> >    - Some existing mailfront features could be implemented as plugins
> which
> >    add a new capability and verb, in particular SMTP authentication
>
> Ok, you've convinced me.  Now the question is whether to add it to the
> existing plugin framework, or add a new one just for protocol
> manipulation.  Is it of any use to add this facility to the pop3front or
> imapfront?
>

Yes, it's very valuable to add this facility to pop3front and imapfront IMO,
my existing patch does this and I use it nearly everywhere I use smtpfront.
 So a plugin interface (or 3 similar plugin interfaces) that could support
all protocols would be very useful.

------Scott.

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

On Wed, Jun 29, 2011 at 5:28 PM, Bruce Guenter <span dir=3D"ltr">&lt;<a hre=
f=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">On Wed, Jun 29, 2011 at 02:02:40AM -0400, Scott Gifford w=
rote:<br>
&gt; My original patch also adds this support to pop3front and imapfront. =
=A0I<br>
&gt; assumed they provided a similar plugin mechanism to smtpfront, but may=
be<br>
&gt; not?<br>
<br>
</div>No, there are no plugins for pop3front or imapfront, and they don&#39=
;t make<br>
sense for that neither since the existing plugin architecture only<br>
handles accepting messages.<br>
<br>
Incidentally, handling TLS in-process for the latter two is particularly<br=
>
problematic, as they end up exec&#39;ing a child process after<br>
authentication. =A0Either the parent would need to hang around handling<br>
the SSL/TLS translation (thus negating the value of in-process<br>
translation), or all the information about the translation would need to<br=
>
be handed off to the child so it could continue uninterrupted.<br></blockqu=
ote><div><br></div><div>I would have to review my patches to see how this i=
s handled now, but in practice it doesn&#39;t matter: all clients in the wi=
ld start TLS before they authenticate.</div>

<div>=A0</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">
&gt; The ability to add EHLO capabilities and new verbs? =A0I personally pr=
obably<br>
&gt; wouldn&#39;t use it for anything else, but to speculate on some possib=
le uses:<br>
&gt;<br>
</div>&gt; =A0 =A0- Some existing mailfront features could be implemented a=
s plugins which<br>
<div class=3D"im">&gt; =A0 =A0add a new capability and verb, in particular =
SMTP authentication<br>
<br>
</div>Ok, you&#39;ve convinced me. =A0Now the question is whether to add it=
 to the<br>
existing plugin framework, or add a new one just for protocol<br>
manipulation. =A0Is it of any use to add this facility to the pop3front or<=
br>
imapfront?<br></blockquote><div><br></div><div>Yes, it&#39;s very valuable =
to add this facility to pop3front and imapfront IMO, my existing patch does=
 this and I use it nearly everywhere I use smtpfront. =A0So a plugin interf=
ace (or 3 similar plugin interfaces) that could support all protocols would=
 be very useful.</div>

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

--20cf307f32a654356f04a6ed972d--