Configuring supported extensions

Damian amavis at arcsin.de
Mon Sep 2 18:40:41 CEST 2024


> 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/20240902/a9ab964f/attachment.htm>


More information about the amavis-users mailing list