Victor Duchovni:
> On Thu, Mar 19, 2009 at 11:58:52PM +0100, mouss wrote:
>
> > I would suggest separating relay control from other checks. something like
> >
> > smtpd_relay_restrictions =
> > permit_mynetworks
> > permit_sasl_authenticated
>
> This has been proposed before.
>
> http://archives.neohapsis.com/archives/postfix/2006-05/0598.html
>
> Perhaps some day, it would be a major change, and the question is whether
> it is worth the effort if it is only an interim design. When you change
> something this big, the new feature should be stable for a long time.
>
> Changing the interface with every release becomes unpopular with users.
> So the current design for all its flaws is stable, and has proved
> reasonably flexible. A new design would need a lot of scrutiny to make
> sure we have a solid solution good for another decade of releases.
>
> One could, take this to the extreme and introduce a new (not replacement,
> but alternative) SMTP server called "pysmtpd" that bolts a Python
> interpreter into Postfix, and provides all the restriction building blocks
> (various lookups, ...) as functions in the Python interpreter. Then, in
> "pysmtpd" you'd tweak Python code to make access decisions. There'd be
> of stock rules and a gentle configuration syntax for non-programmers,
> but the underlying rule engine would be a full programming language
> extensible by module writers and advanced users.
>
> Lots of other possibilities. Which approach is right?
One of the goals of Postfix was to provide a system that is more
secure than other MTAs. For this reason I would not build something
as complex as perl/php/python/etc. into a process that is directly
exposed to the network. If I wanted to do that, I would have built
Postfix like other MTAs.
Instead, an architecture based on delegation can provide the
necessary isolation and functionality: one process to weed out
connections from botnets and spammers at minimal resource cost,
while delegating complex policies and SMTP handling to less exposed
and more expensive helpers. While process creation remains relatively
expensive and needs to be minimized, IPC is cheap enough.
Wietse
