Merge remote-tracking branch 'upstream/master'

* upstream/master: (110 commits)
  [Fix] Fix detection of URLs in text parts
  [Fix] Strip '\r\n' properly
  [Fix] More fixes about shared memory in proxy
  [Fix] One more try to fix redis
  [Feature] Use one pass to remove newlines and store their positions
  [Fix] Fix descriptors leak on shmem detaching
  [Fix] More and more fixes to redis states
  [Fix] Another try to fix redis states
  [Fix] Set terminated state before calling of async free
  [Fix] Fix state on timeout
  [Fix] Another try to fix redis mess
  [Fix] Fix redis timeout events handling
  [Minor] Add some more tests
  [Feature] Try to read on fuzzy timeout to avoid fake timeouts
  [Feature] Add ESMTPSA received type
  [Fix] Fix stack growing
  [Feature] Further relax parser
  [Fix] Fix parsing of nested braces in SMTP comments
  [Minor] Add `application/octet-stream` mime type for `pdf` extension
  [Fix] Fix parser
  ...

5 files changed, 83 insertions, 169 deletions

diff --git a/doc/markdown/architecture/index.md b/doc/markdown/architecture/index.md
index 45e52fa8e..f93ce9818 100644
--- a/doc/markdown/architecture/index.md
+++ b/doc/markdown/architecture/index.md
@@ -1,28 +1,20 @@
-# Rspamd architecture
+# rspamd architecture
 
 ## Introduction
 
-Rspamd is a universal spam filtering system based on event-driven processing
-model. It means that rspamd is intended not to block anywhere in the code. To
-process messages rspamd uses a set of so called `rules`. Each `rule` is a symbolic
-name associated with some message property. For example, we can define the following
-rules:
+rspamd is a universal spam filtering system based on an event-driven processing model, which means that rspamd is not intended to block anywhere in the code. To process messages rspamd uses a set of `rules`. Each `rule` is a symbolic name associated with a message property. For example, we can define the following rules:
 
 - `SPF_ALLOW` - means that a message is validated by SPF;
 - `BAYES_SPAM` - means that a message is statistically considered as spam;
-- `FORGED_OUTLOOK_MID` - message ID seems to be forged for Outlook MUA.
+- `FORGED_OUTLOOK_MID` - message ID seems to be forged for the Outlook MUA.
 
-Rules are defined by [modules](../modules/). So far, if there is a module that
-performs SPF checks it may define several rules according to SPF policy:
+Rules are defined by [modules](../modules/). If there is a module, for example, that performs SPF checks it may define several rules according to SPF policy:
 
 - `SPF_ALLOW` - a sender is allowed to send messages for this domain;
 - `SPF_DENY` - a sender is denied by SPF policy;
 - `SPF_SOFTFAIL` - there is no affinity defined by SPF policy.
 
