Re: [pmg-devel] applied-series: [PATCH pmg-docs 1/5] configuration management: language fix-up

[Stoiko Ivanov <s.ivanov@proxmox.com>]

applied the series. huge thanks for the effort!

On Tue, 15 Jun 2021 12:36:01 +0200
Dylan Whyte <d.whyte@proxmox.com> wrote:

> this fixes wording, spelling, grammar, etc. for the chapter
> 'configuration management'
> 
> Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
> ---
>  pmgconfig.adoc | 256 ++++++++++++++++++++++++-------------------------
>  1 file changed, 128 insertions(+), 128 deletions(-)
> 
> diff --git a/pmgconfig.adoc b/pmgconfig.adoc
> index 67c1bd8..1ae80c3 100644
> --- a/pmgconfig.adoc
> +++ b/pmgconfig.adoc
> @@ -27,15 +27,15 @@ endif::manvolnum[]
>  
>  {pmg} is usually configured using the web-based Graphical User
>  Interface (GUI), but it is also possible to directly edit the
> -configuration files, use the REST API over 'https'
> +configuration files, using the REST API over 'https'
>  or the command line tool `pmgsh`.
>  
>  The command line tool `pmgconfig` is used to simplify some common
> -configuration tasks, i.e. to generate cerificates and to rewrite
> +configuration tasks, such as generating certificates and rewriting
>  service configuration files.
>  
>  NOTE: We use a Postgres database to store mail filter rules and
> -statistic data. See chapter xref:chapter_pmgdb[Database Management]
> +statistical data. See chapter xref:chapter_pmgdb[Database Management]
>  for more information.
>  
>  
> @@ -45,9 +45,8 @@ Configuration files overview
>  `/etc/network/interfaces`::
>  
>  Network setup. We never modify this file directly. Instead, we write
> -changes to `/etc/network/interfaces.new`. When you reboot, we rename
> -the file to `/etc/network/interfaces`, so the changes are applied
> -on the next reboot.
> +changes to `/etc/network/interfaces.new`. When you reboot, {pmg} renames
> +the file to `/etc/network/interfaces`, thus applying the changes.
>  
>  `/etc/resolv.conf`::
>  
> @@ -56,7 +55,7 @@ to create the FQDN and domain name used in the postfix configuration.
>  
>  `/etc/hostname`::
>  
> -The system's host name. {pmg} uses the hostname to create the FQDN used
> +The system's hostname. {pmg} uses the hostname to create the FQDN used
>  in the postfix configuration.
>  
>  `/etc/hosts`::
> @@ -65,7 +64,8 @@ Static table lookup for hostnames.
>  
>  `/etc/pmg/pmg.conf`::
>  
> -Stores common administration options, i.e. the spam and mail proxy setup.
> +Stores common administration options, such as the spam and mail proxy
> +configuration.
>  
>  `/etc/pmg/cluster.conf`::
>  
> @@ -120,15 +120,15 @@ Keys and Certificates
>  
>  `/etc/pmg/pmg-api.pem`::
>  
> -Key and certificate (combined) used be the HTTPs server (API).
> +Key and certificate (combined) used by the HTTPS server (API).
>  
>  `/etc/pmg/pmg-authkey.key`::
>  
> -Privat key use to generate authentication tickets.
> +Private key used to generate authentication tickets.
>  
>  `/etc/pmg/pmg-authkey.pub`::
>  
> -Public key use to verify authentication tickets.
> +Public key used to verify authentication tickets.
>  
>  `/etc/pmg/pmg-csrf.key`::
>  
> @@ -147,20 +147,20 @@ Key for DKIM signing mails with selector '<selector>'.
>  Service Configuration Templates
>  -------------------------------
>  
> -{pmg} uses various services to implement mail filtering, for example
> +{pmg} uses various services to implement mail filtering, for example,
>  the {postfix} Mail Transport Agent (MTA), the {clamav} antivirus
> -engine and the Apache {spamassassin} project. These services use
> -separate configuration files, so we need to rewrite those files when
> +engine, and the Apache {spamassassin} project. These services use
> +separate configuration files, so we need to rewrite those files when the
>  configuration is changed.
>  
> -We use a template based approach to generate those files. The {tts} is
> +We use a template-based approach to generate these files. The {tts} is
>  a well known, fast and flexible template processing system. You can
>  find the default templates in `/var/lib/pmg/templates/`. Please do not
> -modify them directly, because your modification would get lost on the
> +modify these directly, otherwise your modifications will be lost on the
>  next update. Instead, copy the template you wish to change to
>  `/etc/pmg/templates/`, then apply your changes there.
>  
> -Templates can access any configuration setting, and you can use the
> +Templates can access any configuration settings, and you can use the
>  `pmgconfig dump` command to get a list of all variable names:
>  
>  ----
> @@ -173,9 +173,9 @@ pmg.admin.advfilter = 1
>  ...
>  ----
>  
> -The same tool is used to force regeneration of all template based
> -configuration files. You need to run that after modifying a template,
> -or when you directly edit configuration files
> +The same tool is used to force the regeneration of all template-based
> +configuration files. You need to run the following after modifying a template,
> +or when you directly edit configuration files:
>  
>  ----
>  # pmgconfig sync --restart 1
> @@ -192,28 +192,28 @@ synced from the master node to all cluster members.
>  White- and Blacklists
>  ---------------------
>  
> -{pmg} has multiple white- and blacklists. It differentiates between the 
> -xref:pmgconfig_mailproxy_options[SMTP Whitelist]. The rule-based whitelist
> +{pmg} has multiple white- and blacklists. It differentiates between the
> +xref:pmgconfig_mailproxy_options[SMTP Whitelist], the rule-based whitelist
>  and the user whitelist.
> -In addition to the whitelists there are 2 separate blacklists. The rule-based
> +In addition to the whitelists, there are two separate blacklists: the rule-based
>  blacklist and the user blacklist.
>  
>  SMTP Whitelist
>  ~~~~~~~~~~~~~~
>  
>  The xref:pmgconfig_mailproxy_options[SMTP Whitelist] is responsible for disabling
> -greylisting as well as SPF and DNSBL checks. These are done during the SMTP
> +greylisting, as well as SPF and DNSBL checks. These are done during the SMTP
>  dialogue.
>  
>  Rule-based White-/Blacklist
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
>  The xref:chapter_mailfilter[rule-based white- and blacklists] are predefined
> -rules. They work by checking the attached 'Who' objects, containing e.g. a
> -domain or a mail address, for a match. If it matches, the assigned action is
> -used which by default is 'Accept' for the whitelist rule and 'Block' for the
> -blacklist rule. In the default setup the blacklist rule has priority over the
> -whitelist rule and spam checks.
> +rules. They work by checking the attached 'Who' objects, containing, for
> +example, a domain or a mail address for a match. If it matches, the assigned
> +action is used, which by default is 'Accept' for the whitelist rule and 'Block'
> +for the blacklist rule. In the default setup, the blacklist rule has priority
> +over the whitelist rule and spam checks.
>  
>  User White-/Blacklist
>  ~~~~~~~~~~~~~~~~~~~~~
> @@ -221,13 +221,13 @@ User White-/Blacklist
>  The user white- and blacklist are user specific. Every user can add mail addresses
>  to their white- and blacklist. When a user adds a mail address to the whitelist,
>  the result of the spam analysis will be discarded for that recipient. This can
> -help the mail being accepted, but it still depends on the other rules what
> -happens next. In the default setup this results in the mail being accepted for
> +help in the mail being accepted, but what happens next still depends on the
> +other rules. In the default setup, this results in the mail being accepted for
>  this recipient.
>  
> -For mail addresses on a user's blacklist the spam score will be increased by 100.
> -It still depends on the rule system what happens when a spam score that high is
> -encountered. In the default setup it will be recognized as spam and quarantined
> +For mail addresses on a user's blacklist, the spam score will be increased by
> +100. What happens when a high spam score is encountered still depends on the
> +rule system. In the default setup, it will be recognized as spam and quarantined
>  (spam score of 3 or higher).
>  
>  [[pmgconfig_systemconfig]]
> @@ -241,13 +241,12 @@ ifndef::manvolnum[]
>  [thumbnail="pmg-gui-network-config.png", big=1]
>  endif::manvolnum[]
>  
> -Normally the network and time is already configured when you visit the
> -GUI. The installer asks for those settings and sets up the correct
> -values.
> +As network and time are configured in the installer, these generally do not
> +need to be configured again in the GUI.
>  
>  The default setup uses a single Ethernet adapter and static IP
>  assignment. The configuration is stored at '/etc/network/interfaces',
> -and the actual network setup is done the standard Debian way using
> +and the actual network setup is done the standard Debian way, using the
>  package 'ifupdown'.
>  
>  .Example network setup '/etc/network/interfaces'
> @@ -282,7 +281,7 @@ ifndef::manvolnum[]
>  endif::manvolnum[]
>  
>  
> -Those settings are saved to subsection 'admin' in `/etc/pmg/pmg.conf`,
> +These settings are saved to the 'admin' subsection in `/etc/pmg/pmg.conf`,
>  using the following configuration keys:
>  
>  include::pmg.admin-conf-opts.adoc[]
> @@ -301,7 +300,7 @@ ifndef::manvolnum[]
>  [thumbnail="pmg-gui-mailproxy-relaying.png", big=1]
>  endif::manvolnum[]
>  
> -Those settings are saved to subsection 'mail' in `/etc/pmg/pmg.conf`,
> +These settings are saved to the 'mail' subsection in `/etc/pmg/pmg.conf`,
>  using the following configuration keys:
>  
>  include::pmg.mail-relaying-conf-opts.adoc[]
> @@ -314,7 +313,7 @@ ifndef::manvolnum[]
>  [thumbnail="pmg-gui-mailproxy-relaydomains.png", big=1]
>  endif::manvolnum[]
>  
> -List of relayed mail domains, i.e. what destination domains this
> +A list of relayed mail domains, that is, what destination domains this
>  system will relay mail to. The system will reject incoming mails to
>  other domains.
>  
> @@ -327,7 +326,7 @@ ifndef::manvolnum[]
>  [thumbnail="pmg-gui-mailproxy-ports.png", big=1]
>  endif::manvolnum[]
>  
> -Those settings are saved to subsection 'mail' in `/etc/pmg/pmg.conf`,
> +These settings are saved to the 'mail' subsection in `/etc/pmg/pmg.conf`,
>  using the following configuration keys:
>  
>  include::pmg.mail-ports-conf-opts.adoc[]
> @@ -341,7 +340,7 @@ ifndef::manvolnum[]
>  [thumbnail="pmg-gui-mailproxy-options.png", big=1]
>  endif::manvolnum[]
>  
> -Those settings are saved to subsection 'mail' in `/etc/pmg/pmg.conf`,
> +These settings are saved to the 'mail' subsection in `/etc/pmg/pmg.conf`,
>  using the following configuration keys:
>  
>  include::pmg.mail-options-conf-opts.adoc[]
> @@ -351,9 +350,9 @@ include::pmg.mail-options-conf-opts.adoc[]
>  Before and After Queue scanning
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
> -Scanning email can happen at two different stages of mail-processing:
> +Email scanning can happen at two different stages of mail-processing:
>  
> -* Before-queue filtering: During the SMTP Session, after the complete message
> +* Before-queue filtering: During the SMTP session, after the complete message
>    has been received (after the 'DATA' command).
>  
>  * After-queue filtering: After initially accepting the mail and putting it on
> @@ -361,37 +360,37 @@ Scanning email can happen at two different stages of mail-processing:
>  
>  Before-queue filtering has the advantage that the system can reject a mail (by
>  sending a permanent reject code '554'), and leave the task of notifying the
> -original sender to the other mailserver. This is of particular advantage if
> +original sender to the other mail server. This is of particular advantage if
>  the processed mail is a spam message or contains a virus and has a forged
> -sender-address. Sending out a notification in this situation leads so-called
> +sender address. Sending out a notification in this situation leads to so-called
>  'backscatter' mail, which might cause your server to get listed as spamming on
>  RBLs (Real-time Blackhole List).
>  
>  After-queue filtering has the advantage of providing faster delivery of
> -mails for the sending servers, since queueing mails is much faster than
> -analyzing it for spam and viruses.
> -
> -If a mail is addressed to multiple recipients (e.g. when multiple addresses are
> -subscribed to the same mailing list) the situation is more complicated: Your
> -mailserver can only reject or accept the mail for all recipients, after having
> -received the complete message, while your rule setup might accept the mail for
> -part of the recipients and reject it for others. This can be due to a
> -complicated rule setup, or if your users use the 'User White- and Blacklist'
> -feature.
> -
> -If the resulting action of the rule system is the same for all recipients {pmg}
> -responds accordingly if configured for before queue filtering (sending '554'
> +mails for the sending servers, since queuing emails is much faster than
> +analyzing them for spam and viruses.
> +
> +If a mail is addressed to multiple recipients (for example, when multiple
> +addresses are subscribed to the same mailing list), the situation is more
> +complicated; your mail server can only reject or accept the mail for all
> +recipients, after having received the complete message, while your rule setup
> +might accept the mail for part of the recipients and reject it for others. This
> +can be due to a complicated rule setup, or if your users use the 'User White-
> +and Blacklist' feature.
> +
> +If the resulting action of the rule system is the same for all recipients, {pmg}
> +responds accordingly, if configured for before-queue filtering (sending '554'
>  for a blocked mail and '250' for an accepted or quarantined mail). If some
>  mailboxes accept the mail and some reject it, the system has to accept the mail.
>  
>  Whether {pmg} notifies the sender that delivery failed for some recipients by
>  sending a non-delivery report, depends on the 'ndr_on_block' setting in
> -'/etc/pmg/pmg.conf'. If enabled an NDR is sent. Keeping it disabled prevents
> +'/etc/pmg/pmg.conf'. If enabled, an NDR is sent. Keeping this disabled prevents
>  NDRs being sent to the (possibly forged) sender and thus minimizes the chance
> -of getting your IP listed on a RBL. However in certain environments it can be
> +of getting your IP listed on an RBL. However in certain environments, it can be
>  unacceptable not to inform the sender about a rejected mail.
>  
> -The setting has the same effect if after queue filtering is configured, with
> +The setting has the same effect if after-queue filtering is configured, with
>  the exception that an NDR is always sent out, even if all recipients block the
>  mail, since the mail already got accepted before being analyzed.
>  
> @@ -405,10 +404,10 @@ Greylisting
>  
>  Greylisting is a technique for preventing unwanted messages from reaching the
>  resource intensive stages of content analysis (virus detection and spam
> -detection): By initially replying with a temporary failure code ('450') to
> -each new email, the {pmg} tells the sending server that it should queue the
> -mail and retry delivery at a later moment. Since certain kinds of spam get
> -sent out by software, which has no provisioning for queueing, these mails are
> +detection). By initially replying with a temporary failure code ('450') to
> +each new email, {pmg} tells the sending server that it should queue the
> +mail and retry delivery at a later point. Since certain kinds of spam get
> +sent out by software which has no provisioning for queuing, these mails are
>  dropped without reaching {pmg} or your mailbox.
>  
>  The downside of greylisting is the delay introduced by the initial deferral of
> @@ -419,24 +418,24 @@ coming from a source for a recipient, which have passed greylisting in the
>  past are directly passed on: For each email the triple '<sender network,
>  sender email, recipient email>' is stored in a list, along with the time when
>  delivery was attempted. If an email fits an already existing triple, the
> -timestamp for that triple is updated and the email is accepted for further
> +timestamp for that triple is updated, and the email is accepted for further
>  processing.
>  
> -As long as a sender and recipient do communicate frequently there is no delay
> +As long as a sender and recipient communicate frequently, there is no delay
>  introduced by enabling greylisting. A triple is removed after a longer period
> -of time, when no mail fitting that triple has been seen. The timeouts in {pmg}
> +of time, if no mail fitting that triple has been seen. The timeouts in {pmg}
>  are:
>  
>  * 2 days for the retry of the first delivery
>  
> -* 36 days for known triples
> +* 36 days for a known triple
>  
> -Mails with an empty envelope-sender are always delayed.
> +Mails with an empty envelope sender are always delayed.
>  
>  Some email service providers send out emails for one domain from multiple
> -servers. To prevent delays due to an email coming in from 2 separate IPs of
> -the same provider the triples store a network ('cidr') instead of a single IP.
> -For certain large providers the default network size might be too small. You
> +servers. To prevent delays due to an email coming in from two separate IPs of
> +the same provider, the triples store a network ('cidr') instead of a single IP.
> +For certain large providers, the default network size might be too small. You
>  can configure the netmask applied to an IP for the greylist lookup in
>  '/etc/pmg/pmg.conf' or in the GUI with the settings 'greylistmask' for IPv4
>  and 'greylistmask6' for IPv6 respectively.
> @@ -451,13 +450,13 @@ ifndef::manvolnum[]
>  endif::manvolnum[]
>  
>  You can use {pmg} to send emails to different internal email servers. For
> -example you can send emails addressed to domain.com to your first email server,
> +example, you can send emails addressed to domain.com to your first email server
>  and emails addressed to subdomain.domain.com to a second one.
>  
>  You can add the IP addresses, hostname, transport protocol (smtp/lmtp),
>  transport ports and mail domains (or just single email addresses) of your
>  additional email servers. When transport protocol is set to `lmtp`, the option
> -'Use MX' is useless and will be automatically set to 'No'.
> +'Use MX' is useless and will automatically be set to 'No'.
>  
>  
>  [[pmgconfig_mailproxy_networks]]
> @@ -471,8 +470,8 @@ endif::manvolnum[]
>  You can add additional internal (trusted) IP networks or hosts.  All hosts in
>  this list are allowed to relay.
>  
> -NOTE: Hosts in the same subnet with Proxmox can relay by default and it’s not
> -needed to add them in this list.
> +NOTE: Hosts in the same subnet as {pmg} can relay by default and don't need to
> +be added to this list.
>  
>  
>  [[pmgconfig_mailproxy_tls]]
> @@ -490,24 +489,24 @@ generates a new self signed certificate for you (`/etc/pmg/pmg-tls.pem`).
>  
>  {pmg} uses opportunistic TLS encryption by default. The SMTP transaction is
>  encrypted if the 'STARTTLS' ESMTP feature is supported by the remote
> -server. Otherwise, messages are sent in the clear.
> +server. Otherwise, messages are sent unencrypted.
>  
>  You can set a different TLS policy per destination. A destination is either a
> -remote domain or a next-hop destination as specified in `/etc/pmg/transport`.
> +remote domain or a next-hop destination, as specified in `/etc/pmg/transport`.
>  This can be used if you need to prevent email delivery without
>  encryption, or to work around a broken 'STARTTLS' ESMTP implementation. See
>  {postfix_tls_readme} for details on the supported policies.
>  
>  Enable TLS logging::
>  
> -To get additional information about SMTP TLS activity you can enable
> -TLS logging. That way information about TLS sessions and used
> +To get additional information about SMTP TLS activity, you can enable
> +TLS logging. In this case, information about TLS sessions and used
>  certificates is logged via syslog.
>  
>  Add TLS received header::
>  
>  Set this option to include information about the protocol and cipher
> -used as well as the client and issuer CommonName into the "Received:"
> +used, as well as the client and issuer CommonName into the "Received:"
>  message header.
>  
>  Those settings are saved to subsection 'mail' in `/etc/pmg/pmg.conf`,
> @@ -526,13 +525,13 @@ endif::manvolnum[]
>  
>  DomainKeys Identified Mail (DKIM) Signatures (see {dkim_rfc}) is a method to
>  cryptographically authenticate a mail as originating from a particular domain.
> -Before sending the mail a hash over certain header fields and the body is
> +Before sending the mail, a hash over certain header fields and the body is
>  computed, signed with a private key and added in the `DKIM-Signature` header of
>  the mail. The 'selector' (a short identifier chosen by you, used to identify
>  which system and private key were used for signing) is also included in the
>  `DKIM-Signature` header.
>  
> -The verification is done by the receiver: The public key is fetched
> +The verification is done by the receiver. The public key is fetched
>  via DNS TXT lookup for `yourselector._domainkey.yourdomain.example` and used
>  for verifying the hash. You can publish multiple selectors for your domain,
>  each used by a system which sends email from your domain, without the need to
> @@ -540,10 +539,10 @@ share the private key.
>  
>  {pmg} verifies DKIM Signatures for inbound mail in the Spam Filter by default.
>  
> -Additionally it supports conditionally signing outbound mail if configured.
> -It uses one private key and selector per PMG deployment (all nodes in a cluster
> -use the same key). The key has a minimal size of 1024 bits and rsa-sha256 is
> -used as signing algorithm.
> +Additionally, it supports conditionally signing outbound mail, if configured.
> +It uses one private key and selector per {pmg} deployment (all nodes in a
> +cluster use the same key). The key has a minimal size of 1024 bits and
> +rsa-sha256 is used as the signing algorithm.
>  
>  The headers included in the signature are taken from the list of
>  `Mail::DKIM::Signer`. Additionally `Content-Type` (if present), `From`, `To`,
> @@ -568,9 +567,10 @@ record which you need to add to all domains signed by {pmg} by clicking on the
>  Sign all Outgoing Mail::
>  
>  Controls whether all outbound mail should get signed or only mails from domains
> -listed in `/etc/pmg/dkim/domains` if it exists and `/etc/pmg/domains` otherwise.
> +listed in `/etc/pmg/dkim/domains`, if it exists and `/etc/pmg/domains`
> +otherwise.
>  
> -Those settings are saved to subsection 'admin' in `/etc/pmg/pmg.conf`,
> +These settings are saved to the 'admin' subsection in `/etc/pmg/pmg.conf`,
>  using the following configuration keys:
>  
>  include::pmg.admin-dkim-conf-opts.adoc[]
> @@ -586,10 +586,10 @@ endif::manvolnum[]
>  All SMTP checks are disabled for those entries (e.g. Greylisting,
>  SPF, DNSBL, ...)
>  
> -DNSBL checks are done by `postscreen` which works on IP addresses and networks.
> +DNSBL checks are done by `postscreen`, which works on IP addresses and networks.
>  This means it can only make use of the `IP Address` and `IP Network` entries.
>  
> -NOTE: If you use a backup MX server (e.g. your ISP offers this service
> +NOTE: If you use a backup MX server (for example, your ISP offers this service
>  for you) you should always add those servers here.
>  
>  NOTE: To disable DNSBL checks entirely, remove any `DNSBL Sites` entries in
> @@ -610,7 +610,7 @@ endif::manvolnum[]
>  signatures. This makes it harder for spammers to identify one aspect
>  which they can craft their messages to work around the spam filter.
>  
> -Every single email will be analyzed and gets a spam score
> +Every single email will be analyzed and have a spam score
>  assigned. The system attempts to optimize the efficiency of the rules
>  that are run in terms of minimizing the number of false positives and
>  false negatives.
> @@ -631,7 +631,7 @@ email if it is ham or spam (or virus). Good emails are delivered to
>  the inbox and spam messages are moved into the spam quarantine.
>  
>  The system can be configured to send daily reports to inform users
> -about the personal spam messages received the last day. The report is
> +about personal spam messages received in the last day. The report is
>  only sent if there are new messages in the quarantine.
>  
>  Some options are only available in the config file `/etc/pmg/pmg.conf`,
> @@ -661,7 +661,7 @@ slightly adjusting the score of a particular rule. Two examples:
>  * Your system tags many legitimate mails from a partner organization as spam,
>    because the organization has a policy that each mail has to start with
>    'Dear madam or sir' (generating 1.9 points through the rule
> -  'DEAR_SOMETHING'). By setting the score of this rule to 0 you can disable
> +  'DEAR_SOMETHING'). By setting the score of this rule to 0, you can disable
>    it completely.
>  
>  The system logs all the rules which a particular mail hits. Analyzing the logs can
> @@ -670,7 +670,7 @@ lead to finding such a pattern in your environment.
>  You can adjust the score of a rule by creating a new 'Custom Rule Score' entry
>  in the GUI.
>  
> -NOTE: In general it is strongly recommended to not make large changes to the
> +NOTE: In general, it is strongly recommended not to make large changes to the
>  default scores.
>  
>  
> @@ -701,7 +701,7 @@ endif::manvolnum[]
>  
>  Please note that the virus signature database is automatically
>  updated. You can see the database status in the GUI, and also
> -trigger manual updates there.
> +trigger manual updates from there.
>  
>  
>  [[pmgconfig_clamav_quarantine]]
> @@ -712,9 +712,9 @@ ifndef::manvolnum[]
>  [thumbnail="pmg-gui-virusquar-options.png", big=1]
>  endif::manvolnum[]
>  
> -Indentified virus mails are automatically moved to the virus
> -quarantine. The administrator can view these mails using the GUI, and
> -choose to deliver them in case of false positives. {pmg} does not notify
> +Identified virus mails are automatically moved to the virus
> +quarantine. The administrator can view these mails from the GUI, and
> +choose to deliver them, in case of false positives. {pmg} does not notify
>  individual users about received virus mails.
>  
>  Virus quarantine related settings are saved to subsection 'virusquar'
> @@ -728,14 +728,14 @@ Custom SpamAssassin configuration
>  
>  This is only for advanced users. {spamassassin}'s rules and their associated
>  scores get updated regularly and are trained on a huge corpus, which gets
> -classified by experts. In most cases adding a rule for matching a particular
> +classified by experts. In most cases, adding a rule for matching a particular
>  keyword is the wrong approach, leading to many false positives. Usually bad
>  detection rates are better addressed by properly setting up DNS than by adding
>  a custom rule - watch out for matches to 'URIBL_BLOCKED' in the logs or
>  spam-headers - see the {spamassassin_dnsbl}.
>  
> -To add or change the Proxmox {spamassassin} configuration please login to the
> -console via SSH. Change to the `/etc/mail/spamassassin/` directory. In this
> +To add or change the Proxmox {spamassassin} configuration, log in to the
> +console via SSH and change to the `/etc/mail/spamassassin/` directory. In this
>  directory there are several files (`init.pre`, `local.cf`, ...) - do not change
>  them, as `init.pre`, `v310.pre`, `v320.pre`, `local.cf` will be overwritten by
>  the xref:pmgconfig_template_engine[template engine], while the others can
> @@ -752,7 +752,7 @@ to use the correct {spamassassin} syntax, and test it with:
>  If you run a cluster, the `custom.cf` file is synchronized from the
>  master node to all cluster members automatically.
>  
> -To adjust the score assigned to a particular rule you
> +To adjust the score assigned to a particular rule, you
>  can also use the xref:pmgconfig_spamdetector_customscores[Custom Rule Score]
>  settings in the GUI.
>  
> @@ -774,25 +774,25 @@ treatment of an email. Its input is passed via two CLI arguments:
>  * the 'queue-file-name' - a filename, which contains the complete email as
>    rfc822/eml file
>  
> -The expected output need to be printed on STDOUT and consists of two lines:
> +The expected output needs to be printed to STDOUT and consists of two lines:
>  
>  * the 'api-version' (currently 'v1') - see above
>  
>  * one of the following 3 results:
> -** 'OK' - email is ok
> +** 'OK' - email is OK
>  ** 'VIRUS: <virusdescription>' - email is treated as if it contained a virus
>      (the virus description is logged and added to the email's headers)
>  ** 'SCORE: <number>' - <number> is added (negative numbers are also possible)
>      to the email's spamscore
>  
> -The check is run with a 5 minute timeout - if it is exceeded the check
> +The check is run with a 5 minute timeout - if this is exceeded, the check
>  executable is killed and the email is treated as OK.
>  
>  All output written to STDERR by the check is written with priority 'err' to the
>  journal/mail.log.
>  
> -A simple sample script following the API (and yielding a random result) for
> -reference:
> +Below is a simple sample script following the API (and yielding a random result)
> +for reference:
>  
>  ----
>  #!/bin/sh
> @@ -869,7 +869,7 @@ There are four roles:
>  
>  Administrator::
>  
> -Is allowed to manage settings of {pmg}, except some tasks like network
> +Is allowed to manage settings of {pmg}, excluding some tasks like network
>  configuration and upgrading.
>  
>  Quarantine manager::
> @@ -886,17 +886,17 @@ Helpdesk::
>  
>  Combines permissions of the 'Auditor' and the 'Quarantine Manager' role.
>  
> -In addition there is always the 'root' user, which is used to perform special
> +In addition, there is always the 'root' user, which is used to perform special
>  system administrator tasks, such as upgrading a host or changing the network
>  configuration.
>  
> -NOTE: Only pam users are able to login via the webconsole and ssh, which the
> -users created with the web interface are not. Those users are created for {pmg}
> -administration only.
> +NOTE: Only PAM users are able to log in via the web interface and ssh, while the
> +users created through the web interface are not. Those users are created for
> +{pmg} administration only.
>  
>  Local user related settings are saved in `/etc/pmg/user.conf`.
>  
> -For details of the fields see xref:pmg_user_configuration_file[user.conf]
> +For details on the fields, see xref:pmg_user_configuration_file[user.conf]
>  
>  [[pmgconfig_ldap]]
>  LDAP/Active Directory
> @@ -912,7 +912,7 @@ Creating a profile requires (at least) the following:
>  * profile name
>  * protocol (LDAP or LDAPS; LDAPS is recommended)
>  * at least one server
> -* a user and password (if your server does not support anonymous binds)
> +* a username and password (if your server does not support anonymous binds)
>  
>  All other fields should work with the defaults for most setups, but can be
>  used to customize the queries.
> @@ -924,21 +924,21 @@ Bind user
>  ^^^^^^^^^
>  
>  It is highly recommended that the user which you use for connecting to the
> -LDAP server only has the permission to query the server. For LDAP servers
> +LDAP server only has permission to query the server. For LDAP servers
>  (for example OpenLDAP or FreeIPA), the username has to be of a format like
> -'uid=username,cn=users,cn=accounts,dc=domain' , where the specific fields are
> -depending on your setup. For Active Directory servers, the format should be
> +'uid=username,cn=users,cn=accounts,dc=domain', where the specific fields
> +depend on your setup. For Active Directory servers, the format should be
>  like 'username@domain' or 'domain\username'.
>  
>  Sync
>  ^^^^
>  
> -{pmg} synchronizes the relevant user and group info periodically, so that
> -the information is available in a fast manner, even when the LDAP/AD server
> -is temporarily not accessible.
> +{pmg} synchronizes the relevant user and group information periodically, so that
> +the information is quickly available, even when the LDAP/AD server is
> +temporarily inaccessible.
>  
>  After a successful sync, the groups and users should be visible on the web
> -interface. After that, you can create rules targeting LDAP users and groups.
> +interface. Following this, you can create rules targeting LDAP users and groups.
>  
>  
>  [[pmgconfig_fetchmail]]
> @@ -947,15 +947,15 @@ Fetchmail
>  
>  [thumbnail="pmg-gui-fetchmail-config.png", big=1]
>  
> -Fetchmail is utility for polling and forwarding emails. You can define
> +Fetchmail is a utility for polling and forwarding emails. You can define
>  email accounts, which will then be fetched and forwarded to the email
>  address you defined.
>  
>  You have to add an entry for each account/target combination you want to
> -fetch and forward. Those will then be regularly polled and forwarded,
> +fetch and forward. These will then be regularly polled and forwarded,
>  according to your configuration.
>  
> -The API and web interface offer following configuration options:
> +The API and web interface offer the following configuration options:
>  
>  include::fetchmail.conf.5-opts.adoc[]
>