From: Wietse Venema (wietseporcupine.org)
Date: Sat Jun 28 2003 - 09:30:05 CDT

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

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.

Each feature comes at a cost. I wonder if the cost of this one is
justified, considering that almost no-one will be using it.

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.

Remember how the external content filter was implemented. It was
not added as a different mail handling process internal to Postfix.
Instead it uses all the existing infrastructure and external
interfaces. The additional complexity and overhead is experienced
only by those who actually want to use this functionality. The
price is that mail changes queue file upon filtering. The benefit
is that a lot of complexity never needed to be implemented.

If other exotic features can be implemented by chaining delivery
agents (including special-purpose delivery agents) then I would
favor that over burdening regular mail delivery with a lot of code
that almost no-one uses. Add new functions on the periphery if
possible, instead of burdening the core with ever increasing
complexity.

        Wietse

Victor.Duchovnimorganstanley.com:
> On Fri, 27 Jun 2003, Wietse Venema wrote:
>
> > Victor.Duchovnimorganstanley.com:
> > >
> > > The current implement of "REDIRECT" generates not one recipient per
> > > message, but rather one recipient (identical) per
> > > $qmgr_message_recipient_limit recipients.
> > >
> > > Perhaps this was easier to implement, but it is not clear why. Is it
> >
> > Because some bunch of criminals was flooding my SMTP port with the
> > bounces from their SPAM campaign and I did not have time.
> >
> > You're welcome to provide a demonstrably correct implementation
> > that handles many recipient email messages.
> >
>
> OK, I have an implementation that with small changes, arranges to deliver
> to the "REDIRECT" recipient exactly once (in the context of the first
> queue file recipient). It fixes the per-batch anomaly, and even takes care
> of the ambiguity of the orig_to records when the message has multiple
> recipients.
>
> This time I would like to avoid the usual (for me) trap of solving the
> narrow problem, when perhaps a more general solution is in order.
> Specifically the following issues remain:
>
> - Tracking/logging the status (done/not done) of the redirect recipient in
> the context of the first real recipient record feels wrong.
>
> - The log data for the message is inconsistent, the queue manager logs N
> recipients, but delivers only to one. No mention of the remaining
> recipients appears in the logs, they seem to just vanish.
>
> - Warnings and bounces might be sent to the envelope sender even though
> the message was diverted. The fact that the message is diverted is
> typically not something one wants to share with the sender.
>
> So I would like to propose the following incompatible redesign:
>
> 1. The REDIRECT feature should be renamed to "DIVERT" to reduce confusion
> with ".redirect in Sendmail, which is "relocated_maps" in Postfix.
>
> 2. The DIVERT recipient should be written to the queue file as a special
> recipient record (special recipients are designated with a preceding
> REC_TYPE_RTYPE record).
>
> ...
> REC_TYPE_RTYPE: divert
> REC_TYPE_ORCPT: ""
> REC_TYPE_RCPT: <address>
>
> 3. OPTIONAL: Multiple DIVERT recipients are supported. The cleanup daemon
> maintains a duplicate filter for divert recipients, so any given DIVERT
> recipient occurs once (modulo duplicate filter limits).
>
> Otherwise only the first DIVERT recipient counts, "cleanup" writes at
> most one DIVERT record per queue file.
>
> In either case the recipient count in REC_TYPE_SIZE is the total
> number of ordinary and DIVERT recipients.
>
> 4. When "divert" recipients are present, the queue manager marks all
> the ordinary (non-divert) recipients as delivered and logs them as
> as follows:
>
> postfix/qmgr[pid]: QID: to=<address>, relay=none, delay=0, status=diverted
>
> This takes care of the missing recipients problem. The logs reflect all
> recipients.
>
> 5. The queue manager delivers any "divert" recipients, but bounces and
> warnings are not sent to the envelope sender. Delay notices are
> always suppressed and bounces are optionally sent (suitable
> notification) to $divert_bounce_recipient (default $bounce_recipient).
>
> 6. Finally this is similar enough to my archiving goals (except for how
> the message body is handled) that the two mechanisms might share a lot
> of code. Both create special recipients with distinct error handling
> and separate queueing.
>
>
> If people convince me that the above is crazy, I can release the
> conservative patch. Otherwise I would like to solicit constructive
> feedback and perhaps both the "DIVERT" and "ARCHIVE" problems can be
> solved with similar mechanisms.
>
> --
> Viktor.
>
>

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