From: Wietse Venema (wietseporcupine.org)
Date: Sat Jun 28 2003 - 19:01:39 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Victor.Duchovnimorganstanley.com:
> On Sat, 28 Jun 2003, Wietse Venema wrote:
>
> [ Paragraph moved up ]
> > For example, I would implement archival with just a little delivery
> > agent that spits out the envelope before spitting out the content
> > as message/rfc822, and then injects the result into the queue just
> > like Postfix normally forwards mail internally. It costs a few
> > more cycles, but it is trivial to implement and most importantly,
> > it does not require surgery of existing core infrastructure.
> >
>
> Exactly! This is the design goal, to do extremely efficient archiving out
> of the same queue file via suitable delivery agents without cloning the
> message. For wart-free behaviour, I do not want archive recipients to be
> visible in error/delay notices. I would also like archive deliveries to
> always have soft_bounce = yes.
>
> > You basically introduce multiple classes of recipients in the same
> > queue file. One recipient class has pre-empts delivery to another
> > class; one class produces DSNs and the other doesn't. Since the
> > whole concept does not exist, major surgery is required in the
> > queue manager and in the way that bounce reports are being handled.
> >
>
> Is not some of this already necessary to implement REDIRECT (DIVERT) in a
> wart-free fashion? (Log completeness/consistency, once per message
> delivery, original recipient handling, ...) It is possible that REDIRECT

The idea is to IGNORE the original recipients. It is nothing but
the DISCARD action in disguise. In both cases, Postfix lies to the
sender and promises that the mail will be delivered to all the
specified recipients. Like DISCARD, REDIRECT overrides all other
routing or delivery decisions.

For a more proper implementation I'd consider a little delivery
agent that prepends the envelope to the message/rfc822 content.
If this delivery agent can be configured to never bounce to the
original sender, then don't we have all that's needed? There is
already per sender and per recipient bcc.

> We have some klunky divert/screen capabilities in our content filter. They
> are used for handling persistent email harrassment and compliance
> investigations. "Divert" reroutes mail from harrassers to corporate
> security for evidence collection in cease/desist orders, "screen" is
> almost obviated by "always_bcc", except that "screen" is invisible to the
> sender (no delay or error notices).
>
> On further thought I don't think we need orthogonal recipient classes,
> just a few combinable recipient flags:

Postfix currently does not have the concept of per recipient flags.
Introducing a new architectural concept like this introduces a
great deal of complexity that sits forever in the critical code
path even when most people don't useo it.

> If the queue manager merely kept track of flags, and passed them around to
> "bounce" and the delivery agents, could the special bounce handling be
> delegated also?

With Postfix, the queue manager passes recipient information to
delivery agents. If some recipient can't be delivered, a delivery
agent informs the bounce daemons. This straight one-way flow of
information is essential to the Postfix architecture. If there
were recipient flags, it would be improper to bypass delivery
agents. I don't even see how the delivery agent would know what
recipients were subject to bouncing.

> Perhaps just enhancing soft_bounce to work per-recipient, and suppressing
> delay notices to soft_bounce recipients would get most of the job done.
>
> The most complex mechanism in this space is in fact the already
> implemented REDIRECT/DIVERT. ARCHIVE and SCREEN don't pre-empt other
> deliveries and behave like ordinary recipients in every way except when
> bouncing.
>
> I am looking for design feedback, any suggestions? I am volunteering to
> implement any sensible design in this space that meets with your
> architectural goals and still accomplishes my archiving/screening
> requirements.

Consider that it took me a couple months of hard thinking to set
up the Postfix architecture which still does hold up very well.
Adding new concepts requires either that it goes in an external
interface program, or otherwise it will have to be thought out
damned well.

        Wietse

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]