Victor Duchovni:
> On Tue, Dec 28, 2010 at 09:23:14PM -0500, Wietse Venema wrote:
>
> > I have built an event-driven TLS proxy for postscreen(8). This
> > addresses the problem that postscreen(8) could not be used when
> > SMTP clients require STARTTLS support.
> >
> > [...]
> >
> > Next on the agenda is AUTH support, and that is a lot simpler.
>
> Will there be a snapshot with just the TLS proxy, or just a final
> snapshot when AUTH support is also done?
I think I'll release the TLS proxy code first. This involves an
editorial process to transform code that works into code that can
be published.
> Server-side AUTH support for multiple sessions likely cannot be
> implemented in a non-blocking fashion without some sort of concurrency,
> the SASL library may consult LDAP, or a variety of similar---potentially
> high-latency---data sources.
>
> So, unlike the TLS proxy, the AUTH proxy (as e.g. the Cyrus saslauthd
> service) may need to be a forking multi-process service.
As long as the postscreen side is event-driven, some latency in
AUTH support is not a problem. AUTH can be a plain old multi-server
like trivial-rewrite or proxymap, with the difference that the
protocol may have intermediate steps between initial request and
final response.
> Is AUTH support in postscreen really necessary? It seems to me that AUTH
> is submission, that should be on 587, not 25, where one does not want
> postscreen at all.
We have examples of deployments where MTAs have to authenticate.
I don't know if those MTAs have static IP addresses or not.
> Perhaps we can encourage better hygiene, by not offering AUTH in
> postscreen. People who want AUTH and postscreen, can migrate their AUTH
> users to port 587? Or is this still too much to ask of potential Postfix
> users?
I think that postscreen becomes much more viable when people don't
have to worry about smtpd protocol compatibility.
Wietse
