On Tue, 2009-08-04 at 13:20 +0900, Christian Balzer wrote: > Guess "more difficult" is putting it mildly. ;)
Heh :) Most of the commercial archiving systems I've seen which offer SOX and BasleII compliance tie into the backend store and act upon that, aswell as hooking delivery processes. That way they catch incoming mail from other systems plus intra-user mail on the same system. With the proliferation nowadays of systems with multiple components (frontend/backend systems, or clusters of machines with different roles) then it's the only way a complete archive can be guaranteed. Of course, with Exim, there is no simply defined "role" which makes the thought processes behind this rather muddy. At least with your definitions you are offering some clarity over what it is you require, which makes this one easier to consider. > I wonder if I could deliver it locally with a shadow transport to a place > that in turn triggers a remote delivery via .forward file or some such? That's a possibility *but* would add extra SMTP headers (viz received lines, envelope-headers and so on) which might make the compliance angle of an unmodified message slightly more difficult to achieve. However... Please excuse the stream of thought which follows! You already discounted shadow_transport because that's local only - but see below where I mention both the FIFO and pipe approaches. Assuming you're delivering to a Maildir, you do have the option of using an external delivery program instead of Exim's internal maildir code. Of course, you could use procmail if you wanted, or the equivalent Dovecot or Courier application. You could do that using the pipe transport: http://www.exim.org/exim-html-current/doc/html/spec_html/ch29.html#SECID143 Courier-IMAP supplies their "maildrop" package, dovecot supplies and LDA called "deliver". And there's always procmail (did I say that already?) :) How each of those would handle the "deliver this to two recipients" situation is difficult to say, especially as they are *local* delivery agents. Alternatively you could deliver using the appendfile transport to a FIFO with a process sitting on the end of it which receives the message, takes a copy, shovels the original message into the maildir (again using an external MDA) and at that point does what it needs to do with the copy to archive it. Again, at this point you could for example have some pseudo code in the FIFO listener doing something like this: listen { while (message arrives) { slurp message into RAM } if message { if (execute LDA to deliver to user mailbox locally) { execute other delivery to archive system } } } Obviously you'd need some error handling in there! This seems fraught with danger to me; if the process halts for some reason you'll be in big trouble. In fact, there are myriad ways in which this could fail. As a final alternative which you could expand upon, I reckon the safest way to achieve this is really to use an unseen router & transport pair. Humour me here. In the routers: <snip earlier routers> # In the two routers below, $CONDITION is identical! local_maildir_delivery: unseen driver = accept domains = +local_domains transport = local_maildir_delivery condition = <$CONDITION> archive_copy: driver = manualroute route_list = * ip.add.re.ss domains = +local_domains transport = archive_transport condition = <$CONDITION> errors_to = [email protected] <snip further routers> In the transports: local_maildir_delivery: driver = appendfile maildir_format directory = /var/spool/maildirs/$local_part/Maildir/ delivery_date_add envelope_to_add return_path_add group = exim mode = 0660 archive_delivery: driver = remote_smtp Then you'd need some appropriate configuration on your archiving box at ip.add.re.ss so it accepts everything it gets and handles errors appropriately (ie. by not bouncing to the originator of the message). This is about the simplest method I can see, although you may need to run it past the regulatory people within your organisation (or your auditors) to make sure they understand how it works. You also need to consider potential access methods, limits to that access, read-only or read-write (!), discovery and searching, authorised deletion of messages, how to prove that messages have not been tampered with, and so on. Almost all of these things are a mix of technical and policy decisions. If you can buy something off the shelf which works for you, I'd recommend it from the point of view that it means you/your company/organisation enters into an "approved" contract with a supplier who then takes the responsibility for the technical compliance aspects of the system. You may find that your local/regional regulatory regime will accept nothing else, sadly. I'm sure (I hope) someone else will pipe up now, if you'll excuse the terrible pun. Graeme -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
