10 pmgconfig - Proxmox Mail Gateway Configuration Management Toolkit
16 include::pmgconfig.1-synopsis.adoc[]
23 Configuration Management
24 ========================
28 {pmg} is usually configured using the web-based Graphical User
29 Interface (GUI), but it is also possible to directly edit the
30 configuration files, use the REST API over 'https'
31 or the command line tool `pmgsh`.
33 The command line tool `pmgconfig` is used to simplify some common
34 configuration tasks, i.e. to generate cerificates and to rewrite
35 service configuration files.
37 NOTE: We use a Postgres database to store mail filter rules and
38 statistic data. See chapter xref:chapter_pmgdb[Database Management]
42 Configuration files overview
43 ----------------------------
45 `/etc/network/interfaces`::
47 Network setup. We never modify this file directly. Instead, we write
48 changes to `/etc/network/interfaces.new`. When you reboot, we rename
49 the file to `/etc/network/interfaces`, so the changes are applied
54 DNS search domain and nameserver setup.
58 The system's host name.
62 Static table lookup for hostnames.
66 Stores common administration options, i.e. the spam and mail proxy setup.
68 `/etc/pmg/cluster.conf`::
74 The list of relay domains.
76 `/etc/pmg/dkim/domains`::
78 The list of domains for outbound DKIM signing.
80 `/etc/pmg/fetchmailrc`::
82 Fetchmail configuration (POP3 and IMAP setup).
84 `/etc/pmg/ldap.conf`::
88 `/etc/pmg/mynetworks`::
90 List of local (trusted) networks.
92 `/etc/pmg/subscription`::
94 Stores your subscription key and status.
96 `/etc/pmg/tls_policy`::
98 TLS policy for outbound connections.
100 `/etc/pmg/transports`::
102 Message delivery transport setup.
104 `/etc/pmg/user.conf`::
106 GUI user configuration.
108 `/etc/mail/spamassassin/custom.cf`::
110 Custom {spamassassin} setup.
112 `/etc/mail/spamassassin/pmg-scores.cf`::
114 Custom {spamassassin} rule scores.
116 Keys and Certificates
117 ---------------------
119 `/etc/pmg/pmg-api.pem`::
121 Key and certificate (combined) used be the HTTPs server (API).
123 `/etc/pmg/pmg-authkey.key`::
125 Privat key use to generate authentication tickets.
127 `/etc/pmg/pmg-authkey.pub`::
129 Public key use to verify authentication tickets.
131 `/etc/pmg/pmg-csrf.key`::
133 Internally used to generate CSRF tokens.
135 `/etc/pmg/pmg-tls.pem`::
137 Key and certificate (combined) to encrypt mail traffic (TLS).
139 `/etc/pmg/dkim/<selector>.private`::
141 Key for DKIM signing mails with selector '<selector>'.
144 [[pmgconfig_template_engine]]
145 Service Configuration Templates
146 -------------------------------
148 {pmg} uses various services to implement mail filtering, for example
149 the {postfix} Mail Transport Agent (MTA), the {clamav} antivirus
150 engine and the Apache {spamassassin} project. These services use
151 separate configuration files, so we need to rewrite those files when
152 configuration is changed.
154 We use a template based approach to generate those files. The {tts} is
155 a well known, fast and flexible template processing system. You can
156 find the default templates in `/var/lib/pmg/templates/`. Please do not
157 modify them directly, because your modification would get lost on the
158 next update. Instead, copy the template you wish to change to
159 `/etc/pmg/templates/`, then apply your changes there.
161 Templates can access any configuration setting, and you can use the
162 `pmgconfig dump` command to get a list of all variable names:
167 dns.domain = yourdomain.tld
169 ipconfig.int_ip = 192.168.2.127
170 pmg.admin.advfilter = 1
174 The same tool is used to force regeneration of all template based
175 configuration files. You need to run that after modifying a template,
176 or when you directly edit configuration files
179 # pmgconfig sync --restart 1
182 The above command also restarts services if the underlying configuration
183 files are changed. Please note that this is automatically done when
184 you change the configuration using the GUI or API.
186 NOTE: Modified templates from `/etc/pmg/templates/` are automatically
187 synced from the master node to all cluster members.
190 [[pmgconfig_systemconfig]]
198 [thumbnail="pmg-gui-network-config.png", big=1]
201 Normally the network and time is already configured when you visit the
202 GUI. The installer asks for those settings and sets up the correct
205 The default setup uses a single Ethernet adapter and static IP
206 assignment. The configuration is stored at '/etc/network/interfaces',
207 and the actual network setup is done the standard Debian way using
210 .Example network setup '/etc/network/interfaces'
212 source /etc/network/interfaces.d/*
215 iface lo inet loopback
218 iface ens18 inet static
219 address 192.168.2.127
220 netmask 255.255.240.0
226 Many tests to detect SPAM mails use DNS queries, so it is important to
227 have a fast and reliable DNS server. We also query some publicly
228 available DNS Blacklists. Most of them apply rate limits for clients,
229 so they simply will not work if you use a public DNS server (because
230 they are usually blocked). We recommend to use your own DNS server,
231 which needs to be configured in 'recursive' mode.
238 [thumbnail="pmg-gui-system-options.png", big=1]
242 Those settings are saved to subsection 'admin' in `/etc/pmg/pmg.conf`,
243 using the following configuration keys:
245 include::pmg.admin-conf-opts.adoc[]
248 Mail Proxy Configuration
249 ------------------------
251 [[pmgconfig_mailproxy_relaying]]
256 [thumbnail="pmg-gui-mailproxy-relaying.png", big=1]
259 Those settings are saved to subsection 'mail' in `/etc/pmg/pmg.conf`,
260 using the following configuration keys:
262 include::pmg.mail-relaying-conf-opts.adoc[]
264 [[pmgconfig_mailproxy_relay_domains]]
269 [thumbnail="pmg-gui-mailproxy-relaydomains.png", big=1]
272 List of relayed mail domains, i.e. what destination domains this
273 system will relay mail to. The system will reject incoming mails to
277 [[pmgconfig_mailproxy_ports]]
282 [thumbnail="pmg-gui-mailproxy-ports.png", big=1]
285 Those settings are saved to subsection 'mail' in `/etc/pmg/pmg.conf`,
286 using the following configuration keys:
288 include::pmg.mail-ports-conf-opts.adoc[]
291 [[pmgconfig_mailproxy_options]]
296 [thumbnail="pmg-gui-mailproxy-options.png", big=1]
299 Those settings are saved to subsection 'mail' in `/etc/pmg/pmg.conf`,
300 using the following configuration keys:
302 include::pmg.mail-options-conf-opts.adoc[]
305 [[pmgconfig_mailproxy_before_after_queue]]
306 Before and After Queue scanning
307 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
309 Scanning email can happen at two different stages of mail-processing:
311 * Before-queue filtering: During the SMTP Session, after the complete message
312 has been received (after the 'DATA' command).
314 * After-queue filtering: After initially accepting the mail and putting it on
315 a queue for further processing.
317 Before-queue filtering has the advantage that the system can reject a mail (by
318 sending a permanent reject code '554'), and leave the task of notifying the
319 original sender to the other mailserver. This is of particular advantage if
320 the processed mail is a spam message or contains a virus and has a forged
321 sender-address. Sending out a notification in this situation leads so-called
322 'backscatter' mail, which might cause your server to get listed as spamming on
323 RBLs (Real-time Blackhole List).
325 After-queue filtering has the advantage of providing faster delivery of
326 mails for the sending servers, since queueing mails is much faster than
327 analyzing it for spam and viruses.
329 If a mail is addressed to multiple recipients (e.g. when multiple addresses are
330 subscribed to the same mailing list) the situation is more complicated: Your
331 mailserver can only reject or accept the mail for all recipients, after having
332 received the complete message, while your rule setup might accept the mail for
333 part of the recipients and reject it for others. This can be due to a
334 complicated rule setup, or if your users use the 'User White- and Blacklist'
337 If the resulting action of the rule system is the same for all recipients {pmg}
338 responds accordingly if configured for before queue filtering (sending '554'
339 for a blocked mail and '250' for an accepted or quarantined mail). If some
340 mailboxes accept the mail and some reject it, the system has to accept the mail.
342 Whether {pmg} notifies the sender that delivery failed for some recipients by
343 sending a non-delivery report, depends on the 'ndr_on_block' setting in
344 '/etc/pmg/pmg.conf'. If enabled an NDR is sent. Keeping it disabled prevents
345 NDRs being sent to the (possibly forged) sender and thus minimizes the chance
346 of getting your IP listed on a RBL. However in certain environments it can be
347 unacceptable not to inform the sender about a rejected mail.
349 The setting has the same effect if after queue filtering is configured, with
350 the exception that an NDR is always sent out, even if all recipients block the
351 mail, since the mail already got accepted before being analyzed.
353 The details of integrating the mail proxy with {postfix} in both setups are
354 explained in {postfix_beforequeue} and {postfix_afterqueue} respectively.
357 [[pmgconfig_mailproxy_greylisting]]
361 Greylisting is a technique for preventing unwanted messages from reaching the
362 resource intensive stages of content analysis (virus detection and spam
363 detection): By initially replying with a temporary failure code ('450') to
364 each new email, the {pmg} tells the sending server that it should queue the
365 mail and retry delivery at a later moment. Since certain kinds of spam get
366 sent out by software, which has no provisioning for queueing, these mails are
367 dropped without reaching {pmg} or your mailbox.
369 The downside of greylisting is the delay introduced by the initial deferral of
370 the email, which usually amounts to less than 30 minutes.
372 In order to prevent unnecessary delays in delivery from known sources, emails
373 coming from a source for a recipient, which have passed greylisting in the
374 past are directly passed on: For each email the triple '<sender network,
375 sender email, recipient email>' is stored in a list, along with the time when
376 delivery was attempted. If an email fits an already existing triple, the
377 timestamp for that triple is updated and the email is accepted for further
380 As long as a sender and recipient do communicate frequently there is no delay
381 introduced by enabling greylisting. A triple is removed after a longer period
382 of time, when no mail fitting that triple has been seen. The timeouts in {pmg}
385 * 2 days for the retry of the first delivery
387 * 36 days for known triples
389 Mails with an empty envelope-sender are always delayed.
391 Some email service providers send out emails for one domain from multiple
392 servers. To prevent delays due to an email coming in from 2 separate IPs of
393 the same provider the triples store a network ('cidr') instead of a single IP.
394 For certain large providers the default network size might be too small. You
395 can configure the netmask applied to an IP for the greylist lookup in
396 '/etc/pmg/pmg.conf' or in the GUI with the settings 'greylistmask' for IPv4
397 and 'greylistmask6' for IPv6 respectively.
400 [[pmgconfig_mailproxy_transports]]
405 [thumbnail="pmg-gui-mailproxy-transports.png", big=1]
408 You can use {pmg} to send emails to different internal
409 email servers. For example you can send emails addressed to
410 domain.com to your first email server, and emails addressed to
411 subdomain.domain.com to a second one.
413 You can add the IP addresses, hostname, transport protocol (smtp/lmtp),
414 transport ports and mail domains (or just single email addresses)
415 of your additional email servers. When transport protocol is set to `lmtp`,
416 the option 'Use MX' is useless and will be automatically set to 'No'.
419 [[pmgconfig_mailproxy_networks]]
424 [thumbnail="pmg-gui-mailproxy-networks.png", big=1]
427 You can add additional internal (trusted) IP networks or hosts.
428 All hosts in this list are allowed to relay.
430 NOTE: Hosts in the same subnet with Proxmox can relay by default and
431 it’s not needed to add them in this list.
434 [[pmgconfig_mailproxy_tls]]
439 [thumbnail="pmg-gui-mailproxy-tls.png", big=1]
442 Transport Layer Security (TLS) provides certificate-based
443 authentication and encrypted sessions. An encrypted session protects
444 the information that is transmitted with SMTP mail. When you activate
445 TLS, {pmg} automatically generates a new self signed
446 certificate for you (`/etc/pmg/pmg-tls.pem`).
448 {pmg} uses opportunistic TLS encryption by default. The SMTP transaction is
449 encrypted if the 'STARTTLS' ESMTP feature is supported by the remote
450 server. Otherwise, messages are sent in the clear.
452 You can set a different TLS policy per destination. A destination is either a
453 remote domain or a next-hop destination as specified in `/etc/pmg/transport`.
454 This can be used if you need to prevent email delivery without
455 encryption, or to work around a broken 'STARTTLS' ESMTP implementation. See
456 {postfix_tls_readme} for details on the supported policies.
460 To get additional information about SMTP TLS activity you can enable
461 TLS logging. That way information about TLS sessions and used
462 certificates is logged via syslog.
464 Add TLS received header::
466 Set this option to include information about the protocol and cipher
467 used as well as the client and issuer CommonName into the "Received:"
470 Those settings are saved to subsection 'mail' in `/etc/pmg/pmg.conf`,
471 using the following configuration keys:
473 include::pmg.mail-tls-conf-opts.adoc[]
476 [[pmgconfig_mailproxy_dkim]]
481 [thumbnail="pmg-gui-mailproxy-dkim.png", big=1]
484 DomainKeys Identified Mail (DKIM) Signatures (see {dkim_rfc}) is a method to
485 cryptographically authenticate a mail as originating from a particular domain.
486 Before sending the mail a hash over certain header fields and the body is
487 computed, signed with a private key and added in the `DKIM-Signature` header of
488 the mail. The 'selector' (a short identifier chosen by you, used to identify
489 which system and private key were used for signing) is also included in the
490 `DKIM-Signature` header.
492 The verification is done by the receiver: The public key is fetched
493 via DNS TXT lookup for `yourselector._domainkey.yourdomain.example` and used
494 for verifying the hash. You can publish multiple selectors for your domain,
495 each used by a system which sends email from your domain, without the need to
496 share the private key.
498 {pmg} verifies DKIM Signatures for inbound mail in the Spam Filter by default.
500 Additionally it supports conditionally signing outbound mail if configured.
501 It uses one private key and selector per PMG deployment (all nodes in a cluster
502 use the same key). The key has a minimal size of 1024 bits and rsa-sha256 is
503 used as signing algorithm.
505 The headers included in the signature are taken from the list of
506 `Mail::DKIM::Signer`. Additionally `Content-Type` (if present), `From`, `To`,
507 `CC`, `Reply-To` and `Subject` get oversigned.
509 You can either sign all mails received on the internal port using the domain of
510 the envelope sender address or create a list of domains, for which emails
511 should be signed, defaulting to the list of relay domains.
514 Enable DKIM Signing::
516 Controls whether outbound mail should get DKIM signed.
520 The selector used for signing the mail. The private key used for signing is
521 saved under `/etc/pmg/dkim/yourselector.private`. You can display the DNS TXT
522 record which you need to add to all domains signed by {pmg} by clicking on the
523 'View DNS Record' Button.
525 Sign all Outgoing Mail::
527 Controls whether all outbound mail should get signed or only mails from domains
528 listed in `/etc/pmg/dkim/domains` if it exists and `/etc/pmg/domains` otherwise.
530 Those settings are saved to subsection 'admin' in `/etc/pmg/pmg.conf`,
531 using the following configuration keys:
533 include::pmg.admin-dkim-conf-opts.adoc[]
540 [thumbnail="pmg-gui-mailproxy-whitelist.png", big=1]
543 All SMTP checks are disabled for those entries (e.g. Greylisting,
546 NOTE: If you use a backup MX server (e.g. your ISP offers this service
547 for you) you should always add those servers here.
550 [[pmgconfig_spamdetector]]
551 Spam Detector Configuration
552 ---------------------------
558 [thumbnail="pmg-gui-spam-options.png", big=1]
561 {pmg} uses a wide variety of local and network tests to identify spam
562 signatures. This makes it harder for spammers to identify one aspect
563 which they can craft their messages to work around the spam filter.
565 Every single email will be analyzed and gets a spam score
566 assigned. The system attempts to optimize the efficiency of the rules
567 that are run in terms of minimizing the number of false positives and
570 include::pmg.spam-conf-opts.adoc[]
573 [[pmgconfig_spamdetector_quarantine]]
578 [thumbnail="pmg-gui-spamquar-options.png", big=1]
581 {pmg} analyses all incoming email messages and decides for each
582 email if it is ham or spam (or virus). Good emails are delivered to
583 the inbox and spam messages are moved into the spam quarantine.
585 The system can be configured to send daily reports to inform users
586 about the personal spam messages received the last day. The report is
587 only sent if there are new messages in the quarantine.
589 Some options are only available in the config file `/etc/pmg/pmg.conf`,
590 and not in the web interface.
592 include::pmg.spamquar-conf-opts.adoc[]
595 [[pmgconfig_spamdetector_customscores]]
596 Customization of Rulescores
597 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
600 [thumbnail="pmg-gui-spam-custom-scores.png", big=1]
603 While the default scoring of {spamassassin}'s ruleset provides very good
604 detection rates, sometimes your particular environment can benefit from
605 slightly adjusting the score of a particular rule. Two examples:
607 * Your system receives spam mails which are scored at 4.9 and you have
608 a rule which puts all mails above 5 in the quarantine. The one thing the
609 spam mails have in common is that they all hit 'URIBL_BLACK'. By increasing
610 the score of this rule by 0.2 points the spam mails would all be quarantined
611 instead of being sent to your users
613 * Your system tags many legitimate mails from a partner organization as spam,
614 because the organization has a policy that each mail has to start with
615 'Dear madam or sir' (generating 1.9 points through the rule
616 'DEAR_SOMETHING'). By setting the score of this rule to 0 you can disable
619 The system logs all the rules which a particular mail hits. Analyzing the logs can
620 lead to finding such a pattern in your environment.
622 You can adjust the score of a rule by creating a new 'Custom Rule Score' entry
625 NOTE: In general it is strongly recommended to not make large changes to the
630 Virus Detector Configuration
631 ----------------------------
633 [[pmgconfig_clamav_options]]
638 [thumbnail="pmg-gui-virus-options.png", big=1]
641 All mails are automatically passed to the included virus detector
642 ({clamav}). The default settings are considered safe, so it is usually
643 not required to change them.
645 {clamav} related settings are saved to subsection 'clamav' in `/etc/pmg/pmg.conf`,
646 using the following configuration keys:
648 include::pmg.clamav-conf-opts.adoc[]
651 [thumbnail="pmg-gui-clamav-database.png", big=1]
654 Please note that the virus signature database is automatically
655 updated. You can see the database status in the GUI, and also
656 trigger manual updates there.
659 [[pmgconfig_clamav_quarantine]]
664 [thumbnail="pmg-gui-virusquar-options.png", big=1]
667 Indentified virus mails are automatically moved to the virus
668 quarantine. The administrator can view these mails using the GUI, and
669 choose to deliver them in case of false positives. {pmg} does not notify
670 individual users about received virus mails.
672 Virus quarantine related settings are saved to subsection 'virusquar'
673 in `/etc/pmg/pmg.conf`, using the following configuration keys:
675 include::pmg.virusquar-conf-opts.adoc[]
678 Custom SpamAssassin configuration
679 ---------------------------------
681 This is only for advanced users. {spamassassin}'s rules and their associated
682 scores get updated regularly and are trained on a huge corpus, which gets
683 classified by experts. In most cases adding a rule for matching a particular
684 keyword is the wrong approach, leading to many false positives. Usually bad
685 detection rates are better addressed by properly setting up DNS than by adding
686 a custom rule - watch out for matches to 'URIBL_BLOCKED' in the logs or
687 spam-headers - see the {spamassassin_dnsbl}.
689 To add or change the Proxmox {spamassassin} configuration please login to the
690 console via SSH. Change to the `/etc/mail/spamassassin/` directory. In this
691 directory there are several files (`init.pre`, `local.cf`, ...) - do not change
692 them, as `init.pre`, `v310.pre`, `v320.pre`, `local.cf` will be overwritten by
693 the xref:pmgconfig_template_engine[template engine], while the others can
694 get updated by any {spamassassin} package upgrade.
696 To add your custom configuration, you have to create a new file and name it
697 `custom.cf` (in this directory), then add your configuration there. Make sure
698 to use the correct {spamassassin} syntax, and test it with:
701 # spamassassin -D --lint
704 If you run a cluster, the `custom.cf` file is synchronized from the
705 master node to all cluster members automatically.
707 To adjust the score assigned to a particular rule you
708 can also use the xref:pmgconfig_spamdetector_customscores[Custom Rule Score]
712 [[pmgconfig_custom_check]]
713 Custom Check Interface
714 ----------------------
716 For use-cases which are not handled by the {pmg} Virus Detector and
717 {spamassassin} configuration, advanced users can create a custom check
718 executable which, if enabled will be called before the Virus Detector and before
719 passing an email through the Rule System. The custom check API is kept as
720 simple as possible, while still providing a great deal of control over the
721 treatment of an email. Its input is passed via two CLI arguments:
723 * the 'api-version' (currently `v1`) - for potential future change of the
726 * the 'queue-file-name' - a filename, which contains the complete email as
729 The expected output need to be printed on STDOUT and consists of two lines:
731 * the 'api-version' (currently 'v1') - see above
733 * one of the following 3 results:
734 ** 'OK' - email is ok
735 ** 'VIRUS: <virusdescription>' - email is treated as if it contained a virus
736 (the virus description is logged and added to the email's headers)
737 ** 'SCORE: <number>' - <number> is added (negative numbers are also possible)
738 to the email's spamscore
740 The check is run with a 5 minute timeout - if it is exceeded the check
741 executable is killed and the email is treated as OK.
743 All output written to STDERR by the check is written with priority 'err' to the
746 A simple sample script following the API (and yielding a random result) for
752 echo "called with $*" 1>&2
754 if [ "$#" -ne 2 ]; then
755 echo "usage: $0 APIVERSION QUEUEFILENAME" 1>&2
762 if [ "$apiver" != "v1" ]; then
763 echo "wrong APIVERSION: $apiver" 1>&2
771 choice=$(shuf -i 0-3 -n1)
781 echo VIRUS: Random Virus
784 for i in $(seq 1 7); do
785 echo "custom checking mail: $queue_file - minute $i" 1>&2
794 The custom check needs to be enabled in the admin section of `/etc/pmg/pmg.conf`
801 The location of the custom check executable can also be set there with the key
802 `custom_check_path` and defaults to `/usr/local/bin/pmg-custom-check`.
808 User management in {pmg} consists of three types of users/accounts:
811 [[pmgconfig_localuser]]
815 [thumbnail="pmg-gui-local-user-config.png", big=1]
817 Local users can manage and audit {pmg}. They can login on the
818 management web interface.
820 There are three roles:
824 Is allowed to manage settings of {pmg}, except some tasks like
825 network configuration and upgrading.
829 Is allowed to manage quarantines, blacklists and whitelists, but not other
830 settings. Has no right to view any other data.
834 With this role, the user is only allowed to view data and configuration, but
837 In addition there is always the 'root' user, which is used to perform special
838 system administrator tasks, such as upgrading a host or changing the
839 network configuration.
841 NOTE: Only pam users are able to login via the webconsole and ssh, which the
842 users created with the web interface are not. Those users are created for
843 {pmg} administration only.
845 Local user related settings are saved in `/etc/pmg/user.conf`.
847 For details of the fields see xref:pmg_user_configuration_file[user.conf]
850 LDAP/Active Directory
851 ~~~~~~~~~~~~~~~~~~~~~
853 [thumbnail="pmg-gui-ldap-user-config.png", big=1]
855 You can specify multiple LDAP/Active Directory profiles, so that you can
856 create rules matching those users and groups.
858 Creating a profile requires (at least) the following:
861 * protocol (LDAP or LDAPS; LDAPS is recommended)
862 * at least one server
863 * a user and password (if your server does not support anonymous binds)
865 All other fields should work with the defaults for most setups, but can be
866 used to customize the queries.
868 The settings are saved to `/etc/pmg/ldap.conf`. Details for the options
869 can be found here: xref:pmg_ldap_configuration_file[ldap.conf]
874 It is highly recommended that the user which you use for connecting to the
875 LDAP server only has the permission to query the server. For LDAP servers
876 (for example OpenLDAP or FreeIPA), the username has to be of a format like
877 'uid=username,cn=users,cn=accounts,dc=domain' , where the specific fields are
878 depending on your setup. For Active Directory servers, the format should be
879 like 'username@domain' or 'domain\username'.
884 {pmg} synchronizes the relevant user and group info periodically, so that
885 the information is available in a fast manner, even when the LDAP/AD server
886 is temporarily not accessible.
888 After a successful sync, the groups and users should be visible on the web
889 interface. After that, you can create rules targeting LDAP users and groups.
892 [[pmgconfig_fetchmail]]
896 [thumbnail="pmg-gui-fetchmail-config.png", big=1]
898 Fetchmail is utility for polling and forwarding emails. You can define
899 email accounts, which will then be fetched and forwarded to the email
902 You have to add an entry for each account/target combination you want to
903 fetch and forward. Those will then be regularly polled and forwarded,
904 according to your configuration.
906 The API and web interface offer following configuration options:
908 include::fetchmail.conf.5-opts.adoc[]
912 include::pmg-copyright.adoc[]