Re: how to deal with mail retention/archival.

[André Felipe Machado via Info-cyrus]

Hello
1 - http://www.enkive.org ?
2 - expunge delay , but sent msg on client not copying to a sent folder?
3 - postfix always bcc to a second Cyrus system?
Regards
André Felipe



Em 27 de agosto de 2016 13:29:14 BRT, Bron Gondwana via Info-cyrus 
 escreveu:
>
>
>
>On Sat, 27 Aug 2016, at 02:13, Shawn Bakhtiar via Info-cyrus wrote:
>>
>>> On Aug 26, 2016, at 8:35 AM, Giuseppe Ravasio (LU) via Info-cyrus
>>> cy...@lists.andrew.cmu.edu> wrote:
>>>
>>> I saw that someone proposed to make a sort of abuse of delayed
>>> expunge,
>>>  but I think that in order to comply with regulatory retention
>>>  should be
>>>  better considering some specific software.
>>>
>>
>> I don't see how using delayed expunge would really be consider abuse,
>> the documentation makes mention of its use for this very reason.
>
>You will hit performance issues. All expunged messages need to be
>scanned over at every select and refresh.
>
>> "In any case, the time between a message arriving and being deleted
>> may not be sufficient to ensure the message is replicated, included
>in
>> the next backup cycle, and generally available for recovery or
>> compliance with the regulatory environment."
>> --src  https://cyrusimap.org/imap/features/delayed-expunge.html
>
>If you are replicating to a system that's backing up, then you need
>delayed delete to ensure everything gets replicated.
>
>The backup system that's in development uses the sync protocol to feed
>the data from Cyrus into the backups.
>
>> We use rsync to make a duplicate of the email spool to a file server
>> at regular intervals, which eventually makes its way to tape.
>Although
>> we don't have regulatory requirements I've had to do a few recoveries
>> and have done so without problem.
>>
>> in our case we have cyr_expire set to 3 days (I believe the default
>> config), which provides more than enough time to in case a backup
>> fails for some reason or another.
>>
>>
>>> For example:
>>> http://www.mailpiler.org (Fully Free Software)
>>> https://www.mailarchiva.com (the old version is opensource but the
>>>  latest is closed)
>>>
>>> The specific software will be much better for searching the archive.
>>>  Finding something in the delayed_expunge folders after many years
>of
>>>  archive will absolutely be a nightmare!
>>>
>>
>>
>> Of course these tools offer features but that all comes at a price.
>>
>>
>>>
>>
>>
>>> Giuseppe
>>>
>>>
>>>  On 08/26/2016 03:09 PM, Alvin Starr via Info-cyrus wrote:
>>>
 A company I am working with is facing issues of regulatorymail
 retention.

  Some searching has yielded little useful results other than
  putting a
  system in front to store all incoming messages.

  What are others doing for mail archival?

  An ideal solution would let the users carry on using current use
  patterns and not impose extra restrictions.

  --
  Alvin Starr   ||   voice: (905)513-7688
  Netvel Inc.   ||   Cell:  (416)806-0133
 al...@netvel.net ||



  
  Cyrus Home Page: http://www.cyrusimap.org/
  List Archives/Info:
  http://lists.andrew.cmu.edu/pipermail/info-cyrus/
  To Unsubscribe:
 https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

>>> 
>>>  Cyrus Home Page: http://www.cyrusimap.org/
>>>  List Archives/Info:
>>>  http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>>>  To Unsubscribe:
>>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>>
>> 
>> Cyrus Home Page: http://www.cyrusimap.org/
>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>> To Unsubscribe:
>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>
>--
>  Bron Gondwana
>  br...@fastmail.fm
>
>
>
>
>
>Cyrus Home Page: http://www.cyrusimap.org/
>List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>To Unsubscribe:
>https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Bron Gondwana via Info-cyrus]

On Sat, 27 Aug 2016, at 02:13, Shawn Bakhtiar via Info-cyrus wrote:
>
>> On Aug 26, 2016, at 8:35 AM, Giuseppe Ravasio (LU) via Info-cyrus > cy...@lists.andrew.cmu.edu> wrote:
>>
>> I saw that someone proposed to make a sort of abuse of delayed
>> expunge,
>>  but I think that in order to comply with regulatory retention
>>  should be
>>  better considering some specific software.
>>
>
> I don't see how using delayed expunge would really be consider abuse,
> the documentation makes mention of its use for this very reason.

