Restricted Mode

Beginning with version 0.3, in addition to the classic normal mode ('NM'), Mailmin can operate in restricted mode ('RM'), in which only a severely limited subset of Mailmin functionality is available. Mailmin enters RM in the following two cases:

See the key setup page and the sample configuration file for more information. If the message is signed by an authorized key, then Mailmin operates in NM, as usual.


These restrictions are in effect in RM:

The @wattach directive

Unlike in NM, where the entire remaining line following a @wattach directive is appended to the system invocation of wget, in RM the line's individual 'words' (as parsed by Perl's Text::ParseWords &parse_line function) are individually fed to wget (invoked with its '-i' option) on its standard input. There are two reasons for this:

Note also that Mailmin will prepend "http://" to any URL that doesn't seem to already have a protocol prefix, i.e any URL that doesn't match the regex m![a-z]+://!i. This occurs before URL filtering.

URL filtering

When in RM (enabling filtering in NM would be pointless), if the rm_filter_file configuration file option is set to a file, then URL filtering will be done. Basically, whitelisting and blacklisting can be implemented using the power of regular expressions. More precisely, each URL will be sequentially checked against each line in the file, which is assumed to be a Perl regular expression optionally preceded by some whitespace and a '-', which are not included in the regex. Blank lines and lines whose first non-whitespace character is a '#' (comments) are ignored. Checking stops at the first match; if the line began with a '-', the URL is blocked; it is otherwise accepted. URLs that do not match any line are blocked; this default can of course be reversed by concluding the filter file with a line containing something like a single '.' .


The above restrictions notwithstanding, enabling anonymous access is probably insecure; use with caution, and please report all bugs, especially security vulnerabilities!

Denial of Service

Allowing untrusted users access, even to RM, creates the potential for DoS attacks; I am considering various defenses against them. Ideas and suggestions are most welcome!