<div dir="ltr"><div>Noticed one of my conf files had $LOGFILE overridden to the service user's home directory. That log file shows it found nearly all the decoders.</div><div><br></div><div>Thanks for the assistance.<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2024 at 12:22 AM Tyler Montney <<a href="mailto:montneytyler@gmail.com">montneytyler@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'm not seeing any entries, "Found decoder for...", like you mentioned. (Fedora 40, amavisd-2.13.1: maillog and messages.) Tested a few external programs from @decoders, like gzip, and they're definitely on $PATH. Changing the log level made no difference.<br></div><div><br></div><div>Does this indicate amavisd won't be able to scan archives?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 2, 2024 at 11:49 AM Damian <<a href="mailto:amavis@arcsin.de" target="_blank">amavis@arcsin.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <blockquote type="cite">
      <pre>For example, say .rar isn't supported natively. I've seen tutorials suggest
installing related packages, but don't see how Amavis picks up on that.
>From the amavsid.conf, I see a "@decoders" which seems like a map
(extension, command, arguments). This appears to map to
/lib/Amavis/Unpackers.pm.

   - What's the process for ensuring certain extensions get scanned?</pre>
    </blockquote>
    <p>At startup, Amavis will log something like this:</p>
    <p>
      </p><blockquote type="cite">Found decoder for    .Z    at
        /usr/bin/uncompress<br>
        Found decoder for    .gz   at /usr/bin/gzip -d<br>
        Internal decoder for .gz   (backup, not used)<br>
        Found decoder for    .bz2  at /usr/bin/bzip2 -d<br>
        Found decoder for    .xz   at /usr/bin/xz -dc<br>
        Found decoder for    .lzma at /usr/bin/xz -dc --format=lzma<br>
        ...<br>
      </blockquote>
      <br>
    <p></p>
    <blockquote type="cite">
      <pre>   - How do I know which extensions are supported?</pre>
    </blockquote>
    <span style="white-space:pre-wrap">
</span>
    <pre><span style="white-space:normal">The second "column" of @decoders, which you referred to as command, specifies Perl subroutines that know how to call external programs and how to interpret their output.
The third column is a search list of external programs that can handle the extensions in the first column. </span></pre>
    <p></p>
    <p>So if an external unpacker like 7z started to support a new
      archive extension without changing its CLI for unpacking, one
      should be able to add this new extension to the first column of
      the appropriate @decoders row. However, if there were a new
      unpacker that has a new type of CLI, someone would have to write
      an unpackers routine and reference it in the second column.<br>
    </p>
  </div>

</blockquote></div>
</blockquote></div>