From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id AC76872435 for ; Tue, 15 Jun 2021 14:12:04 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A1B512E1B5 for ; Tue, 15 Jun 2021 14:11:34 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 5CDCE2E1A8 for ; Tue, 15 Jun 2021 14:11:31 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 3A8E2437CA for ; Tue, 15 Jun 2021 14:11:31 +0200 (CEST) Date: Tue, 15 Jun 2021 14:11:27 +0200 From: Stoiko Ivanov To: Dylan Whyte Cc: pmg-devel@lists.proxmox.com Message-ID: <20210615141127.1427d443@rosa.proxmox.com> In-Reply-To: <20210615103605.27739-1-d.whyte@proxmox.com> References: <20210615103605.27739-1-d.whyte@proxmox.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.548 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DEAR_SOMETHING 1.973 Contains 'Dear (something)' KAM_ASCII_DIVIDERS 0.8 Spam that uses ascii formatting tricks KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [custom.cf, interfaces.new, pmg-authkey.pub] Subject: Re: [pmg-devel] applied-series: [PATCH pmg-docs 1/5] configuration management: language fix-up X-BeenThere: pmg-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Mail Gateway development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 12:12:04 -0000 applied the series. huge thanks for the effort! On Tue, 15 Jun 2021 12:36:01 +0200 Dylan Whyte wrote: > this fixes wording, spelling, grammar, etc. for the chapter > 'configuration management' >=20 > Signed-off-by: Dylan Whyte > --- > pmgconfig.adoc | 256 ++++++++++++++++++++++++------------------------- > 1 file changed, 128 insertions(+), 128 deletions(-) >=20 > diff --git a/pmgconfig.adoc b/pmgconfig.adoc > index 67c1bd8..1ae80c3 100644 > --- a/pmgconfig.adoc > +++ b/pmgconfig.adoc > @@ -27,15 +27,15 @@ endif::manvolnum[] > =20 > {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`. > =20 > 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. > =20 > 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. > =20 > =20 > @@ -45,9 +45,8 @@ Configuration files overview > `/etc/network/interfaces`:: > =20 > 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. > =20 > `/etc/resolv.conf`:: > =20 > @@ -56,7 +55,7 @@ to create the FQDN and domain name used in the postfix = configuration. > =20 > `/etc/hostname`:: > =20 > -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. > =20 > `/etc/hosts`:: > @@ -65,7 +64,8 @@ Static table lookup for hostnames. > =20 > `/etc/pmg/pmg.conf`:: > =20 > -Stores common administration options, i.e. the spam and mail proxy setup. > +Stores common administration options, such as the spam and mail proxy > +configuration. > =20 > `/etc/pmg/cluster.conf`:: > =20 > @@ -120,15 +120,15 @@ Keys and Certificates > =20 > `/etc/pmg/pmg-api.pem`:: > =20 > -Key and certificate (combined) used be the HTTPs server (API). > +Key and certificate (combined) used by the HTTPS server (API). > =20 > `/etc/pmg/pmg-authkey.key`:: > =20 > -Privat key use to generate authentication tickets. > +Private key used to generate authentication tickets. > =20 > `/etc/pmg/pmg-authkey.pub`:: > =20 > -Public key use to verify authentication tickets. > +Public key used to verify authentication tickets. > =20 > `/etc/pmg/pmg-csrf.key`:: > =20 > @@ -147,20 +147,20 @@ Key for DKIM signing mails with selector ''. > Service Configuration Templates > ------------------------------- > =20 > -{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. > =20 > -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. > =20 > -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: > =20 > ---- > @@ -173,9 +173,9 @@ pmg.admin.advfilter =3D 1 > ... > ---- > =20 > -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 tem= plate, > +or when you directly edit configuration files: > =20 > ---- > # pmgconfig sync --restart 1 > @@ -192,28 +192,28 @@ synced from the master node to all cluster members. > White- and Blacklists > --------------------- > =20 > -{pmg} has multiple white- and blacklists. It differentiates between the= =20 > -xref:pmgconfig_mailproxy_options[SMTP Whitelist]. The rule-based whiteli= st > +{pmg} has multiple white- and blacklists. It differentiates between the > +xref:pmgconfig_mailproxy_options[SMTP Whitelist], the rule-based whiteli= st > 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 ru= le-based > blacklist and the user blacklist. > =20 > SMTP Whitelist > ~~~~~~~~~~~~~~ > =20 > The xref:pmgconfig_mailproxy_options[SMTP Whitelist] is responsible for = disabling > -greylisting as well as SPF and DNSBL checks. These are done during the S= MTP > +greylisting, as well as SPF and DNSBL checks. These are done during the = SMTP > dialogue. > =20 > Rule-based White-/Blacklist > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > =20 > The xref:chapter_mailfilter[rule-based white- and blacklists] are predef= ined > -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 actio= n 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 ove= r 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 assi= gned > +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 pri= ority > +over the whitelist rule and spam checks. > =20 > 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 wh= itelist, > the result of the spam analysis will be discarded for that recipient. Th= is can > -help the mail being accepted, but it still depends on the other rules wh= at > -happens next. In the default setup this results in the mail being accept= ed 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 accept= ed for > this recipient. > =20 > -For mail addresses on a user's blacklist the spam score will be increase= d 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 quar= antined > +For mail addresses on a user's blacklist, the spam score will be increas= ed 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 qua= rantined > (spam score of 3 or higher). > =20 > [[pmgconfig_systemconfig]] > @@ -241,13 +241,12 @@ ifndef::manvolnum[] > [thumbnail=3D"pmg-gui-network-config.png", big=3D1] > endif::manvolnum[] > =20 > -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. > =20 > 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'. > =20 > .Example network setup '/etc/network/interfaces' > @@ -282,7 +281,7 @@ ifndef::manvolnum[] > endif::manvolnum[] > =20 > =20 > -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: > =20 > include::pmg.admin-conf-opts.adoc[] > @@ -301,7 +300,7 @@ ifndef::manvolnum[] > [thumbnail=3D"pmg-gui-mailproxy-relaying.png", big=3D1] > endif::manvolnum[] > =20 > -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: > =20 > include::pmg.mail-relaying-conf-opts.adoc[] > @@ -314,7 +313,7 @@ ifndef::manvolnum[] > [thumbnail=3D"pmg-gui-mailproxy-relaydomains.png", big=3D1] > endif::manvolnum[] > =20 > -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. > =20 > @@ -327,7 +326,7 @@ ifndef::manvolnum[] > [thumbnail=3D"pmg-gui-mailproxy-ports.png", big=3D1] > endif::manvolnum[] > =20 > -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: > =20 > include::pmg.mail-ports-conf-opts.adoc[] > @@ -341,7 +340,7 @@ ifndef::manvolnum[] > [thumbnail=3D"pmg-gui-mailproxy-options.png", big=3D1] > endif::manvolnum[] > =20 > -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: > =20 > include::pmg.mail-options-conf-opts.adoc[] > @@ -351,9 +350,9 @@ include::pmg.mail-options-conf-opts.adoc[] > Before and After Queue scanning > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > =20 > -Scanning email can happen at two different stages of mail-processing: > +Email scanning can happen at two different stages of mail-processing: > =20 > -* Before-queue filtering: During the SMTP Session, after the complete me= ssage > +* Before-queue filtering: During the SMTP session, after the complete me= ssage > has been received (after the 'DATA' command). > =20 > * After-queue filtering: After initially accepting the mail and putting = it on > @@ -361,37 +360,37 @@ Scanning email can happen at two different stages o= f mail-processing: > =20 > Before-queue filtering has the advantage that the system can reject a ma= il (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 advantag= e 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-ca= lled > +sender address. Sending out a notification in this situation leads to so= -called > 'backscatter' mail, which might cause your server to get listed as spamm= ing on > RBLs (Real-time Blackhole List). > =20 > 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 addres= ses 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 ma= il 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 Blackl= ist' > -feature. > - > -If the resulting action of the rule system is the same for all recipient= s {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 other= s. This > +can be due to a complicated rule setup, or if your users use the 'User W= hite- > +and Blacklist' feature. > + > +If the resulting action of the rule system is the same for all recipient= s, {pmg} > +responds accordingly, if configured for before-queue filtering (sending = '554' > for a blocked mail and '250' for an accepted or quarantined mail). If so= me > mailboxes accept the mail and some reject it, the system has to accept t= he mail. > =20 > Whether {pmg} notifies the sender that delivery failed for some recipien= ts 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 prev= ents > +'/etc/pmg/pmg.conf'. If enabled, an NDR is sent. Keeping this disabled p= revents > NDRs being sent to the (possibly forged) sender and thus minimizes the c= hance > -of getting your IP listed on a RBL. However in certain environments it c= an 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. > =20 > -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 blo= ck the > mail, since the mail already got accepted before being analyzed. > =20 > @@ -405,10 +404,10 @@ Greylisting > =20 > Greylisting is a technique for preventing unwanted messages from reachin= g 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 g= et > -sent out by software, which has no provisioning for queueing, these mail= s 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. > =20 > The downside of greylisting is the delay introduced by the initial defer= ral of > @@ -419,24 +418,24 @@ coming from a source for a recipient, which have pa= ssed greylisting in the > past are directly passed on: For each email the triple ' 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 furth= er > +timestamp for that triple is updated, and the email is accepted for furt= her > processing. > =20 > -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 de= lay > introduced by enabling greylisting. A triple is removed after a longer p= eriod > -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: > =20 > * 2 days for the retry of the first delivery > =20 > -* 36 days for known triples > +* 36 days for a known triple > =20 > -Mails with an empty envelope-sender are always delayed. > +Mails with an empty envelope sender are always delayed. > =20 > 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 sing= le 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 I= Ps of > +the same provider, the triples store a network ('cidr') instead of a sin= gle 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 I= Pv4 > and 'greylistmask6' for IPv6 respectively. > @@ -451,13 +450,13 @@ ifndef::manvolnum[] > endif::manvolnum[] > =20 > 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. > =20 > 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'. > =20 > =20 > [[pmgconfig_mailproxy_networks]] > @@ -471,8 +470,8 @@ endif::manvolnum[] > You can add additional internal (trusted) IP networks or hosts. All hos= ts in > this list are allowed to relay. > =20 > -NOTE: Hosts in the same subnet with Proxmox can relay by default and it= =E2=80=99s not > -needed to add them in this list. > +NOTE: Hosts in the same subnet as {pmg} can relay by default and don't n= eed to > +be added to this list. > =20 > =20 > [[pmgconfig_mailproxy_tls]] > @@ -490,24 +489,24 @@ generates a new self signed certificate for you (`/= etc/pmg/pmg-tls.pem`). > =20 > {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. > =20 > You can set a different TLS policy per destination. A destination is eit= her a > -remote domain or a next-hop destination as specified in `/etc/pmg/transp= ort`. > +remote domain or a next-hop destination, as specified in `/etc/pmg/trans= port`. > 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. > =20 > Enable TLS logging:: > =20 > -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. > =20 > Add TLS received header:: > =20 > 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. > =20 > Those settings are saved to subsection 'mail' in `/etc/pmg/pmg.conf`, > @@ -526,13 +525,13 @@ endif::manvolnum[] > =20 > DomainKeys Identified Mail (DKIM) Signatures (see {dkim_rfc}) is a metho= d to > cryptographically authenticate a mail as originating from a particular d= omain. > -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` he= ader of > the mail. The 'selector' (a short identifier chosen by you, used to iden= tify > which system and private key were used for signing) is also included in = the > `DKIM-Signature` header. > =20 > -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 doma= in, > each used by a system which sends email from your domain, without the ne= ed to > @@ -540,10 +539,10 @@ share the private key. > =20 > {pmg} verifies DKIM Signatures for inbound mail in the Spam Filter by de= fault. > =20 > -Additionally it supports conditionally signing outbound mail if configur= ed. > -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-sha25= 6 is > -used as signing algorithm. > +Additionally, it supports conditionally signing outbound mail, if config= ured. > +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. > =20 > 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 b= y {pmg} by clicking on the > Sign all Outgoing Mail:: > =20 > 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` ot= herwise. > +listed in `/etc/pmg/dkim/domains`, if it exists and `/etc/pmg/domains` > +otherwise. > =20 > -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: > =20 > 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, ...) > =20 > -DNSBL checks are done by `postscreen` which works on IP addresses and ne= tworks. > +DNSBL checks are done by `postscreen`, which works on IP addresses and n= etworks. > This means it can only make use of the `IP Address` and `IP Network` ent= ries. > =20 > -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 s= ervice > for you) you should always add those servers here. > =20 > 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. > =20 > -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 ar= e delivered to > the inbox and spam messages are moved into the spam quarantine. > =20 > 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. > =20 > 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. Tw= o 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 disa= ble > + 'DEAR_SOMETHING'). By setting the score of this rule to 0, you can dis= able > it completely. > =20 > The system logs all the rules which a particular mail hits. Analyzing th= e 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. > =20 > -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 t= o the > default scores. > =20 > =20 > @@ -701,7 +701,7 @@ endif::manvolnum[] > =20 > 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. > =20 > =20 > [[pmgconfig_clamav_quarantine]] > @@ -712,9 +712,9 @@ ifndef::manvolnum[] > [thumbnail=3D"pmg-gui-virusquar-options.png", big=3D1] > endif::manvolnum[] > =20 > -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. > =20 > Virus quarantine related settings are saved to subsection 'virusquar' > @@ -728,14 +728,14 @@ Custom SpamAssassin configuration > =20 > This is only for advanced users. {spamassassin}'s rules and their associ= ated > 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 partic= ular > +classified by experts. In most cases, adding a rule for matching a parti= cular > 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}. > =20 > -To add or change the Proxmox {spamassassin} configuration please login t= o the > -console via SSH. Change to the `/etc/mail/spamassassin/` directory. In t= his > +To add or change the Proxmox {spamassassin} configuration, log in to the > +console via SSH and change to the `/etc/mail/spamassassin/` directory. I= n 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 overwrit= ten 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. > =20 > -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 Sc= ore] > settings in the GUI. > =20 > @@ -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 > =20 > -The expected output need to be printed on STDOUT and consists of two lin= es: > +The expected output needs to be printed to STDOUT and consists of two li= nes: > =20 > * the 'api-version' (currently 'v1') - see above > =20 > * one of the following 3 results: > -** 'OK' - email is ok > +** 'OK' - email is OK > ** 'VIRUS: ' - email is treated as if it contained a v= irus > (the virus description is logged and added to the email's headers) > ** 'SCORE: ' - is added (negative numbers are also poss= ible) > to the email's spamscore > =20 > -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. > =20 > All output written to STDERR by the check is written with priority 'err'= to the > journal/mail.log. > =20 > -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: > =20 > ---- > #!/bin/sh > @@ -869,7 +869,7 @@ There are four roles: > =20 > Administrator:: > =20 > -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. > =20 > Quarantine manager:: > @@ -886,17 +886,17 @@ Helpdesk:: > =20 > Combines permissions of the 'Auditor' and the 'Quarantine Manager' role. > =20 > -In addition there is always the 'root' user, which is used to perform sp= ecial > +In addition, there is always the 'root' user, which is used to perform s= pecial > system administrator tasks, such as upgrading a host or changing the net= work > configuration. > =20 > -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 fo= r {pmg} > -administration only. > +NOTE: Only PAM users are able to log in via the web interface and ssh, w= hile the > +users created through the web interface are not. Those users are created= for > +{pmg} administration only. > =20 > Local user related settings are saved in `/etc/pmg/user.conf`. > =20 > -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.con= f] > =20 > [[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 bin= ds) > =20 > 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 > ^^^^^^^^^ > =20 > It is highly recommended that the user which you use for connecting to t= he > -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 li= ke > -'uid=3Dusername,cn=3Dusers,cn=3Daccounts,dc=3Ddomain' , where the specif= ic fields are > -depending on your setup. For Active Directory servers, the format should= be > +'uid=3Dusername,cn=3Dusers,cn=3Daccounts,dc=3Ddomain', where the specifi= c fields > +depend on your setup. For Active Directory servers, the format should be > like 'username@domain' or 'domain\username'. > =20 > Sync > ^^^^ > =20 > -{pmg} synchronizes the relevant user and group info periodically, so that > -the information is available in a fast manner, even when the LDAP/AD ser= ver > -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. > =20 > After a successful sync, the groups and users should be visible on the w= eb > -interface. After that, you can create rules targeting LDAP users and gro= ups. > +interface. Following this, you can create rules targeting LDAP users and= groups. > =20 > =20 > [[pmgconfig_fetchmail]] > @@ -947,15 +947,15 @@ Fetchmail > =20 > [thumbnail=3D"pmg-gui-fetchmail-config.png", big=3D1] > =20 > -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. > =20 > 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. > =20 > -The API and web interface offer following configuration options: > +The API and web interface offer the following configuration options: > =20 > include::fetchmail.conf.5-opts.adoc[] > =20