Patrik Rak:
> On 29.3.2013 13:14, Wietse Venema wrote:
> > Patrik Rak:
> >> On Thu, 28 Mar 2013, Wietse Venema wrote:
> >>
> >>> - When the queue manager opens a queue file that contains an archive
> >>> recipient address record, it first contacts the archive daemon
> >>> before attempting to deliver the message.
> >>>
> >>> ....
> >>>
> >>> - After the archive daemon has queued an archive message, the archive
> >>> daemon clears the archive recipient record in the queue file and
> >>> reports successful completion to the queue manager. Then, the queue
> >>> manager processes the queue file for normal delivery.
> >>
> >> Is it really required that the message is archived before any further
> >> processing continues? It seems to only introduce delays...
> >
> > In the draft, the archive copy is *created* before normal message
> > delivery to recipients. The archive copy can be delivered later.
> >
> > The archive copy could be created *after* each delivery attempt.
> > Then, the queue file should not be deleted before the archive daemon
> > has cleared the archive-recipient record. This would allow deliveries
> > to continue while the archive daemon is unavailable.
>
> That was exactly my point - the archive copy might be delivered to
> archive recipient after the original message was delivered to original
> recipients anyway, so why bother with the whole asynchronous daemon
> thing at all?
The archive copy must be submitted asynchronously, just like email
is delivered asynchronously, and just like a bounce message is
submitted asynchronously.
> Imagine an archive delivery agent, which works basically like the local
> delivery agent when it forwards a message copy. The only difference is
> that it tweaks the message a bit by adding the expanded information for
> archiving purposes as it queues it via the cleanup daemon back to postfix.
For the archive service to be a delivery agent, Postfix should
produce sensible behavior when people send mail directly to it with
transport_maps or whatever, including all the delivery agent features
that can be tweaked such as rate limits, concurrency scheduling,
and so on. If it doesn't produce sensible behavior in all forseeable
scenarios, then it would only save a few lines of code at the expense
of introducing more opportunities for mistake.
For example, if the bounce daemon were an agent that delivers mail
to the envelope sender, then that could result in chaos as people
configure Postfix to send mail there directly with transport_maps
or whatever (what does it mean to deliver mail directly to the
"trace" or "success" service, when that mail was submitted with
"sendmail -bv" or "sendmail -N success"?) Instead, Postfix has the
"error" and "retry" transports (and no transports that correspond
to the "success" or "trace" services).
Wietse