You will hit performance issues. All expunged messages need to be
scanned over at every select and refresh.

> "In any case, the time between a message arriving and being deleted
> may not be sufficient to ensure the message is replicated, included in
> the next backup cycle, and generally available for recovery or
> compliance with the regulatory environment."
> --src  https://cyrusimap.org/imap/features/delayed-expunge.html

If you are replicating to a system that's backing up, then you need
delayed delete to ensure everything gets replicated.

The backup system that's in development uses the sync protocol to feed
the data from Cyrus into the backups.

> We use rsync to make a duplicate of the email spool to a file server
> at regular intervals, which eventually makes its way to tape. Although
> we don't have regulatory requirements I've had to do a few recoveries
> and have done so without problem.
>
> in our case we have cyr_expire set to 3 days (I believe the default
> config), which provides more than enough time to in case a backup
> fails for some reason or another.
>
>
>> For example:
>> http://www.mailpiler.org (Fully Free Software)
>> https://www.mailarchiva.com (the old version is opensource but the
>>  latest is closed)
>>
>> The specific software will be much better for searching the archive.
>>  Finding something in the delayed_expunge folders after many years of
>>  archive will absolutely be a nightmare!
>>
>
>
> Of course these tools offer features but that all comes at a price.
>
>
>>
>
>
>> Giuseppe
>>
>>
>>  On 08/26/2016 03:09 PM, Alvin Starr via Info-cyrus wrote:
>>
>>> A company I am working with is facing issues of regulatorymail
>>> retention.
>>>
>>>  Some searching has yielded little useful results other than
>>>  putting a
>>>  system in front to store all incoming messages.
>>>
>>>  What are others doing for mail archival?
>>>
>>>  An ideal solution would let the users carry on using current use
>>>  patterns and not impose extra restrictions.
>>>
>>>  --
>>>  Alvin Starr   ||   voice: (905)513-7688
>>>  Netvel Inc.   ||   Cell:  (416)806-0133
>>> al...@netvel.net ||
>>>
>>>
>>>
>>>  
>>>  Cyrus Home Page: http://www.cyrusimap.org/
>>>  List Archives/Info:
>>>  http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>>>  To Unsubscribe:
>>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>>>
>> 
>>  Cyrus Home Page: http://www.cyrusimap.org/
>>  List Archives/Info:
>>  http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>>  To Unsubscribe:
>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>
> 
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

--
  Bron Gondwana
  br...@fastmail.fm

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Adam Tauno Williams via Info-cyrus]

