On Wed, 05 Aug 2009 10:31:16 +0100 Graeme Fowler wrote:
>
[SOX compliance]
Well, this was an example mostly, please do note that this ain't Kansas
and that as far as I know J-SOX has a lot less strings attached to it.
Either way, my first goal is an archive, compliance with local laws is
something somebody else needs to worry about.
We're an ISP and my original target is to be able to offer people an
archive option if they are willing to admit to themselves that they are
likely stupid enough to blow away their mailbox at some point in time. ^o^
They usually manage that via webmail or when setting up a POP3 account on
their parents machine when they visit there, which keeps on emptying their
mailbox before they can. ;)
Any application of this for J-SOX purposes would be a nice bonus.
>
> > 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.
>
Don't think additional headers are an issue. The copies of outgoing mails
(easy to achieve) would not be "original" either in that sense.
I will give that a try later and see if I can cook something up.
> However... Please excuse the stream of thought which follows!
>
You shall be excused, I'll be cutting it down to size.
> 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.
>
Using Dovecot here and while I love it to pieces I'm not about to change
the LDA to it. Several reasons for that, one being that we are giving
people with full mailboxes a grace period and queue stuff up for that
duration. Which of course only works with Exim doing the final delivery.
[Very smartypants pipe construct sniped]
> 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.
>
Indeed. I have been thinking about something like that as well and was
not happy with the failure points.
> 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@???
>
This still does not address the potential of mails not being delivered by
the local delivery transport.
Hmmm. I wonder if there is a way to tell the 2nd router that the
transport of the first one succeeded...
But a glance at the various variables does not reveal anything.
[...]
> 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).
>
That is a very valid point, it needs to be a total black hole in that
regard.
> 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.
>
I'm sure having potentially mails in the archive the actual user never saw
is a show stopper there. ;)
> 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.
>
Yeah, that is something for other people to worry about, AFAIK read-only
media is not required for J-SOX.
> 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.
>
Again, this is not for us internally and _if_ I get this to work we would
be one of those vendors/suppliers. ;)
> I'm sure (I hope) someone else will pipe up now, if you'll excuse the
> terrible pun.
>
So far none, I guess they could not stand the pun-ishment.
Regards,
Christian
--
Christian Balzer Network/Systems Engineer NOC
chibi@??? Global OnLine Japan/Fusion Network Services
http://www.gol.com/
https://secure3.gol.com/mod-pl/ols/index.cgi/?intr_id=F-2ECXvzcr6656
