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?
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.
During this process, the archiving recipient passed to the agent becomes
a normal recipient of the new file, while the original envelope
recipients (both delivered and not-yet-delivered) are fetched directly
from the original queue file and stored in the body of the new queue
file in whatever format desired, together with any other envelope
information required. Of course, no special archive recipient record is
added to this new queue file.
Having such agent, all what needs to be changed in queue manager is that:
- When it sees the new Archive recipient record, it assigns that
recipient to this internal archive transport. Otherwise it treats it as
any other recipient. In particular, once this recipient is delivered
(which means the archive copy is created), it is reset by the queue
manager like any other recipient. No need for the archiving process to
trespass here at all.
- As long as there is an Archive recipient record active in the queue
file, the message may not be bounced or otherwise deleted. As you say,
this is to take care of the situation when the archive transport is not
working for whatever reasons.
All this can be built quite easily with the existing infrastructure. No
need to add another asynchronous client library talking to special
purpose daemon which would communicate by some other means. I think the
delivery route is the most natural one. It's like bcc-ing the message to
procmail script for archiving, except that it's all builtin and it can
collect the envelope information in its entirety.
Or am I missing something which makes the async daemon preferable?
Patrik
