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... To me, it seems that the archive recipient from the queue manager's POV is as any other recipient, except that it is automatically routed to it's own archive transport which passes the message to the archive delivery agent. Plus the extra treatment of the bounces. Other than that, it doesn't seem to need to be treated much differently. Of course, unless it is really mandatory that the message is passed to archive before anywhere else. But if it is not necessary, I would say it doesn't matter when exactly it is archived, as long as it is archived. And it would be, because it would sit in the queue file until the last of the recipients would be delivered, and would never bounce or otherwise go away until the archive recipient is cleared. And even if it would be required to be archived before anywhere else, I think it would be quite easy to adjust qmgr so it ignores any recipients other than the archive ones, and only after those were delivered, allows reading in the other ones from the queue file. This behavior could be even controlled on per message basis, if necessary. So, to sum it up, I would rather treat the archive process as an delivery agent, rather than a daemon similar to bounce or defer daemons. In this form, archiving is just a special form of a bcc which automatically transforms the message along the way. No risk of delays induced by waiting for archival to complete either. On Fri, 29 Mar 2013, Viktor Dukhovni wrote: > > S: 354 End data with <CR><LF>.<CR><LF> > > C: From: <original-sender@sender-domain> > > To: <original-recipient1@recipient-domain1>, > > <recipient2@recipient-domain2> > > The message envelope could be quite large, since a message > can have thousands of recipients after virtual(5) expansion. > Putting all envelope recipients in the "To:" header risks > running into header length limits that cause header truncation > or parsing problems. One needs to split it among multiple To: headers. It is the best practice anyway. Postfix itself can handle only limited amount of recipients in single header, while it can deal with huge amounts when each is given its own To/Cc/Bcc: header. > Unlike Postfix, some software imposes limits on the total size > of the header, not just individual header records. > > Therefore, the envelope should be presented a MIME body part. > > If the above is not compelling, and there is no message body part > containing the envelope (which is carried above in headers) then > we don't need a multipart encapsulation of the inner message, just > set the outer content-type to message/rfc822. I guess it would be best to make this part a configurable option of the archiving daemon. After all, I guess that there might be couple more transformation options which might people might want to adjust depending on their needs. Patrik
