<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><tt>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.</tt></p>
    <p><tt>For the pure archival of the input/output stream including
        duplicate deliveries and all spam always_bcc into YAMDA would
        work.</tt></p>
    <p><tt>In my thinking Cyrus is responsible for the storage and
        management of email so archival would be a part of that process.<br>
      </tt></p>
    <p><tt></tt><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 08/26/2016 09:17 AM, Nic Bernstein
      wrote:<br>
    </div>
    <blockquote cite="mid:57C0417D.4030706@onlight.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      Alvin,<br>
      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.<br>
          -nic<br>
      <br>
      <div class="moz-cite-prefix">On 08/26/2016 08:09 AM, Alvin Starr
        via Info-cyrus wrote:<br>
      </div>
      <blockquote
        cite="mid:598cd973-fb93-829b-92e0-3f59c1821a26@netvel.net"
        type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=windows-1252">
        <tt>A company I am worki</tt><tt>ng with is facing issues of </tt><tt>regulatory</tt><tt>
          m</tt><tt>ail </tt><tt>retention</tt><tt>.</tt><tt><br>
          <br>
          Some searching has yielded little useful results other than
          putting a system in front to store all incoming messages.<br>
          <br>
        </tt><tt>What are others doing for mail archival?<br>
        </tt><tt><br>
          An ideal solution would let the users carry on using current
          use patterns and not impose extra restrictions.<br>
          <br>
        </tt>
        <pre class="moz-signature" cols="72">-- 
Alvin Starr                   ||   voice: (905)513-7688
Netvel Inc.                   ||   Cell:  (416)806-0133
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:alvin@netvel.net">alvin@netvel.net</a>              ||
</pre>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">----
Cyrus Home Page: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.cyrusimap.org/">http://www.cyrusimap.org/</a>
List Archives/Info: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a>
To Unsubscribe:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a></pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">-- 
Nic Bernstein                             <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:nic@onlight.com">nic@onlight.com</a>
Onlight Inc.                              <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.onlight.com">www.onlight.com</a>
6525 W Bluemound Rd., Ste 24              v. 414.272.4477
Milwaukee, Wisconsin  53213-4073          f. 414.290.0335
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Alvin Starr                   ||   voice: (905)513-7688
Netvel Inc.                   ||   Cell:  (416)806-0133
<a class="moz-txt-link-abbreviated" href="mailto:alvin@netvel.net">alvin@netvel.net</a>              ||
</pre>
  </body>
</html>