On Fri, 2016-08-26 at 12:11 -0500, Jason L Tibbitts III via Info-cyrus
wrote:
> > > > > > "GR(" == Giuseppe Ravasio (LU) via Info-cyrus <
> > > > > > info-cyrus@lists.andrew.cmu.edu> writes:
> GR(> I saw that someone proposed to make a sort of abuse of delayed
> GR(> expunge, but I think that in order to comply with regulatory
> GR(> retention should be better considering some specific software.
> True, but it seems odd (to me, in a situation where I don't have
> infinite money) to have basically two mail servers: one which
> actually
> removes things when the user deletes stuff and one which doesn't.

But that is essentially archival - on-the-same-system is not archival. 
 It is also, potentially, still available to be easily changed;  which
is not good when the intent is retention.

> I guess they can be optimized for different things, but it still 
> seems odd when we already have a server that can store as much mail 
> as you want, provides a means to access and search it with ACLs for 
> auditors and such, and of course is already installed and running.

Do you want to give auditors access to your production systems?  
Generally I want to give them the qualifying information and have them
go away.

> If it were possible to hook the message deletion functions in cyrus 
> to move things to a different place in the hierarchy and then control
> expiry on those differently than the regular folders, it would 
> probably be sufficient.  But that requires code and I don't have the 
> skills to write it.

What you are talking about is "tiered storage".  That has been talked
about in the past - I don't know if anyone has implemented it.

> Certainly not super featureful but frankly
> when the lawyers want something, I just dump mail files on them and 
> let them sort it out.

Exactly!  So perhaps just dump them out of the system in the first
place.


-- 
Adam Tauno Williams  GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA



Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Adam Tauno Williams via Info-cyrus]

On Fri, 2016-08-26 at 16:13 +, Shawn Bakhtiar via Info-cyrus wrote:
> > On Aug 26, 2016, at 8:35 AM, Giuseppe Ravasio (LU) via Info-cyrus <
> > info-cyrus@lists.andrew.cmu.edu> wrote:
> > I saw that someone proposed to make a sort of abuse of delayed
> > expunge,
> > but I think that in order to comply with regulatory retention 
> > should be better considering some specific software.
> I don't see how using delayed expunge would really be consider abuse,
> the documentation makes mention of its use for this very reason.

+1


> We use rsync to make a duplicate of the email spool to a file server
> at regular intervals, which eventually makes its way to tape.


Same here.  And always_bcc to a shared folder which is dumped to an
MBOX file via fetchmail at an interval.  Those can be archived or even
shipped off-site.

> Although we don't have regulatory requirements I've had to do a few
> recoveries and have done so without problem. 

I always advise people to be hesitant about "we don't have regulatory
requirements" as if you are a legal corporation of any kind, in almost
all of the 50 states [United States], you are under data retention
rules - even if you don't know it.  Which you will discover when you
are involved in a law suit - saying "uhh... yeah, we don't have those e
-mails" will not be good.

> > Finding something in the delayed_expunge folders after many years
> > of archive will absolutely be a nightmare!

Most states [again the United States] allow a corporation to have on
file a documented data retention policy that states how long you retain
e-mails;  which if you comply with you will be OK.  The policy just
needs to be 'reasonable'.  For example: where I work we say 120 days. 
 No need - at least for legal reasons - to have years of archives.

Obviously requirements vary by industry - but almost everyone is
actually under some kind of requirement.

-- 
Adam Tauno Williams  GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA



Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Alvin Starr via Info-cyrus]

If Strict compliance and regulatory requirements were the issue I would 
agree that a completely separate subsystem would be appropriate.


This is more for a company that is on the periphery of compliance issues.

There will be no compliance officers or strict validation against 
regulatory requirements.


The overall I.T. budget for the company would never be able to cover the 
cost of strict compliance.



On 08/26/2016 12:41 PM, Patrick Goetz via Info-cyrus wrote:

On 08/26/2016 08:09 AM, Alvin Starr via Info-cyrus wrote:

What are others doing for mail archival?



If you need to retain all email for regulatory reasons, I would run 
the mail through something like a procmail filter, sending one copy to 
the user and another to an Archival spool, which could even be an 
entirely separate smtp server.




Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Jason L Tibbitts III via Info-cyrus]

> "GR(" == Giuseppe Ravasio (LU) via Info-cyrus 
>  writes:

GR(> I saw that someone proposed to make a sort of abuse of delayed
GR(> expunge, but I think that in order to comply with regulatory
GR(> retention should be better considering some specific software.

True, but it seems odd (to me, in a situation where I don't have
infinite money) to have basically two mail servers: one which actually
removes things when the user deletes stuff and one which doesn't.

I guess they can be optimized for different things, but it still seems
odd when we already have a server that can store as much mail as you
want, provides a means to access and search it with ACLs for auditors
and such, and of course is already installed and running.

If it were possible to hook the message deletion functions in cyrus to
move things to a different place in the hierarchy and then control
expiry on those differently than the regular folders, it would probably
be sufficient.  But that requires code and I don't have the skills to
write it.

Alternately, it _could_, instead of removing the message files at
deletion time, just move them somewhere.  Then you could script what you
want to do with them.  Certainly not super featureful but frankly when
the lawyers want something, I just dump mail files on them and let them
sort it out.

 - J<

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Shawn Bakhtiar via Info-cyrus]

On Aug 26, 2016, at 8:35 AM, Giuseppe Ravasio (LU) via Info-cyrus 
> wrote:

I saw that someone proposed to make a sort of abuse of delayed expunge,
but I think that in order to comply with regulatory retention should be
better considering some specific software.


I don't see how using delayed expunge would really be consider abuse, the 
documentation makes mention of its use for this very reason.

"In any case, the time between a message arriving and being deleted may not be 
sufficient to ensure the message is replicated, included in the next backup 
cycle, and generally available for recovery or compliance with the regulatory 
environment."
--src https://cyrusimap.org/imap/features/delayed-expunge.html

We use rsync to make a duplicate of the email spool to a file server at regular 
intervals, which eventually makes its way to tape. Although we don't have 
regulatory requirements I've had to do a few recoveries and have done so 
without problem.

in our case we have cyr_expire set to 3 days (I believe the default config), 
which provides more than enough time to in case a backup fails for some reason 
or another.


For example:
http://www.mailpiler.org (Fully Free Software)
https://www.mailarchiva.com (the old version is opensource but the
latest is closed)

The specific software will be much better for searching the archive.
Finding something in the delayed_expunge folders after many years of
archive will absolutely be a nightmare!



Of course these tools offer features but that all comes at a price.




Giuseppe


On 08/26/2016 03:09 PM, Alvin Starr via Info-cyrus wrote:
A company I am working with is facing issues of regulatorymail retention.

Some searching has yielded little useful results other than putting a
system in front to store all incoming messages.

What are others doing for mail archival?

An ideal solution would let the users carry on using current use
patterns and not impose extra restrictions.

--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||




Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Patrick Goetz via Info-cyrus]

