Reinject to Postfix, or just send on to LMTP?

[/dev/rob0]

Please forgive what might be a too-basic question. I'm setting up a
new system with Postfix/virtual delivering to Dovecot LMTP. I'm not
quite understanding if there is any benefit to this design:
Postfix -> Amavisd-new -> Postfix/reinject -> Dovecot LMTP
as opposed to this:
Postfix -> Amavisd-new -> Dovecot LMTP

I understand that I'd need either two amavisd processes or policy
banks on alternate ports for submission and sendmail, and I'd still
need that reinject smtpd for the outbound mail:
Postfix -> Amavisd-new -> Postfix/reinject -> remote SMTP
But I don't see any reason why a policy bank can't handle that, with
forward_method in the appropriate policy bank: LMTP to localhost for
incoming, SMTP to Postfix/reinject for outgoing.

Postfix would route incoming mail to amavisd via a virtual_transport
setting, and route outgoing to the other amavisd port (i.e., 10024)
with a check_client_access static:filter,smtp:[127.0.0.1]:10024
restriction. (I'm not sure if the comma will work in a static: map,
but if it doesn't I know several workarounds. :) ) I'd only need a
content_filter setting as an -o on pickup(8).

Does this make sense? I hate the log clutter of the double-pass
through Postfix, so if I can avoid it, I will.
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

[Ralf Hildebrandt]

* /dev/rob0 <ro...@gmx.co.uk>:

> Please forgive what might be a too-basic question. I'm setting up a
> new system with Postfix/virtual delivering to Dovecot LMTP. I'm not
> quite understanding if there is any benefit to this design:

> Postfix -> Amavisd-new -> Postfix/reinject -> Dovecot LMTP

The first postfix only checks for unknown users
Postfix/reinject does alias expansion/virtual_aliasing

If you don't need "alias expansion/virtual_aliasing", denn

> as opposed to this:
> Postfix -> Amavisd-new -> Dovecot LMTP

is for you.

--
Ralf Hildebrandt Charite Universitätsmedizin Berlin
ralf.hil...@charite.de Campus Benjamin Franklin
http://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155

[Ralf Hildebrandt]

* Ralf Hildebrandt <Ralf.Hil...@charite.de>:

> * /dev/rob0 <ro...@gmx.co.uk>:
> > Please forgive what might be a too-basic question. I'm setting up a
> > new system with Postfix/virtual delivering to Dovecot LMTP. I'm not
> > quite understanding if there is any benefit to this design:
>
> > Postfix -> Amavisd-new -> Postfix/reinject -> Dovecot LMTP
>
> The first postfix only checks for unknown users
> Postfix/reinject does alias expansion/virtual_aliasing

At least in the "usual" setup with
receive_override_options=no_address_mappings

[/dev/rob0]

On Sun, May 26, 2013 at 07:11:20PM +0200, Ralf Hildebrandt wrote:
> * /dev/rob0 <ro...@gmx.co.uk>:
> > Please forgive what might be a too-basic question. I'm setting up
> > a new system with Postfix/virtual delivering to Dovecot LMTP. I'm
> > not quite understanding if there is any benefit to this design:
>
> > Postfix -> Amavisd-new -> Postfix/reinject -> Dovecot LMTP
>
> The first postfix only checks for unknown users
> Postfix/reinject does alias expansion/virtual_aliasing
>

> If you don't need "alias expansion/virtual_aliasing", denn
>
> > as opposed to this:
> > Postfix -> Amavisd-new -> Dovecot LMTP
>
> is for you.

Oh, good point. Thanks. I need to plan for how a virtually aliased
address would be handled. It's quite possible that something could
come in via the MX port but end up going out to the Internet. That
was what I missed.

On further thought I think it will work well enough. I won't need
receive_override_options (as you mentioned in the other post.)

In virtual_alias_maps (example.com being my virtual mailbox domain,
remote.tld being external):

us...@example.com us...@example.com,us...@remote.tld

Postfix splits this into two deliveries. One goes to amavisd via
virtual_transport. Amavisd filters this as incoming and passes
whatever remains of it to Dovecot LMTP. The other one hits my
wildcard FILTER rule and goes to amavisd's other port as outbound
mail.

This raises a point that maybe I'll want another policy bank with
stricter rules (lower spam thresholds in particular) for such
departing mail which originated externally.

I guess I'll be filtering submission mail destined to the
virtual_transport twice, but that doesn't bother me. Better too much
scrutiny applied than too little.

Off the subject, but I'm wondering: will amavisd support the new
multiple recipient_delimiter feature that Postfix 2.11 will have?