-Rspamd supports two main types of modules: internal written in C and external
-written in Lua. There is no real difference between these two types with the exception
-that C modules are embeded all the time and can be enabled in `filters` attribute
-in the `options` section of the config:
+rspamd supports two main types of modules: internal modules written in C and external modules written in lua. There is no real difference between the two types with the exception that C modules are embedded and can be enabled in a `filters` attribute in the `options` section of the config:
 
 ~~~ucl
 options {
@@ -33,29 +25,21 @@ options {
 
 ## Protocol
 
-Rspamd uses HTTP protocol for all operations. This protocol is described in the [protocol section](protocol.md).
+rspamd uses the HTTP protocol for all operations. This protocol is described in the [protocol section](protocol.md).
 
 ## Metrics
 
-Rules in rspamd, defines merely a logic of checks, however it is required to
-set up weights for each rule. Weight means `significance` in terms of rspamd. So
-far, rules with greater absolute value of weight are considered as more important
-than the recent rules. The weight of rules is defined in `metrics`. Each metric
-is a set of grouped rules with specific weights. For example, we may define the
-following weights for our SPF rules:
+Rules in rspamd define a logic of checks, but it is required to set up weights for each rule. (For rspamd, weight means `significance`.) Rules with a greater absolute value of weight are considered more important. The weight of rules is defined in `metrics`. Each metric is a set of grouped rules with specific weights. For example, we may define the following weights for our SPF rules:
 
 - `SPF_ALLOW`: -1
 - `SPF_DENY`: 2
 - `SPF_SOFTFAIL`: 0.5
 
-Positive weights means that this rule turns message to more spammy, while negative
-means the opposite.
+Positive weights mean that this rule increases a messages 'spammyness', while negative weights mean the opposite.
 
 ### Rules scheduler
 
-To avoid unnecessary checks rspamd uses scheduler of rules for each message. So far,
-if a message is considered as `definite spam` then further checks are not performed.
-This scheduler is rather naive and it performs the following logic:
+To avoid unnecessary checks rspamd uses a scheduler of rules for each message. If a message is considered as definite spam then further checks are not performed. This scheduler is rather naive and it performs the following logic:
 
 - select negative rules *before* positive ones to prevent false positives;
 - prefer rules with the following characteristics:
@@ -65,77 +49,39 @@ This scheduler is rather naive and it performs the following logic:
 
 These optimizations can filter definite spam more quickly than a generic queue.
 
-Since rspamd-0.9 there are more optimizations for rules and expressions that are
-roughly described in the [following presentation](http://highsecure.ru/ast-rspamd.pdf).
+Since rspamd-0.9 there are further optimizations for rules and expressions that are described generally in the [following presentation](http://highsecure.ru/ast-rspamd.pdf).
 
 ## Actions
 
-Another important property of metrics is their actions set. This set defines recommended
-actions for a message if it reach a certain score defined by all rules triggered.
-Rspamd defines the following actions:
+Another important property of metrics is their actions set. This set defines recommended actions for a message if it reaches a certain score defined by all rules which have been triggered. rspamd defines the following actions:
 
-- `No action`: a message is likely ham;
-- `Greylist`: greylist message is it is not certainly ham;
+- `No action`: a message is likely to be ham;
+- `Greylist`: greylist a message if it is not certainly ham;
 - `Add header`: a message is likely spam, so add a specific header;
 - `Rewrite subject`: a message is likely spam, so rewrite its subject;
 - `Reject`: a message is very likely spam, so reject it completely
 
-These actions are just recommendations for MTA and are not to be strictly followed.
-For all actions that are greater or equal than `greylist` it is recommended to
-perform explicit greylisting. `Add header` and `rewrite subject` actions are very
-close in semantics and are both considered as `probable spam`. `Reject` is a
-strong rule that usually means that a message should be really rejected by MTA.
-The triggering score for these actions should be specified according to their logic
-priorities. If two actions have the same weight, the result is unspecified.
+These actions are just recommendations for the MTA and are not to be strictly followed. For all actions that are greater or equal than `greylist` it is recommended to perform explicit greylisting. `Add header` and `rewrite subject` actions are very close in semantics and are both considered as probable spam. `Reject` is a strong rule which usually means that a message should be really rejected by the MTA. The triggering score for these actions should be specified according to their logic priorities. If two actions have the same weight, the result is unspecified.
 
 ## Rules weight
 
-The weights of rules is not necessarily constant. For example, for statistics rules
-we have no certain confidence if a message is spam or not. We have some probability
-instead. To allow fuzzy rules weight, rspamd supports `dynamic weights`. Generally,
-it means that a rule may add a dynamic range from 0 to a defined weight in the metric.
-So far if we define symbol `BAYES_SPAM` with weight 5.0, then this rule can add
-a resulting symbol with weight from 0 to 5.0. To distribute values in the proper
-way, rspamd usually uses some sort of Sigma function to provide fair distribution curve.
-Nevertheless, the most of rspamd rules uses static weights with the exception of
-fuzzy rules.
-
-## Statistic
-
-Rspamd uses statistic algorithms to precise the final score of a message. Currently,
-the only algorithm defined is OSB-Bayes. You may find the concrete details of this
-algorithm in the following [paper](http://osbf-lua.luaforge.net/papers/osbf-eddc.pdf).
-Rspamd uses window size of 5 words in its classification. During classification procedure,
-rspamd split a message to a set of tokens.
-
-Tokens are separated by punctiation or space characters. Short tokens (less than 3 symbols) are ignored. For each token rspamd
-calculates two non-cryptographic hashes used subsequently as indices. All these tokens
-are stored in memory-mapped files called `statistic files` (or `statfiles`). Each statfile
-is a set of token chains, indexed by the first hash. A new token may be inserted to some
-chain, and if this chain is full then rspamd tries to expire less significant tokens to
-insert a new one. It is possible to obtain the current state of tokens by running
-
-	rspamc stat
-
-command that asks controller for free and used tokens in each statfile.
-Please note that if a statfile is close to be completely filled then during subsequent
-learning you will loose existing data. Therefore, it is recommended to increase size for
-such statfiles.
+The weight of rules is not necessarily constant. For example, for statistics rules we have no certain confidence if a message is spam or not; instead we have a measure of probability. To allow fuzzy rules weight, rspamd supports `dynamic weights`. Generally, it means that a rule may add a dynamic range from 0 to a defined weight in the metric. So if we define the symbol `BAYES_SPAM` with a weight of 5.0, then this rule can add a resulting symbol with a weight from 0 to 5.0. To distribute values, rspamd uses a form of Sigma function to provide a fair distribution curve. The majority of rspamd rules, with the exception of fuzzy rules, use static weights.
 
-## Running rspamd
+## Statistics
 
-There are several command-line options that can be passed to rspamd. All of them can be displayed by passing `--help` argument:
+rspamd uses statistic algorithms to precisely calculate the final score of a message. Currently, the only algorithm defined is OSB-Bayes. You can find details of this algorithm in the following [paper](http://osbf-lua.luaforge.net/papers/osbf-eddc.pdf). rspamd uses a window size of 5 words in its classification. During the classification procedure, rspamd splits a message into a set of tokens. Tokens are separated by punctuation or whitespace characters. Short tokens (less than 3 symbols) are ignored. For each token, rspamd calculates two non-cryptographic hashes used subsequently as indices. All these tokens are stored in different statistics backends (mmapped files, sqlite3 database or redis server). Currently, the recommended backend for statistics is `redis`.
 
-All options are optional: by default rspamd would try to read `etc/rspamd.conf` config file and run as daemon. Also there is test mode that can be turned on by passing `-t` argument. In test mode, rspamd reads config file and checks its syntax. If a configuration file is OK, then exit code is zero. Test mode is useful for testing new config file withou rspamd restart. `--convert-config` option can be used to convert old style (pre 0.6.0) config to [ucl](../configuration/ucl.md) one:
+## Running rspamd
 
-	$ rspamd -c ./rspamd.xml --convert-conf ./rspamd.conf
+There are several command-line options that can be passed to rspamd. All of them can be displayed by passing the `--help` argument.
 
+All options are optional: by default rspamd will try to read the `etc/rspamd.conf` config file and run as a daemon. Also there is a test mode that can be turned on by passing the `-t` argument. In test mode, rspamd reads the config file and checks its syntax. If a configuration file is OK, the exit code is zero. Test mode is useful for testing new config files without restarting rspamd.
 
 ## Managing rspamd using signals
 
-First of all, it is important to note that all user's signals should be sent to rspamd main process and not to its children (as for child processes these signals can have other meanings). To determine which process is main you can use two ways:
+It is important to note that all user signals should be sent to the rspamd main process and not to its children (as for child processes these signals can have other meanings). You can identify the main process:
 
-- by reading pidfile:
+- by reading the pidfile:
 
 		$ cat pidfile
 
@@ -151,10 +97,10 @@ First of all, it is important to note that all user's signals should be sent to
 		$ ps auxwww | grep rspamd | grep main
 		nobody 28378  0.0  0.2 49744  9424   rspamd: main process
 
-After getting the pid of main process it is possible to manage rspamd with signals:
+After getting the pid of the main process it is possible to manage rspamd with signals, as follows:
 
-- `SIGHUP` - restart rspamd: reread config file, start new workers (as well as controller and other processes), stop accepting connections by old workers, reopen all log files. Note that old workers would be terminated after one minute that should allow to process all pending requests. All new requests to rspamd will be processed by newly started workers.
-- `SIGTERM` - terminate rspamd system.
-- `SIGUSR1` - reopen log files (useful for log files rotation).
+- `SIGHUP` - restart rspamd: reread config file, start new workers (as well as controller and other processes), stop accepting connections by old workers, reopen all log files. Note that old workers would be terminated after one minute which should allow processing of all pending requests. All new requests to rspamd will be processed by the newly started workers.
+- `SIGTERM` - terminate rspamd.
+- `SIGUSR1` - reopen log files (useful for log file rotation).
 
-These signals may be used in start scripts as it is done in `FreeBSD` start script. Restarting of rspamd is performed softly: no connections are dropped and if a new config is incorrect then the old config is used.
+These signals may be used in rc-style scripts. Restarting of rspamd is performed softly: no connections are dropped and if a new config is incorrect then the old config is used.
diff --git a/doc/markdown/architecture/protocol.md b/doc/markdown/architecture/protocol.md
index 51ac8e9c6..56e1da1d4 100644
--- a/doc/markdown/architecture/protocol.md
+++ b/doc/markdown/architecture/protocol.md
@@ -1,15 +1,12 @@
-# Rspamd protocol
+# rspamd protocol
 
 ## Protocol basics
 
-Rspamd uses HTTP protocol of either version 1.0 or 1.1. However, there is compatibility layer described further in this document.
-Rspamd defines some servicing headers that allows to pass extra information about a message scanned, such as envelope data, IP address,
-SMTP sasl authentication data and so on. Rspamd supports both normal and chunked encoded HTTP request, however, form URL encoding is **NOT** supported currently.
+rspamd uses the HTTP protocol, either version 1.0 or 1.1. (There is also a compatibility layer described further in this document.) rspamd defines some headers which allow the passing of extra information about a scanned message, such as envelope data, IP address or SMTP sasl authentication data, etc. rspamd supports normal and chunked encoded HTTP requests.
 
-## Rspamd HTTP request
+## rspamd HTTP request
 
-Rspamd encourages usage of HTTP protocol since it is standard and can be used by literally every programming language without exotic libraries.
-The typical HTTP request looks like the following:
+rspamd encourages the use of the HTTP protocol since it is standard and can be used by every programming language without the use of exotic libraries. A typical HTTP request looks like the following:
 
 	POST /check HTTP/1.0
 	Content-Length: 26969
@@ -21,32 +18,31 @@ The typical HTTP request looks like the following:
 
 	<your message goes here>
 
-You can also use chunked encoding that allows streamlined data transfer which is useful if you don't know the length of the message.
+You can also use chunked encoding that allows streamlined data transfer which is useful if you don't know the length of a message.
 
 ### HTTP request
 
-Normally, you should just use '/check' here. However, if you talk to the controller then you might want to use controllers commands here. 
+Normally, you should just use '/check' here. However, if you want to communicate with the controller then you might want to use controllers commands.
 
 (TODO: write this part)
 
 ### HTTP headers
 
-To avoid unnecessary work, rspamd allows MTA to pass pre-processed data about the message by using either HTTP headers or JSON control block (described further in this document). 
-Rspamd supports the following non-standard HTTP headers:
+To avoid unnecessary work, rspamd allows an MTA to pass pre-processed data about the message by using either HTTP headers or a JSON control block (described further in this document). rspamd supports the following non-standard HTTP headers:
 
 | Header          | Description                       |
-| :-------------- | :-------------------------------- |                                                                                                                 
-| **Deliver-To:** | Defines actual delivery recipient of message. Can be used for personalized statistic and for user specific options.|  
-| **IP:**         | Defines IP from which this message is received.                                                                    | 
-| **Helo:**       | Defines SMTP helo.                                                                                                 |
-| **Hostname:**   | Defines resolved hostname.                                                                                         |
-| **From:**       | Defines SMTP mail from command data.                                                                               |  
-| **Queue-Id:**   | Defines SMTP queue id for message (can be used instead of message id in logging).                                  | 
-| **Rcpt:**       | Defines SMTP recipient (it may be several `Rcpt` headers).                                                         |
-| **Pass:**       | If this header has `all` value, all filters would be checked for this message.                                     |
-| **Subject:**    | Defines subject of message (is used for non-mime messages).                                                        |
+| :-------------- | :-------------------------------- |
+| **Deliver-To:** | Defines actual delivery recipient of message. Can be used for personalized statistics and for user specific options. |
+| **IP:**         | Defines IP from which this message is received. |
+| **Helo:**       | Defines SMTP helo |
+| **Hostname:**   | Defines resolved hostname |
+| **From:**       | Defines SMTP mail from command data |
+| **Queue-Id:**   | Defines SMTP queue id for message (can be used instead of message id in logging). |
+| **Rcpt:**       | Defines SMTP recipient (there may be several `Rcpt` headers) |
+| **Pass:**       | If this header has `all` value, all filters would be checked for this message. |
+| **Subject:**    | Defines subject of message (is used for non-mime messages). |
 | **User:**       | Defines SMTP user. |
-| **Message-Length:**       | Defines the length of message excluding the control block. |
+| **Message-Length:** | Defines the length of message excluding the control block. |
 
 Controller also defines certain headers:
 
@@ -54,9 +50,9 @@ Controller also defines certain headers:
 
 Standard HTTP headers, such as `Content-Length`, are also supported.
 
-## Rspamd HTTP reply
+## rspamd HTTP reply
 
-Rspamd reply is encoded using `json` format. Here is a typical HTTP reply:
+rspamd reply is encoded in `JSON`. Here is a typical HTTP reply:
 
 	HTTP/1.1 200 OK
 	Connection: close
@@ -111,7 +107,7 @@ Rspamd reply is encoded using `json` format. Here is a typical HTTP reply:
 
 For convenience, the reply is LINTed using [jsonlint](http://jsonlint.com). The actual reply is compressed for speed.
 
-The reply can be treated as the JSON object where keys are metric names (namely `default`) and values are objects that represent metric.
+The reply can be treated as a JSON object where keys are metric names (namely `default`) and values are objects that represent metrics.
 
 Each metric has the following fields:
 
@@ -124,27 +120,26 @@ Each metric has the following fields:
 	- `greylist` - message should be greylisted;
 	- `add header` - message is suspicious and should be marked as spam
 	- `rewrite subject` - message is suspicious and should have subject rewritten
-	- `soft reject` - message should be temporary rejected at the moment (for example, due to rate limit exhausting)
+	- `soft reject` - message should be temporary rejected (for example, due to rate limit exhausting)
 	- `reject` - message should be rejected as spam
 
-Additionally, metric contains all symbols added during message's processing indexed by symbols' names.
+Additionally, metric contains all symbols added during a message's processing, indexed by symbol names.
 
-Moreover, some other keys might be in the reply:
+Additional keys which may be in the reply include:
 
-* `subject` - if action is `rewrite subject` then this value defines the desired subject for a message
+* `subject` - if action is `rewrite subject` this value defines the desired subject for a message
 * `urls` - a list of urls found in a message (only hostnames)
 * `emails` - a list of emails found in a message
 * `message-id` - ID of message (useful for logging)
-* `messages` - array of optional messages added by some rspamd filters (such as `SPF`)
+* `messages` - array of optional messages added by rspamd filters (such as `SPF`)
 
-## Rspamd JSON control block
+## rspamd JSON control block
 
-Since rspamd 0.9 it is also possible to pass additional data by using request body prepending JSON control block to the message. Hence, you can use either headers or JSON block to pass data from MTA to rspamd.
-The advantage of JSON block is that it can be encrypted using `httpcrypt`. Headers encryption is currently unsupported.
+Since rspamd version 0.9 it is also possible to pass additional data by prepending a JSON control block to a message. So you can use either headers or a JSON block to pass data from the MTA to rspamd.
 
-To use JSON control block, you need to pass extra header to rspamd called `Message-Length`. This header should be equal to the size of the message **excluding** JSON control block. Therefore, the size of control block is equal to `Content-Length` - `Message-Length`. Rspamd assumes that a message starts immediately after control block (with no extra CRLF). This method is equally compatible with streaming transfer, however even if not specifying `Content-Length` you are still required to specify `Message-Length`.
+To use a JSON control block, you need to pass an extra header called `Message-Length` to rspamd. This header should be equal to the size of the message **excluding** the JSON control block. Therefore, the size of the control block is equal to `Content-Length - Message-Length`. rspamd assumes that a message starts immediately after the control block (with no extra CRLF). This method is equally compatible with streaming transfer, however even if you are not specifying `Content-Length` you are still required to specify `Message-Length`.
 
-Here is an example of JSON control block:
+Here is an example of a JSON control block:
 
 ~~~json
 {
@@ -156,43 +151,4 @@ Here is an example of JSON control block:
 }
 ~~~
 
-Moreover, [UCL](https://github.com/vstakhov/libucl) json extensions and syntax conventions are also supported inside control block.
-
-## Legacy RSPAMC protocol
-
-For compatibility, rspamd also supports legacy `RSPAMC` and also spamassassin `SPAMC` protocols. Thought their usage is discouraged, these protocols could be still used as last resort to communicate with rspamd from legacy applications.
-The rspamc dialog looks as following:
-
-	SYMBOLS RSPAMC/1.1
-	Content-Length: 2200
-
-	<message octets>
-
-	RSPAMD/1.1 0 OK
-	Metric: default; True; 10.40 / 10.00 / 0.00
-	Symbol: R_UNDISC_RCPT
-	Symbol: ONCE_RECEIVED
-	Symbol: R_MISSING_CHARSET
-	Urls: 
-
-Rspamc protocol support different commands as well:
-
-| Command | Description   |
-| :-------| :-----        |                                                                               
-| CHECK   | Check a message and output results for each metric. But do not output symbols. |      
-| SYMBOLS | Same as `CHECK` but output symbols.                                          |    
-| PROCESS | Same as `SYMBOLS` but output also original message with inserted X-Spam headers. |  
-| PING    | Do not do any processing, just check rspamd state:                                 |
-
-
-After command there should be one mandatory header: `Content-Length` that defines message's length in bytes and optional headers (same as for HTTP).
-
-Rspamd supports spamassassin `spamc` protocol and you can even pass rspamc headers in spamc mode, but reply of rspamd in `spamc` mode is truncated to "default" metric only with no options for symbols being displayed. Rspamc reply looks as following: 
-
-	RSPAMD/1.1 0 OK
-	Metric: default; True; 10.40 / 10.00 / 0.00
-	Symbol: R_UNDISC_RCPT
-	Symbol: ONCE_RECEIVED
-	Symbol: R_MISSING_CHARSET
-	Urls: 
- 
+Moreover, [UCL](https://github.com/vstakhov/libucl) json extensions and syntax conventions are also supported inside the control block.
\ No newline at end of file
diff --git a/doc/markdown/modules/regexp.md b/doc/markdown/modules/regexp.md
index f08079bff..01d7a0635 100644
--- a/doc/markdown/modules/regexp.md
+++ b/doc/markdown/modules/regexp.md
@@ -60,12 +60,24 @@ The match type is defined by special flags after the last `/` symbol:
 * `B` - MIME header regexp (applied for headers in MIME parts only)
 * `R` - full headers content (applied for all headers undecoded and for the message only - **not** including MIME headers)
 * `M` - raw message regexp
-* `P` - part regexp
+* `P` - part regexp without HTML tags
+* `Q` - part regexp with HTML tags
+* `C` - spamassassin `BODY` regexp analogue(see http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt)
+* `D` - spamassassin `RAWBODY` regexp analogue
 * `U` - URL regexp
 
+From 1.3, it is also possible to specify long regexp types for convenience in curly braces:
 
-We strongly discourage from using of raw message regexps as they are expensive and
-should be replaced by [trie](trie.md) rules if possible.
+* `{header}` - header regexp
+* `{raw_header}` - undecoded header regexp (e.g. without quoted-printable decoding)
+* `{mime_header}` - MIME header regexp (applied for headers in MIME parts only)
+* `{all_header}` - full headers content (applied for all headers undecoded and for the message only - **not** including MIME headers)
+* `{body}` - raw message regexp
+* `{mime}` - part regexp without HTML tags
+* `{raw_mime}` - part regexp with HTML tags
+* `{sa_body}` - spamassassin `BODY` regexp analogue(see http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt)
+* `{sa_raw_body}` - spamassassin `RAWBODY` regexp analogue
+* `{url}` - URL regexp
 
 Each regexp also supports the following flags:
 
@@ -122,7 +134,7 @@ Here is an example of table form definition of regexp rule:
 
 ~~~lua
 config['regexp']['RE_TEST'] = {
-    re = '/test/P',
+    re = '/test/i{mime}',
     score = 10.0,
     condition = function(task)
         if task:get_header('Subject') then
diff --git a/doc/rspamc.1 b/doc/rspamc.1
index b29bbb20d..331bdada8 100644
--- a/doc/rspamc.1
+++ b/doc/rspamc.1
@@ -100,22 +100,22 @@ Emulate that message was received from specified ip address
 .RE
 .TP
 .B \-u \f[I]username\f[], \-\-user=\f[I]username\f[]
-Emulate that message was from specified user
+Emulate that message was received from specified authenticated user
 .RS
 .RE
 .TP
 .B \-d \f[I]user\@domain\f[], \-\-deliver=\f[I]user\@domain\f[]
-Emulate that message is delivered to specified user
+Emulate that message is delivered to specified user (for LDA/statistics)
 .RS
 .RE
 .TP
 .B \-F \f[I]user\@domain\f[], \-\-from=\f[I]user\@domain\f[]
-Emulate that message is from specified user
+Emulate that message has specified SMTP FROM address
 .RS
 .RE
 .TP
 .B \-r \f[I]user\@domain\f[], \-\-rcpt=\f[I]user\@domain\f[]
-Emulate that message is for specified user
+Emulate that message has specified SMTP RCPT address
 .RS
 .RE
 .TP
diff --git a/doc/rspamc.1.md b/doc/rspamc.1.md
index 8e76d01b2..fb0fa58c8 100644
--- a/doc/rspamc.1.md
+++ b/doc/rspamc.1.md
@@ -64,16 +64,16 @@ requires input.
 :	Emulate that message was received from specified ip address
 
 -u *username*, \--user=*username*
-:	Emulate that message was from specified user
+:	Emulate that message was received from specified authenticated user
 
 -d *user@domain*, \--deliver=*user@domain*
-:	Emulate that message is delivered to specified user
+:	Emulate that message is delivered to specified user (for LDA/statistics)
 
 -F *user@domain*, \--from=*user@domain*
-:	Emulate that message is from specified user
+:	Emulate that message has specified SMTP FROM address
 
 -r *user@domain*, \--rcpt=*user@domain*
-:	Emulate that message is for specified user
+:	Emulate that message has specified SMTP RCPT address
 
 \--helo=*helo_string*
 :	Imitate SMTP HELO passing from MTA
@@ -167,4 +167,4 @@ Add custom action's weight:
 Rspamd documentation and source codes may be downloaded from
 <https://rspamd.com/>.
 
-[rspamd-workers]: https://rspamd.com/doc/workers/
\ No newline at end of file
+[rspamd-workers]: https://rspamd.com/doc/workers/