Re: Configuring supported extensions
Damian <[email protected]> Mon, 2 Sep 2024 18:40:41 +0200
| Newsgroups | gmane.mail.virus.amavis.user |
|---|---|
| Message-ID | <[email protected]> |
> 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.