Configuring supported extensions

[Tyler Montney]

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.

Thanks for the assistance.


On Thu, Sep 5, 2024 at 12:22 AM Tyler Montney <montneytyler at gmail.com>
wrote:

> 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.
>
> Does this indicate amavisd won't be able to scan archives?
>
> On Mon, Sep 2, 2024 at 11:49 AM Damian <amavis at arcsin.de> wrote:
>
>> 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?
>>
>> At startup, Amavis will log something like this:
>>
>> Found decoder for    .Z    at /usr/bin/uncompress
>> Found decoder for    .gz   at /usr/bin/gzip -d
>> Internal decoder for .gz   (backup, not used)
>> Found decoder for    .bz2  at /usr/bin/bzip2 -d
>> Found decoder for    .xz   at /usr/bin/xz -dc
>> Found decoder for    .lzma at /usr/bin/xz -dc --format=lzma
>> ...
>>
>>
>>    - How do I know which extensions are supported?
>>
>> 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.
>>
>> 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.amavis.org/pipermail/amavis-users/attachments/20240905/f1ec7212/attachment.htm>