Another polish round.

1 files changed, 22 insertions, 22 deletions

diff --git a/doc/markdown/architecture/index.md b/doc/markdown/architecture/index.md
index 78b3131ff..3c854a65b 100644
--- a/doc/markdown/architecture/index.md
+++ b/doc/markdown/architecture/index.md
@@ -8,16 +8,16 @@ process messages rspamd uses a set of so called `rules`. Each `rule` is a symbol
 name associated with some 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.
+- `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.
 
 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:
 
-- 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.
+- `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
@@ -40,9 +40,9 @@ 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:
 
-- SPF_ALLOW: -1
-- SPF_DENY: 2
-- SPF_SOFTFAIL: 0.5
+- `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.
@@ -67,15 +67,15 @@ Another important property of metrics is their actions set. This set defines rec
 actions for a message if it reach a certain score defined by all rules triggered.
 Rspamd defines the following actions:
 
-- **No action**: a message is likely ham;
-- **Greylist**: greylist message is 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
+- `No action`: a message is likely ham;
+- `Greylist`: greylist message is 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
+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
@@ -135,14 +135,14 @@ First of all, it is important to note that all user's signals should be sent to
 - by getting process info: 
 
 		$ ps auxwww | grep rspamd
-		nobody 28378  0.0  0.2 49744  9424   rspamd: main process (rspamd)
-		nobody 64082  0.0  0.2 50784  9520   rspamd: worker process (rspamd)
-		nobody 64083  0.0  0.3 51792 11036   rspamd: worker process (rspamd)
-		nobody 64084  0.0  2.7 158288 114200 rspamd: controller process (rspamd)
-		nobody 64085  0.0  1.8 116304 75228  rspamd: fuzzy storage (rspamd)
+		nobody 28378  0.0  0.2 49744  9424   rspamd: main process
+		nobody 64082  0.0  0.2 50784  9520   rspamd: worker process
+		nobody 64083  0.0  0.3 51792 11036   rspamd: worker process
+		nobody 64084  0.0  2.7 158288 114200 rspamd: controller process
+		nobody 64085  0.0  1.8 116304 75228  rspamd: fuzzy storage
 	
 		$ ps auxwww | grep rspamd | grep main
-		nobody 28378  0.0  0.2 49744  9424   rspamd: main process (rspamd)
+		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: