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 = archivemanager@???
<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