On 08/26/2016 08:09 AM, Alvin Starr via Info-cyrus wrote:

What are others doing for mail archival?



If you need to retain all email for regulatory reasons, I would run the 
mail through something like a procmail filter, sending one copy to the 
user and another to an Archival spool, which could even be an entirely 
separate smtp server.




Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Giuseppe Ravasio (LU) via Info-cyrus]

I saw that someone proposed to make a sort of abuse of delayed expunge,
but I think that in order to comply with regulatory retention should be
better considering some specific software.

For example:
http://www.mailpiler.org (Fully Free Software)
https://www.mailarchiva.com (the old version is opensource but the
latest is closed)

The specific software will be much better for searching the archive.
Finding something in the delayed_expunge folders after many years of
archive will absolutely be a nightmare!

Giuseppe


On 08/26/2016 03:09 PM, Alvin Starr via Info-cyrus wrote:
> A company I am working with is facing issues of regulatorymail retention.
> 
> Some searching has yielded little useful results other than putting a
> system in front to store all incoming messages.
> 
> What are others doing for mail archival?
> 
> An ideal solution would let the users carry on using current use
> patterns and not impose extra restrictions.
> 
> -- 
> Alvin Starr   ||   voice: (905)513-7688
> Netvel Inc.   ||   Cell:  (416)806-0133
> al...@netvel.net  ||
> 
> 
> 
> 
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
> 

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Alvin Starr via Info-cyrus]

On 08/26/2016 10:25 AM, Adam Tauno Williams via Info-cyrus wrote:

On Fri, 2016-08-26 at 10:07 -0400, Alvin Starr via Info-cyrus wrote:

Well the MTA still does not deal with archival because it will need
to be passed through to Yet Another MDA to handle the archival and
management process.

I'm not sure what you mean.  You can archive to a 'shared' folder or
into an MBOX to be processed by something which rotates content.
Trapping all the email in postfix and using a bcc would either push the 
bcc'd email to another mail handler of back into cyrus in some other 
mailbox.

Which is doable but just seems clunky.



For the pure archival of the input/output stream including duplicate
deliveries and all spam always_bcc into YAMDA would work.

always_bcc and delayed expunge work for us.
This could be the answer. I tried using always_bcc for another use and 
found that it had some quirks with cyrus so I have avoided it since then 
but it may be worth a revisit.



In my thinking Cyrus is responsible for the storage and management of
email so archival would be a part of that process.

It has to be the MTAs responsibility as Cyrus very possibly does not
see *sent* mail; or messages which are somehow otherwise routed.


True enough but an always_bcc into the Sent folder would solve that problem.

--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Alvin Starr via Info-cyrus]

I was wondering about the idea of using delayed_expunge.

I was also thinking about the expunge process moving the message out to 
some other place but that would be a change to the expunge code.



On 08/26/2016 10:19 AM, Andrew Morgan wrote:
Could your retention needs be satisfied with Cyrus' delayed_delete and 
delayed_expunge functionality?


Thanks,
Andy

On Fri, 26 Aug 2016, Alvin Starr via Info-cyrus wrote:

Well the MTA still does not deal with archival because it will need 
to be passed through to Yet Another MDA to handle the archival and 
management process.


For the pure archival of the input/output stream including duplicate 
deliveries and all spam always_bcc into YAMDA would work.


In my thinking Cyrus is responsible for the storage and management of 
email so archival would be a part of that process.




On 08/26/2016 09:17 AM, Nic Bernstein wrote:

Alvin,
This is really more of an issue for your MTA, such as Postfix or 
Exim.  The MDA -- Cyrus in this case -- has little or nothing to do 
with the sort of archiving/retention you need for compliance. Take a 
look at always_bcc and similar directives in Postfix, or the 
equivalent in whatever your MTA is.

-nic

On 08/26/2016 08:09 AM, Alvin Starr via Info-cyrus wrote:
A company I am working with is facing issues of regulatorymail 
retention.


Some searching has yielded little useful results other than putting 
a system in front to store all incoming messages.


What are others doing for mail archival?

An ideal solution would let the users carry on using current use 
patterns and not impose extra restrictions.


--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net   ||



Cyrus Home Page:http://www.cyrusimap.org/
List Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


--
Nic bernstein...@onlight.com
Onlight Inc.www.onlight.com
6525 W Bluemound Rd., Ste 24  v. 414.272.4477
Milwaukee, Wisconsin  53213-4073  f. 414.290.0335


--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||




--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Michael D. Sofka via Info-cyrus]

On 08/26/2016 10:25 AM, Adam Tauno Williams via Info-cyrus wrote:



In my thinking Cyrus is responsible for the storage and management of
email so archival would be a part of that process.


It has to be the MTAs responsibility as Cyrus very possibly does not
see *sent* mail; or messages which are somehow otherwise routed.



But most clients place a copy in a Sent folder.

--
Michael D. Sofka   sof...@rpi.edu
C Sr. Systems Programmer,   Email, TeX, Epistemology
Rensselaer Polytechnic Institute, Troy, NY.  http://www.rpi.edu/~sofkam/

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Adam Tauno Williams via Info-cyrus]

On Fri, 2016-08-26 at 10:07 -0400, Alvin Starr via Info-cyrus wrote:
> Well the MTA still does not deal with archival because it will need
> to be passed through to Yet Another MDA to handle the archival and
> management process.

I'm not sure what you mean.  You can archive to a 'shared' folder or
into an MBOX to be processed by something which rotates content.

> For the pure archival of the input/output stream including duplicate
> deliveries and all spam always_bcc into YAMDA would work.

always_bcc and delayed expunge work for us.

> In my thinking Cyrus is responsible for the storage and management of
> email so archival would be a part of that process.

It has to be the MTAs responsibility as Cyrus very possibly does not
see *sent* mail; or messages which are somehow otherwise routed.

-- 
Adam Tauno Williams  GPG D95ED383
OpenGroupware Developer 



Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Andrew Morgan via Info-cyrus]

Could your retention needs be satisfied with Cyrus' delayed_delete and 
delayed_expunge functionality?


Thanks,
Andy

On Fri, 26 Aug 2016, Alvin Starr via Info-cyrus wrote:

Well the MTA still does not deal with archival because it will need to be 
passed through to Yet Another MDA to handle the archival and management 
process.


For the pure archival of the input/output stream including duplicate 
deliveries and all spam always_bcc into YAMDA would work.


In my thinking Cyrus is responsible for the storage and management of email 
so archival would be a part of that process.




On 08/26/2016 09:17 AM, Nic Bernstein wrote:

Alvin,
This is really more of an issue for your MTA, such as Postfix or Exim.  The 
MDA -- Cyrus in this case -- has little or nothing to do with the sort of 
archiving/retention you need for compliance. Take a look at always_bcc and 
similar directives in Postfix, or the equivalent in whatever your MTA is.

-nic

On 08/26/2016 08:09 AM, Alvin Starr via Info-cyrus wrote:

A company I am working with is facing issues of regulatorymail retention.

Some searching has yielded little useful results other than putting a 
system in front to store all incoming messages.


What are others doing for mail archival?

An ideal solution would let the users carry on using current use patterns 
and not impose extra restrictions.


