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