--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net   ||



Cyrus Home Page:http://www.cyrusimap.org/
List Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


--
Nic bernstein...@onlight.com
Onlight Inc.www.onlight.com
6525 W Bluemound Rd., Ste 24  v. 414.272.4477
Milwaukee, Wisconsin  53213-4073  f. 414.290.0335


--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||




Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Michael D. Sofka via Info-cyrus]

On 08/26/2016 09:09 AM, Alvin Starr via Info-cyrus wrote:

A company I am working with is facing issues of regulatorymail retention.

Some searching has yielded little useful results other than putting a
system in front to store all incoming messages.

What are others doing for mail archival?

An ideal solution would let the users carry on using current use
patterns and not impose extra restrictions.



One possible solution in Cyrus, is to have expunge_mode on delayed, and 
then set the /vendor/cmu/cyrus-imapd/expire to something very large. 
Or, to place the expire notation deeper in the tree, so it can be 
removed from individual mailboxes.  This is a little clunky, and  it 
would be nice if 'Administrative Hold' were a mailbox setting in Cyrus.


Mike
--
Michael D. Sofka   sof...@rpi.edu
C Sr. Systems Programmer,   Email, TeX, Epistemology
Rensselaer Polytechnic Institute, Troy, NY.  http://www.rpi.edu/~sofkam/

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Alvin Starr via Info-cyrus]

Well the MTA still does not deal with archival because it will need to 
be passed through to Yet Another MDA to handle the archival and 
management process.


For the pure archival of the input/output stream including duplicate 
deliveries and all spam always_bcc into YAMDA would work.


In my thinking Cyrus is responsible for the storage and management of 
email so archival would be a part of that process.




On 08/26/2016 09:17 AM, Nic Bernstein wrote:

Alvin,
This is really more of an issue for your MTA, such as Postfix or 
Exim.  The MDA -- Cyrus in this case -- has little or nothing to do 
with the sort of archiving/retention you need for compliance. Take a 
look at always_bcc and similar directives in Postfix, or the 
equivalent in whatever your MTA is.

-nic

On 08/26/2016 08:09 AM, Alvin Starr via Info-cyrus wrote:

A company I am working with is facing issues of regulatorymail retention.

Some searching has yielded little useful results other than putting a 
system in front to store all incoming messages.


What are others doing for mail archival?

An ideal solution would let the users carry on using current use 
patterns and not impose extra restrictions.


--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net   ||



Cyrus Home Page:http://www.cyrusimap.org/
List Archives/Info:http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


--
Nic bernstein...@onlight.com
Onlight Inc.www.onlight.com
6525 W Bluemound Rd., Ste 24  v. 414.272.4477
Milwaukee, Wisconsin  53213-4073  f. 414.290.0335


--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Re: how to deal with mail retention/archival.

[Nic Bernstein via Info-cyrus]

Alvin,
This is really more of an issue for your MTA, such as Postfix or Exim.  
The MDA -- Cyrus in this case -- has little or nothing to do with the 
sort of archiving/retention you need for compliance.  Take a look at 
always_bcc and similar directives in Postfix, or the equivalent in 
whatever your MTA is.

-nic

On 08/26/2016 08:09 AM, Alvin Starr via Info-cyrus wrote:

A company I am working with is facing issues of regulatorymail retention.

Some searching has yielded little useful results other than putting a 
system in front to store all incoming messages.


What are others doing for mail archival?

An ideal solution would let the users carry on using current use 
patterns and not impose extra restrictions.


--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net   ||



Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


--
Nic Bernstein n...@onlight.com
Onlight Inc.  www.onlight.com
6525 W Bluemound Rd., Ste 24  v. 414.272.4477
Milwaukee, Wisconsin  53213-4073  f. 414.290.0335


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

how to deal with mail retention/archival.

[Alvin Starr via Info-cyrus]

A company I am working with is facing issues of regulatorymail retention.

Some searching has yielded little useful results other than putting a 
system in front to store all incoming messages.


What are others doing for mail archival?

An ideal solution would let the users carry on using current use 
patterns and not impose extra restrictions.


--
Alvin Starr   ||   voice: (905)513-7688
Netvel Inc.   ||   Cell:  (416)806-0133
al...@netvel.net  ||


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus