-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy path11_network-services.po
2647 lines (1952 loc) · 137 KB
/
11_network-services.po
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2015-11-17 12:22+0100\n"
"PO-Revision-Date: 2015-11-17 12:22+0100\n"
"Last-Translator: Automatically generated\n"
"Language-Team: None\n"
"Language: en-US \n"
"MIME-Version: 1.0\n"
"Content-Type: application/x-publican; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Publican v4.3.2\n"
msgid "Postfix"
msgstr ""
msgid "Apache"
msgstr ""
msgid "NFS"
msgstr ""
msgid "Samba"
msgstr ""
msgid "Squid"
msgstr ""
msgid "OpenLDAP"
msgstr ""
msgid "SIP"
msgstr ""
msgid "Network Services: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN"
msgstr ""
msgid "Network services are the programs that users interact with directly in their daily work. They are the tip of the information system iceberg, and this chapter focuses on them; the hidden parts they rely on are the infrastructure we already described."
msgstr ""
msgid "Many modern network services require encryption technology to operate reliably and securely, especially when used on the public Internet. X.509 Certificates (which may also be referred to as SSL Certificates or TLS Certificates) are frequently used for this purpose. A certificate for a specific domain can often be shared between more than one of the services discussed in this chapter."
msgstr ""
msgid "<primary>TLS</primary>"
msgstr ""
msgid "<primary>X.509</primary>"
msgstr ""
msgid "<primary>Certificates</primary>"
msgstr ""
msgid "Mail Server"
msgstr ""
msgid "The Falcot Corp administrators selected Postfix for the electronic mail server, due to its reliability and its ease of configuration. Indeed, its design enforces that each task is implemented in a process with the minimum set of required permissions, which is a great mitigation measure against security problems."
msgstr ""
msgid "<primary>email</primary><secondary>server</secondary>"
msgstr ""
msgid "<primary>mail server</primary>"
msgstr ""
msgid "<primary>Postfix</primary>"
msgstr ""
msgid "<emphasis>ALTERNATIVE</emphasis> The Exim4 server"
msgstr ""
msgid "<primary>Exim</primary>"
msgstr ""
msgid "Debian uses Exim4 as the default email server (which is why the initial installation includes Exim4). The configuration is provided by a separate package, <emphasis role=\"pkg\">exim4-config</emphasis>, and automatically customized based on the answers to a set of Debconf questions very similar to the questions asked by the <emphasis role=\"pkg\">postfix</emphasis> package."
msgstr ""
msgid "The configuration can be either in one single file (<filename>/etc/exim4/exim4.conf.template</filename>) or split across a number of configuration snippets stored under <filename>/etc/exim4/conf.d/</filename>. In both cases, the files are used by <command>update-exim4.conf</command> as templates to generate <filename>/var/lib/exim4/config.autogenerated</filename>. The latter is the file used by Exim4. Thanks to this mechanism, values obtained through Exim's debconf configuration — which are stored in <filename>/etc/exim4/update-exim4.conf.conf</filename> — can be injected in Exim's configuration file, even when the administrator or another package has altered the default Exim configuration."
msgstr ""
msgid "The Exim4 configuration file syntax has its peculiarities and its learning curve; however, once these peculiarities are understood, Exim4 is a very complete and powerful email server, as evidenced by the tens of pages of documentation. <ulink type=\"block\" url=\"http://www.exim.org/docs.html\" />"
msgstr ""
msgid "Installing Postfix"
msgstr ""
msgid "The <emphasis role=\"pkg\">postfix</emphasis> package includes the main SMTP daemon. Other packages (such as <emphasis role=\"pkg\">postfix-ldap</emphasis> and <emphasis role=\"pkg\">postfix-pgsql</emphasis>) add extra functionality to Postfix, including access to mapping databases. You should only install them if you know that you need them."
msgstr ""
msgid "<emphasis>BACK TO BASICS</emphasis> SMTP"
msgstr ""
msgid "<primary>SMTP</primary>"
msgstr ""
msgid "<primary>Simple Mail Transfer Protocol</primary>"
msgstr ""
msgid "<primary>server</primary><secondary>SMTP</secondary>"
msgstr ""
msgid "SMTP (<emphasis>Simple Mail Transfer Protocol</emphasis>) is the protocol used by mail servers to exchange and route emails."
msgstr ""
msgid "Several Debconf questions are asked during the installation of the package. The answers allow generating a first version of the <filename>/etc/postfix/main.cf</filename> configuration file."
msgstr ""
msgid "The first question deals with the type of setup. Only two of the proposed answers are relevant in case of an Internet-connected server, “Internet site” and “Internet with smarthost”. The former is appropriate for a server that receives incoming email and sends outgoing email directly to its recipients, and is therefore well-adapted to the Falcot Corp case. The latter is appropriate for a server receiving incoming email normally, but that sends outgoing email through an intermediate SMTP server — the “smarthost” — rather than directly to the recipient's server. This is mostly useful for individuals with a dynamic IP address, since many email servers reject messages coming straight from such an IP address. In this case, the smarthost will usually be the ISP's SMTP server, which is always configured to accept email coming from the ISP's customers and forward it appropriately. This setup (with a smarthost) is also relevant for servers that are not permanently connected to the internet, since it avoids having to manage a queue of undeliverable messages that need to be retried later."
msgstr ""
msgid "<emphasis>VOCABULARY</emphasis> ISP"
msgstr ""
msgid "<primary>ISP, Internet Service Provider</primary>"
msgstr ""
msgid "ISP is the acronym for “Internet Service Provider”. It covers an entity, often a commercial company, that provides Internet connections and the associated basic services (email, news and so on)."
msgstr ""
msgid "The second question deals with the full name of the machine, used to generate email addresses from a local user name; the full name of the machine ends up as the part after the at-sign (“@”). In the case of Falcot, the answer should be <literal>mail.falcot.com</literal>. This is the only question asked by default, but the configuration it leads to is not complete enough for the needs of Falcot, which is why the administrators run <command>dpkg-reconfigure postfix</command> so as to be able to customize more parameters."
msgstr ""
msgid "One of the extra questions asks for all the domain names related to this machine. The default list includes its full name as well as a few synonyms for <literal>localhost</literal>, but the main <literal>falcot.com</literal> domain needs to be added by hand. More generally, this question should usually be answered with all the domain names for which this machine should serve as an MX server; in other words, all the domain names for which the DNS says that this machine will accept email. This information ends up in the <literal>mydestination</literal> variable of the main Postfix configuration file — <filename>/etc/postfix/main.cf</filename>."
msgstr ""
msgid "<primary>server</primary><secondary>MX</secondary>"
msgstr ""
msgid "<primary>MX</primary><secondary>server</secondary>"
msgstr ""
msgid "Role of the DNS <emphasis>MX</emphasis> record while sending a mail"
msgstr ""
msgid "<emphasis>EXTRA</emphasis> Querying the MX records"
msgstr ""
msgid "When the DNS does not have an MX record for a domain, the email server will try sending the messages to the host itself, by using the matching A record (or AAAA in IPv6)."
msgstr ""
msgid "In some cases, the installation can also ask what networks should be allowed to send email via the machine. In its default configuration, Postfix only accepts emails coming from the machine itself; the local network will usually be added. The Falcot Corp administrators added <literal>192.168.0.0/16</literal> to the default answer. If the question is not asked, the relevant variable in the configuration file is <literal>mynetworks</literal>, as seen in the example below."
msgstr ""
msgid "Local email can also be delivered through <command>procmail</command>. This tool allows users to sort their incoming email according to rules stored in their <filename>~/.procmailrc</filename> file."
msgstr ""
msgid "<primary><command>procmail</command></primary>"
msgstr ""
msgid "<primary>email</primary><secondary>filtering</secondary>"
msgstr ""
msgid "<primary>filtering email</primary>"
msgstr ""
msgid "After this first step, the administrators got the following configuration file; it will be used as a starting point for adding some extra functionality in the next sections."
msgstr ""
msgid "Initial <filename>/etc/postfix/main.cf</filename> file"
msgstr ""
msgid ""
"\n"
"# See /usr/share/postfix/main.cf.dist for a commented, more complete version\n"
"\n"
"\n"
"# Debian specific: Specifying a file name will cause the first\n"
"# line of that file to be used as the name. The Debian default\n"
"# is /etc/mailname.\n"
"#myorigin = /etc/mailname\n"
"\n"
"smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)\n"
"biff = no\n"
"\n"
"# appending .domain is the MUA's job.\n"
"append_dot_mydomain = no\n"
"\n"
"# Uncomment the next line to generate \"delayed mail\" warnings\n"
"#delay_warning_time = 4h\n"
"\n"
"readme_directory = no\n"
"\n"
"# TLS parameters\n"
"smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem\n"
"smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key\n"
"smtpd_use_tls=yes\n"
"smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache\n"
"smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache\n"
"\n"
"# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for\n"
"# information on enabling SSL in the smtp client.\n"
"\n"
"smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination\n"
"myhostname = mail.falcot.com\n"
"alias_maps = hash:/etc/aliases\n"
"alias_database = hash:/etc/aliases\n"
"myorigin = /etc/mailname\n"
"mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost\n"
"relayhost = \n"
"mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16\n"
"mailbox_command = procmail -a \"$EXTENSION\"\n"
"mailbox_size_limit = 0\n"
"recipient_delimiter = +\n"
"inet_interfaces = all\n"
"inet_protocols = all"
msgstr ""
msgid "<emphasis>SECURITY</emphasis> <emphasis>Snake oil</emphasis> SSL certificates"
msgstr ""
msgid "The <emphasis>snake oil</emphasis> certificates, like the <emphasis>snake oil</emphasis> “medicine” sold by unscrupulous quacks in old times, have absolutely no value: you cannot rely on them to authenticate the server since they are automatically generated self-signed certificates. However they are useful to improve the privacy of the exchanges."
msgstr ""
msgid "In general they should only be used for testing purposes, and normal service must use real certificates; these can be generated with the procedure described in <xref linkend=\"sect.easy-rsa\" />."
msgstr ""
msgid "Configuring Virtual Domains"
msgstr ""
msgid "<primary>domain</primary><secondary>virtual</secondary>"
msgstr ""
msgid "<primary>virtual domain</primary>"
msgstr ""
msgid "The mail server can receive emails addressed to other domains besides the main domain; these are then known as virtual domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains."
msgstr ""
msgid "<emphasis>CAUTION</emphasis> Virtual domains and canonical domains"
msgstr ""
msgid "None of the virtual domains must be referenced in the <literal>mydestination</literal> variable; this variable only contains the names of the “canonical” domains directly associated to the machine and its local users."
msgstr ""
msgid "Virtual Alias Domains"
msgstr ""
msgid "<primary>alias</primary><secondary>virtual alias domain</secondary>"
msgstr ""
msgid "<primary>virtual domain</primary><secondary>virtual alias domain</secondary>"
msgstr ""
msgid "A virtual alias domain only contains aliases, i.e. addresses that only forward emails to other addresses."
msgstr ""
msgid "Such a domain is enabled by adding its name to the <literal>virtual_alias_domains</literal> variable, and referencing an address mapping file in the <literal>virtual_alias_maps</literal> variable."
msgstr ""
msgid "Directives to add in the <filename>/etc/postfix/main.cf</filename> file"
msgstr ""
msgid ""
"\n"
"virtual_alias_domains = falcotsbrand.com\n"
"virtual_alias_maps = hash:/etc/postfix/virtual"
msgstr ""
msgid "The <filename>/etc/postfix/virtual</filename> file describes a mapping with a rather straightforward syntax: each line contains two fields separated by whitespace; the first field is the alias name, the second field is a list of email addresses where it redirects. The special <literal>@domain.com</literal> syntax covers all remaining aliases in a domain."
msgstr ""
msgid "Example <filename>/etc/postfix/virtual</filename> file"
msgstr ""
msgid ""
"\n"
"webmaster@falcotsbrand.com jean@falcot.com\n"
"contact@falcotsbrand.com laure@falcot.com, sophie@falcot.com\n"
"# The alias below is generic and covers all addresses within \n"
"# the falcotsbrand.com domain not otherwise covered by this file.\n"
"# These addresses forward email to the same user name in the\n"
"# falcot.com domain.\n"
"@falcotsbrand.com @falcot.com"
msgstr ""
msgid "Virtual Mailbox Domains"
msgstr ""
msgid "<emphasis>CAUTION</emphasis> Combined virtual domain?"
msgstr ""
msgid "Postfix does not allow using the same domain in both <literal>virtual_alias_domains</literal> and <literal>virtual_mailbox_domains</literal>. However, every domain of <literal>virtual_mailbox_domains</literal> is implicitly included in <literal>virtual_alias_domains</literal>, which makes it possible to mix aliases and mailboxes within a virtual domain."
msgstr ""
msgid "<primary>mailbox, virtual domain</primary>"
msgstr ""
msgid "<primary>virtual domain</primary><secondary>virtual mailbox domain</secondary>"
msgstr ""
msgid "Messages addressed to a virtual mailbox domain are stored in mailboxes not assigned to a local system user."
msgstr ""
msgid "Enabling a virtual mailbox domain requires naming this domain in the <literal>virtual_mailbox_domains</literal> variable, and referencing a mailbox mapping file in <literal>virtual_mailbox_maps</literal>. The <literal>virtual_mailbox_base</literal> parameter contains the directory under which the mailboxes will be stored."
msgstr ""
msgid "The <literal>virtual_uid_maps</literal> parameter (respectively <literal>virtual_gid_maps</literal>) references the file containing the mapping between the email address and the system user (respectively group) that “owns” the corresponding mailbox. To get all mailboxes owned by the same owner/group, the <literal>static:5000</literal> syntax assigns a fixed UID/GID (of value 5000 here)."
msgstr ""
msgid ""
"\n"
"virtual_mailbox_domains = falcot.org\n"
"virtual_mailbox_maps = hash:/etc/postfix/vmailbox\n"
"virtual_mailbox_base = /var/mail/vhosts"
msgstr ""
msgid "Again, the syntax of the <filename>/etc/postfix/vmailbox</filename> file is quite straightforward: two fields separated with whitespace. The first field is an email address within one of the virtual domains, and the second field is the location of the associated mailbox (relative to the directory specified in <emphasis>virtual_mailbox_base</emphasis>). If the mailbox name ends with a slash (<literal>/</literal>), the emails will be stored in the <emphasis>maildir</emphasis> format; otherwise, the traditional <emphasis>mbox</emphasis> format will be used. The <emphasis>maildir</emphasis> format uses a whole directory to store a mailbox, each individual message being stored in a separate file. In the <emphasis>mbox</emphasis> format, on the other hand, the whole mailbox is stored in one file, and each line starting with “<literal>From </literal>” (<literal>From</literal> followed by a space) signals the start of a new message."
msgstr ""
msgid "The <filename>/etc/postfix/vmailbox</filename> file"
msgstr ""
msgid ""
"\n"
"# Jean's email is stored as maildir, with\n"
"# one file per email in a dedicated directory\n"
"jean@falcot.org falcot.org/jean/\n"
"# Sophie's email is stored in a traditional \"mbox\" file,\n"
"# with all mails concatenated into one single file\n"
"sophie@falcot.org falcot.org/sophie"
msgstr ""
msgid "Restrictions for Receiving and Sending"
msgstr ""
msgid "The growing number of unsolicited bulk emails (<emphasis>spam</emphasis>) requires being increasingly strict when deciding which emails a server should accept. This section presents some of the strategies included in Postfix."
msgstr ""
msgid "<emphasis>CULTURE</emphasis> The spam problem"
msgstr ""
msgid "<primary>spam</primary>"
msgstr ""
msgid "“Spam” is a generic term used to designate all the unsolicited commercial emails (also known as UCEs) that flood our electronic mailboxes; the unscrupulous individuals sending them are known as spammers. They care little about the nuisance they cause, since sending an email costs very little, and only a very small percentage of recipients need to be attracted by the offers for the spamming operation to make more money than it costs. The process is mostly automated, and any email address made public (for instance, on a web forum, or on the archives of a mailing list, or on a blog, and so on) will be discovered by the spammers' robots, and subjected to a never-ending stream of unsolicited messages."
msgstr ""
msgid "All system administrators try to face this nuisance with spam filters, but of course spammers keep adjusting to try to work around these filters. Some even rent networks of machines compromised by a worm from various crime syndicates. Recent statistics estimate that up to 95% of all emails circulating on the Internet are spam!"
msgstr ""
msgid "IP-Based Access Restrictions"
msgstr ""
msgid "The <literal>smtpd_client_restrictions</literal> directive controls which machines are allowed to communicate with the email server."
msgstr ""
msgid "Restrictions Based on Client Address"
msgstr ""
msgid ""
"\n"
"smtpd_client_restrictions = permit_mynetworks,\n"
" warn_if_reject reject_unknown_client,\n"
" check_client_access hash:/etc/postfix/access_clientip,\n"
" reject_rbl_client sbl-xbl.spamhaus.org,\n"
" reject_rbl_client list.dsbl.org"
msgstr ""
msgid "When a variable contains a list of rules, as in the example above, these rules are evaluated in order, from the first to the last. Each rule can accept the message, reject it, or leave the decision to a following rule. As a consequence, order matters, and simply switching two rules can lead to a widely different behavior."
msgstr ""
msgid "The <literal>permit_mynetworks</literal> directive, used as the first rule, accepts all emails coming from a machine in the local network (as defined by the <emphasis>mynetworks</emphasis> configuration variable)."
msgstr ""
msgid "The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the <literal>warn_if_reject</literal> modifier to the <literal>reject_unknown_client</literal> directive: this modifier turns the rejection into a simple warning recorded in the logs. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement."
msgstr ""
msgid "<emphasis>TIP</emphasis> <emphasis>access</emphasis> tables"
msgstr ""
msgid "The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created from an uncompressed copy of the <filename>/usr/share/doc/postfix-doc/examples/access.gz</filename> file. This model is self-documented in its comments, which means each table describes its own syntax."
msgstr ""
msgid "The <filename>/etc/postfix/access_clientip</filename> table lists IP addresses and networks; <filename>/etc/postfix/access_helo</filename> lists domain names; <filename>/etc/postfix/access_sender</filename> contains sender email addresses. All these files need to be turned into hash-tables (a format optimized for fast access) after each change, with the <command>postmap /etc/postfix/<replaceable>file</replaceable></command> command."
msgstr ""
msgid "The third directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the <filename>/etc/postfix/access_clientip</filename> file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules."
msgstr ""
msgid "The last two rules reject any message coming from a server listed in one of the indicated blacklists. RBL is an acronym for <emphasis>Remote Black List</emphasis>; there are several such lists, but they all list badly configured servers that spammers use to relay their emails, as well as unexpected mail relays such as machines infected with worms or viruses."
msgstr ""
msgid "<primary>RBL</primary>"
msgstr ""
msgid "<primary>Remote Black List</primary>"
msgstr ""
msgid "<emphasis>TIP</emphasis> White list and RBLs"
msgstr ""
msgid "Blacklists sometimes include a legitimate server that has been suffering an incident. In these situations, all emails coming from one of these servers would be rejected unless the server is listed in a whitelist defined by <filename>/etc/postfix/access_clientip</filename>."
msgstr ""
msgid "Prudence therefore recommends including in the whitelist all the trusted servers from which many emails are usually received."
msgstr ""
msgid "Checking the Validity of the <literal>EHLO</literal> or <literal>HELO</literal> Commands"
msgstr ""
msgid "Each SMTP exchange starts with a <literal>HELO</literal> (or <literal>EHLO</literal>) command, followed by the name of the sending email server; checking the validity of this name can be interesting."
msgstr ""
msgid "<primary><literal>HELO</literal></primary>"
msgstr ""
msgid "<primary><literal>EHLO</literal></primary>"
msgstr ""
msgid "Restrictions on the name announced in <literal>EHLO</literal>"
msgstr ""
msgid ""
"\n"
"smtpd_helo_restrictions = permit_mynetworks,\n"
" reject_invalid_hostname,\n"
" check_helo_access hash:/etc/postfix/access_helo,\n"
" reject_non_fqdn_hostname,\n"
" warn_if_reject reject_unknown_hostname"
msgstr ""
msgid "The first <literal>permit_mynetworks</literal> directive allows all machines on the local network to introduce themselves freely. This is important, because some email programs do not respect this part of the SMTP protocol adequately enough, and they can introduce themselves with nonsensical names."
msgstr ""
msgid "The <literal>reject_invalid_hostname</literal> rule rejects emails when the <literal>EHLO</literal> announce lists a syntactically incorrect hostname. The <literal>reject_non_fqdn_hostname</literal> rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The <literal>reject_unknown_hostname</literal> rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to too many rejections, the administrators turned its effect to a simple warning with the <literal>warn_if_reject</literal> modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule."
msgstr ""
msgid "Using <literal>permit_mynetworks</literal> as the first rule has an interesting side effect: the following rules only apply to hosts outside the local network. This allows blacklisting all hosts that announce themselves as part of the <literal>falcot.com</literal>, for instance by adding a <literal>falcot.com REJECT You are not in our network!</literal> line to the <filename>/etc/postfix/access_helo</filename> file."
msgstr ""
msgid "Accepting or Refusing Based on the Announced Sender"
msgstr ""
msgid "Every message has a sender, announced by the <literal>MAIL FROM</literal> command of the SMTP protocol; again, this information can be validated in several different ways."
msgstr ""
msgid "<primary><literal>MAIL FROM</literal></primary>"
msgstr ""
msgid "<primary>email</primary><secondary>filtering on the sender</secondary>"
msgstr ""
msgid "Sender checks"
msgstr ""
msgid ""
"\n"
"smtpd_sender_restrictions = \n"
" check_sender_access hash:/etc/postfix/access_sender,\n"
" reject_unknown_sender_domain, reject_unlisted_sender,\n"
" reject_non_fqdn_sender"
msgstr ""
msgid "The <filename>/etc/postfix/access_sender</filename> table maps some special treatment to some senders. This usually means listing some senders into a white list or a black list."
msgstr ""
msgid "The <literal>reject_unknown_sender_domain</literal> rule requires a valid sender domain, since it is needed for a valid address. The <literal>reject_unlisted_sender</literal> rule rejects local senders if the address does not exist; this prevents emails from being sent from an invalid address in the <literal>falcot.com</literal> domain, and messages emanating from <literal>joe.bloggs@falcot.com</literal> are only accepted if such an address really exists."
msgstr ""
msgid "Finally, the <literal>reject_non_fqdn_sender</literal> rule rejects emails purporting to come from addresses without a fully-qualified domain name. In practice, this means rejecting emails coming from <literal>user@machine</literal>: the address must be announced as either <literal>user@machine.example.com</literal> or <literal>user@example.com</literal>."
msgstr ""
msgid "Accepting or Refusing Based on the Recipient"
msgstr ""
msgid "Each email has at least one recipient, announced with the <literal>RCPT TO</literal> command in the SMTP protocol. These addresses also warrant validation, even if that may be less relevant than the checks made on the sender address."
msgstr ""
msgid "<primary>RCPT TO</primary>"
msgstr ""
msgid "<primary>email</primary><secondary>filtering on the recipient</secondary>"
msgstr ""
msgid "Recipient checks"
msgstr ""
msgid ""
"\n"
"smtpd_recipient_restrictions = permit_mynetworks, \n"
" reject_unauth_destination, reject_unlisted_recipient, \n"
" reject_non_fqdn_recipient"
msgstr ""
msgid "<literal>reject_unauth_destination</literal> is the basic rule that requires outside messages to be addressed to us; messages sent to an address not served by this server are rejected. Without this rule, a server becomes an open relay that allows spammers to send unsolicited emails; this rule is therefore mandatory, and it will be best included near the beginning of the list, so that no other rules may authorize the message before its destination has been checked."
msgstr ""
msgid "The <literal>reject_unlisted_recipient</literal> rule rejects messages sent to non-existing local users, which makes sense. Finally, the <literal>reject_non_fqdn_recipient</literal> rule rejects non-fully-qualified addresses; this makes it impossible to send an email to <literal>jean</literal> or <literal>jean@machine</literal>, and requires using the full address instead, such as <literal>jean@machine.falcot.com</literal> or <literal>jean@falcot.com</literal>."
msgstr ""
msgid "Restrictions Associated with the <literal>DATA</literal> Command"
msgstr ""
msgid "The <literal>DATA</literal> command of SMTP is emitted before the contents of the message. It doesn't provide any information per se, apart from announcing what comes next. It can still be subjected to checks."
msgstr ""
msgid "<primary><literal>DATA</literal></primary>"
msgstr ""
msgid "<literal>DATA</literal> checks"
msgstr ""
msgid "\n"
"smtpd_data_restrictions = reject_unauth_pipelining"
msgstr ""
msgid "The <literal>reject_unauth_pipelining</literal> directives causes the message to be rejected if the sending party sends a command before the reply to the previous command has been sent. This guards against a common optimization used by spammer robots, since they usually don't care a fig about replies and only focus on sending as many emails as possible in as short a time as possible."
msgstr ""
msgid "Applying Restrictions"
msgstr ""
msgid "Although the above commands validate information at various stages of the SMTP exchange, Postfix only sends the actual rejection as a reply to the <literal>RCPT TO</literal> command."
msgstr ""
msgid "This means that even if the message is rejected due to an invalid <literal>EHLO</literal> command, Postfix knows the sender and the recipient when announcing the rejection. It can then log a more explicit message than it could if the transaction had been interrupted from the start. In addition, a number of SMTP clients do not expect failures on the early SMTP commands, and these clients will be less disturbed by this late rejection."
msgstr ""
msgid "A final advantage to this choice is that the rules can accumulate information during the various stages of the SMTP exchange; this allows defining more fine-grained permissions, such as rejecting a non-local connection if it announces itself with a local sender."
msgstr ""
msgid "Filtering Based on the Message Contents"
msgstr ""
msgid "The validation and restriction system would not be complete without a way to apply checks to the message contents. Postfix differentiates the checks applying to the email headers from those applying to the email body."
msgstr ""
msgid "Enabling content-based filters"
msgstr ""
msgid ""
"\n"
"header_checks = regexp:/etc/postfix/header_checks\n"
"body_checks = regexp:/etc/postfix/body_checks"
msgstr ""
msgid "<primary>email</primary><secondary>filtering on contents</secondary>"
msgstr ""
msgid "Both files contain a list of regular expressions (commonly known as <emphasis>regexps</emphasis> or <emphasis>regexes</emphasis>) and associated actions to be triggered when the email headers (or body) match the expression."
msgstr ""
msgid "<emphasis>QUICK LOOK</emphasis> Regexp tables"
msgstr ""
msgid "The <filename>/usr/share/doc/postfix-doc/examples/header_checks.gz</filename> file contains many explanatory comments and can be used as a starting point for creating the <filename>/etc/postfix/header_checks</filename> and <filename>/etc/postfix/body_checks</filename> files."
msgstr ""
msgid "Example <filename>/etc/postfix/header_checks</filename> file"
msgstr ""
msgid ""
"\n"
"/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)\n"
"/^Subject: *Your email contains VIRUSES/ DISCARD virus notification"
msgstr ""
msgid "<emphasis>BACK TO BASICS</emphasis> Regular expression"
msgstr ""
msgid "The <emphasis>regular expression</emphasis> term (shortened to <emphasis>regexp</emphasis> or <emphasis>regex</emphasis>) references a generic notation for expressing a description of the contents and/or structure of a string of characters. Certain special characters allow defining alternatives (for instance, <literal>foo|bar</literal> matches either “foo” or “bar”), sets of allowed characters (for instance, <literal>[0-9]</literal> means any digit, and <literal>.</literal> — a dot — means any character), quantifications (<literal>s?</literal> matches either <literal>s</literal> or the empty string, in other words 0 or 1 occurrence of <literal>s</literal>; <literal>s+</literal> matches one or more consecutive <literal>s</literal> characters; and so on). Parentheses allow grouping search results."
msgstr ""
msgid "The precise syntax of these expressions varies across the tools using them, but the basic features are similar. <ulink type=\"block\" url=\"http://en.wikipedia.org/wiki/Regular_expression\" />"
msgstr ""
msgid "The first one checks the header mentioning the email software; if <literal>GOTO Sarbacane</literal> (a bulk email software) is found, the message is rejected. The second expression controls the message subject; if it mentions a virus notification, we can decide not to reject the message but to discard it immediately instead."
msgstr ""
msgid "Using these filters is a double-edged sword, because it is easy to make the rules too generic and to lose legitimate emails as a consequence. In these cases, not only the messages will be lost, but their senders will get unwanted (and annoying) error messages."
msgstr ""
msgid "Setting Up <foreignphrase>greylisting</foreignphrase>"
msgstr ""
msgid "<primary>greylisting</primary>"
msgstr ""
msgid "“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted on a further try after some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time."
msgstr ""
msgid "Postfix doesn't provide greylisting natively, but there is a feature by which the decision to accept or reject a given message can be delegated to an external program. The <emphasis role=\"pkg\">postgrey</emphasis> package contains just such a program, designed to interface with this access policy delegation service."
msgstr ""
msgid "Once <emphasis role=\"pkg\">postgrey</emphasis> is installed, it runs as a daemon and listens on port 10023. Postfix can then be configured to use it, by adding the <literal>check_policy_service</literal> parameter as an extra restriction:"
msgstr ""
msgid ""
"\n"
"smtpd_recipient_restrictions = permit_mynetworks,\n"
" [...]\n"
" check_policy_service inet:127.0.0.1:10023"
msgstr ""
msgid "Each time Postfix reaches this rule in the ruleset, it will connect to the <command>postgrey</command> daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database."
msgstr ""
msgid "The main disadvantage of greylisting is that legitimate messages get delayed, which is not always acceptable. It also increases the burden on servers that send many legitimate emails."
msgstr ""
msgid "<emphasis>IN PRACTICE</emphasis> Shortcomings of greylisting"
msgstr ""
msgid "Theoretically, greylisting should only delay the first mail from a given sender to a given recipient, and the typical delay is in the order of minutes. Reality, however, can differ slightly. Some large ISPs use clusters of SMTP servers, and when a message is initially rejected, the server that retries the transmission may not be the same as the initial one. When that happens, the second server gets a temporary error message due to greylisting too, and so on; it may take several hours until transmission is attempted by a server that has already been involved, since SMTP servers usually increase the delay between retries at each failure."
msgstr ""
msgid "As a consequence, the incoming IP address may vary in time even for a single sender. But it goes further: even the sender address can change. For instance, many mailing-list servers encode extra information in the sender address so as to be able to handle error messages (known as <emphasis>bounces</emphasis>). Each new message sent to a mailing-list may then need to go through greylisting, which means it has to be stored (temporarily) on the sender's server. For very large mailing-lists (with tens of thousands of subscribers), this can soon become a problem."
msgstr ""
msgid "To mitigate these drawbacks, Postgrey manages a whitelist of such sites, and messages emanating from them are immediately accepted without going through greylisting. This list can easily be adapted to local needs, since it is stored in the <filename>/etc/postgrey/whitelist_clients</filename> file."
msgstr ""
msgid "<emphasis>GOING FURTHER</emphasis> Selective greylisting with <emphasis role=\"pkg\">milter-greylist</emphasis>"
msgstr ""
msgid "The drawbacks of greylisting can be mitigated by only using greylisting on the subset of clients that are already considered as probable sources of spam (because they are listed in a DNS blacklist). This is not possible with <emphasis role=\"pkg\">postgrey</emphasis> but <emphasis role=\"pkg\">milter-greylist</emphasis> can be used in such a way."
msgstr ""
msgid "In that scenario, since DNS blacklists never triggers a definitive rejection, it becomes reasonable to use aggressive blacklists, including those listing all dynamic IP addresses from ISP clients (such as <literal>pbl.spamhaus.org</literal> or <literal>dul.dnsbl.sorbs.net</literal>)."
msgstr ""
msgid "Since milter-greylist uses Sendmail's milter interface, the postfix side of its configuration is limited to “<literal>smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock</literal>”. The <citerefentry><refentrytitle>greylist.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> manual page documents <filename>/etc/milter-greylist/greylist.conf</filename> and the numerous ways to configure milter-greylist. You will also have to edit <filename>/etc/default/milter-greylist</filename> to actually enable the service."
msgstr ""
msgid "Customizing Filters Based On the Recipient"
msgstr ""
msgid "<xref linkend=\"sect.restrictions-for-receiving-and-sending\" /> and <xref linkend=\"sect.setting-up-greylisting\" /> reviewed many of the possible restrictions. They all have their use in limiting the amount of received spam, but they also all have their drawbacks. It is therefore more and more common to customize the set of filters depending on the recipient. At Falcot Corp, greylisting is interesting for most users, but it hinders the work of some users who need low latency in their emails (such as the technical support service). Similarly, the commercial service sometimes has problems receiving emails from some Asian providers who may be listed in blacklists; this service asked for a non-filtered address so as to be able to correspond."
msgstr ""
msgid "Postfix provides such a customization of filters with a “restriction class” concept. The classes are declared in the <literal>smtpd_restriction_classes</literal> parameter, and defined the same way as <literal>smtpd_recipient_restrictions</literal>. The <literal>check_recipient_access</literal> directive then defines a table mapping a given recipient to the appropriate set of restrictions."
msgstr ""
msgid "Defining restriction classes in <filename>main.cf</filename>"
msgstr ""
msgid ""
"smtpd_restriction_classes = greylisting, aggressive, permissive\n"
"\n"
"greylisting = check_policy_service inet:127.0.0.1:10023\n"
"aggressive = reject_rbl_client sbl-xbl.spamhaus.org,\n"
" check_policy_service inet:127.0.0.1:10023\n"
"permissive = permit\n"
"\n"
"smtpd_recipient_restrictions = permit_mynetworks,\n"
" reject_unauth_destination,\n"
" check_recipient_access hash:/etc/postfix/recipient_access"
msgstr ""
msgid "The <filename>/etc/postfix/recipient_access</filename> file"
msgstr ""
msgid ""
"\n"
"# Unfiltered addresses\n"
"postmaster@falcot.com permissive\n"
"support@falcot.com permissive\n"
"sales-asia@falcot.com permissive\n"
"\n"
"# Aggressive filtering for some privileged users\n"
"joe@falcot.com aggressive\n"
"\n"
"# Special rule for the mailing-list manager\n"
"sympa@falcot.com reject_unverified_sender\n"
"\n"
"# Greylisting by default\n"
"falcot.com greylisting"
msgstr ""
msgid "Integrating an Antivirus"
msgstr ""
msgid "<primary>antivirus</primary>"
msgstr ""
msgid "The many viruses circulating as attachments to emails make it important to set up an antivirus at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages."
msgstr ""
msgid "The Falcot administrators selected <command>clamav</command> for their free antivirus. The main package is <emphasis role=\"pkg\">clamav</emphasis>, but they also installed a few extra packages such as <emphasis role=\"pkg\">arj</emphasis>, <emphasis role=\"pkg\">unzoo</emphasis>, <emphasis role=\"pkg\">unrar</emphasis> and <emphasis role=\"pkg\">lha</emphasis>, since they are required for the antivirus to analyze attachments archived in one of these formats."
msgstr ""
msgid "<primary><command>clamav</command></primary>"
msgstr ""
msgid "<primary><command>clamav-milter</command></primary>"
msgstr ""
msgid "The task of interfacing between antivirus and the email server goes to <command>clamav-milter</command>. A <emphasis>milter</emphasis> (short for <emphasis>mail filter</emphasis>) is a filtering program specially designed to interface with email servers. A milter uses a standard application programming interface (API) that provides much better performance than filters external to the email servers. Milters were initially introduced by <emphasis>Sendmail</emphasis>, but <emphasis>Postfix</emphasis> soon followed suit."
msgstr ""
msgid "<emphasis>QUICK LOOK</emphasis> A milter for Spamassassin"
msgstr ""
msgid "<primary><emphasis role=\"pkg\">spamass-milter</emphasis></primary>"
msgstr ""
msgid "The <emphasis role=\"pkg\">spamass-milter</emphasis> package provides a milter based on <emphasis>SpamAssassin</emphasis>, the famous unsolicited email detector. It can be used to flag messages as probable spams (by adding an extra header) and/or to reject the messages altogether if their “spamminess” score goes beyond a given threshold."
msgstr ""
msgid "Once the <emphasis role=\"pkg\">clamav-milter</emphasis> package is installed, the milter should be reconfigured to run on a TCP port rather than on the default named socket. This can be achieved with <command>dpkg-reconfigure clamav-milter</command>. When prompted for the “Communication interface with Sendmail”, answer “<literal>inet:10002@127.0.0.1</literal>”."
msgstr ""
msgid "<emphasis>NOTE</emphasis> Real TCP port vs named socket"
msgstr ""
msgid "The reason why we use a real TCP port rather than the named socket is that the postfix daemons often run chrooted and do not have access to the directory hosting the named socket. You could also decide to keep using a named socket and pick a location within the chroot (<filename>/var/spool/postfix/</filename>)."
msgstr ""
msgid "The standard ClamAV configuration fits most situations, but some important parameters can still be customized with <command>dpkg-reconfigure clamav-base</command>."
msgstr ""
msgid "The last step involves telling Postfix to use the recently-configured filter. This is a simple matter of adding the following directive to <filename>/etc/postfix/main.cf</filename>:"
msgstr ""
msgid ""
"\n"
"# Virus check with clamav-milter\n"
"smtpd_milters = inet:[127.0.0.1]:10002"
msgstr ""
msgid "If the antivirus causes problems, this line can be commented out, and <command>service postfix reload</command> should be run so that this change is taken into account."
msgstr ""
msgid "<emphasis>IN PRACTICE</emphasis> Testing the antivirus"
msgstr ""
msgid "Once the antivirus is set up, its correct behavior should be tested. The simplest way to do that is to send a test email with an attachment containing the <filename>eicar.com</filename> (or <filename>eicar.com.zip</filename>) file, which can be downloaded online: <ulink type=\"block\" url=\"http://www.eicar.org/86-0-Intended-use.html\" />"
msgstr ""
msgid "This file is not a true virus, but a test file that all antivirus software on the market diagnose as a virus to allow checking installations."
msgstr ""
msgid "All messages handled by Postfix now go through the antivirus filter."
msgstr ""
msgid "Authenticated SMTP"
msgstr ""
msgid "Being able to send emails requires an SMTP server to be reachable; it also requires said SMTP server to send emails through it. For roaming users, this may need regularly changing the configuration of the SMTP client, since Falcot's SMTP server rejects messages coming from IP addresses apparently not belonging to the company. Two solutions exist: either the roaming user installs an SMTP server on their computer, or they still use the company server with some means of authenticating as an employee. The former solution is not recommended since the computer won't be permanently connected, and it won't be able to retry sending messages in case of problems; we will focus on the latter solution."
msgstr ""
msgid "SMTP authentication in Postfix relies on SASL (<emphasis>Simple Authentication and Security Layer</emphasis>). It requires installing the <emphasis role=\"pkg\">libsasl2-modules</emphasis> and <emphasis role=\"pkg\">sasl2-bin</emphasis> packages, then registering a password in the SASL database for each user that needs authenticating on the SMTP server. This is done with the <command>saslpasswd2</command> command, which takes several parameters. The <literal>-u</literal> option defines the authentication domain, which must match the <literal>smtpd_sasl_local_domain</literal> parameter in the Postfix configuration. The <literal>-c</literal> option allows creating a user, and <literal>-f</literal> allows specifying the file to use if the SASL database needs to be stored at a different location than the default (<filename>/etc/sasldb2</filename>)."
msgstr ""
msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean</userinput>\n"
"<computeroutput>[... type jean's password twice ...]</computeroutput>"
msgstr ""
msgid "Note that the SASL database was created in Postfix's directory. In order to ensure consistency, we also turn <filename>/etc/sasldb2</filename> into a symbolic link pointing at the database used by Postfix, with the <command>ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2</command> command."
msgstr ""
msgid "Now we need to configure Postfix to use SASL. First the <literal>postfix</literal> user needs to be added to the <literal>sasl</literal> group, so that it can access the SASL account database. A few new parameters are also needed to enable SASL, and the <literal>smtpd_recipient_restrictions</literal> parameter needs to be configured to allow SASL-authenticated clients to send emails freely."
msgstr ""
msgid "Enabling SASL in <filename>/etc/postfix/main.cf</filename>"
msgstr ""
msgid ""
"\n"
"# Enable SASL authentication\n"
"smtpd_sasl_auth_enable = yes\n"
"# Define the SASL authentication domain to use\n"
"smtpd_sasl_local_domain = $myhostname\n"
"[...]\n"
"# Adding permit_sasl_authenticated before reject_unauth_destination\n"
"# allows relaying mail sent by SASL-authenticated users\n"
"smtpd_recipient_restrictions = permit_mynetworks,\n"
" permit_sasl_authenticated,\n"
" reject_unauth_destination,\n"
"[...]"
msgstr ""
msgid "<emphasis>EXTRA</emphasis> Authenticated SMTP client"
msgstr ""
msgid "Most email clients are able to authenticate to an SMTP server before sending outgoing messages, and using that feature is a simple matter of configuring the appropriate parameters. If the client in use does not provide that feature, the workaround is to use a local Postfix server and configure it to relay email via the remote SMTP server. In this case, the local Postfix itself will be the client that authenticates with SASL. Here are the required parameters:"
msgstr ""
msgid ""
"\n"
"smtp_sasl_auth_enable = yes\n"
"smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd\n"
"relay_host = [mail.falcot.com]"
msgstr ""
msgid "The <filename>/etc/postfix/sasl_passwd</filename> file needs to contain the username and password to use for authenticating on the <literal>mail.falcot.com</literal> server. Here is an example:"
msgstr ""
msgid "\n"
"[mail.falcot.com] joe:LyinIsji"
msgstr ""
msgid "As for all Postfix maps, this file must be turned into <filename>/etc/postfix/sasl_passwd.db</filename> with the <command>postmap</command> command."
msgstr ""
msgid "Web Server (HTTP)"
msgstr ""
msgid "The Falcot Corp administrators decided to use the Apache HTTP server, included in Debian <emphasis role=\"distribution\">Jessie</emphasis> at version 2.4.10."
msgstr ""
msgid "<primary><command>apache</command></primary>"
msgstr ""
msgid "<primary>server</primary><secondary>web</secondary>"
msgstr ""
msgid "<primary>web server</primary>"
msgstr ""
msgid "<primary>server</primary><secondary>HTTP</secondary>"
msgstr ""
msgid "<primary>HTTP</primary><secondary>server</secondary>"
msgstr ""
msgid "<emphasis>ALTERNATIVE</emphasis> Other web servers"
msgstr ""
msgid "Apache is merely the most widely-known (and widely-used) web server, but there are others; they can offer better performance under certain workloads, but this has its counterpart in the smaller number of available features and modules. However, when the prospective web server is built to serve static files or to act as a proxy, the alternatives, such as <emphasis role=\"pkg\">nginx</emphasis> and <emphasis role=\"pkg\">lighttpd</emphasis>, are worth investigating."
msgstr ""
msgid "<primary><emphasis role=\"pkg\">nginx</emphasis></primary>"
msgstr ""
msgid "<primary><emphasis role=\"pkg\">lighttpd</emphasis></primary>"
msgstr ""
msgid "Installing Apache"
msgstr ""
msgid "Installing the <emphasis role=\"pkg\">apache2</emphasis> package is all that is needed. It contains all the modules, including the <emphasis>Multi-Processing Modules</emphasis> (MPMs) that affect how Apache handles parallel processing of many requests (those used to be provided in separate <emphasis role=\"pkg\">apache2-mpm-*</emphasis> packages). It will also pull <emphasis role=\"pkg\">apache2-utils</emphasis> containing the command line utilities that we will discover later."
msgstr ""
msgid "The MPM in use affects significantly the way Apache will handle concurrent requests. With the <emphasis>worker</emphasis> MPM, it uses <emphasis>threads</emphasis> (lightweight processes), whereas with the <emphasis>prefork</emphasis> MPM it uses a pool of processes created in advance. With the <emphasis>event</emphasis> MPM it also uses threads, but the inactive connections (notably those kept open by the HTTP <emphasis>keep-alive</emphasis> feature) are handed back to a dedicated management thread."
msgstr ""
msgid "The Falcot administrators also install <emphasis role=\"pkg\">libapache2-mod-php5</emphasis> so as to include the PHP support in Apache. This causes the default <emphasis>event</emphasis> MPM to be disabled, and <emphasis>prefork</emphasis> to be used instead, since PHP only works under that particular MPM."
msgstr ""
msgid "<emphasis>SECURITY</emphasis> Execution under the <literal>www-data</literal> user"
msgstr ""
msgid "<primary><literal>www-data</literal></primary>"
msgstr ""
msgid "<primary>suexec</primary>"
msgstr ""
msgid "By default, Apache handles incoming requests under the identity of the <literal>www-data</literal> user. This means that a security vulnerability in a CGI script executed by Apache (for a dynamic page) won't compromise the whole system, but only the files owned by this particular user."
msgstr ""
msgid "Using the <emphasis>suexec</emphasis> modules allows bypassing this rule so that some CGI scripts are executed under the identity of another user. This is configured with a <literal>SuexecUserGroup <replaceable>user</replaceable><replaceable>group</replaceable></literal> directive in the Apache configuration."
msgstr ""
msgid "<primary><emphasis role=\"pkg\">libapache2-mpm-itk</emphasis></primary>"
msgstr ""
msgid "Another possibility is to use a dedicated MPM, such as the one provided by <emphasis role=\"pkg\">libapache2-mpm-itk</emphasis>. This particular one has a slightly different behavior: it allows “isolating” virtual hosts (actually, sets of pages) so that they each run as a different user. A vulnerability in one website therefore cannot compromise files belonging to the owner of another website."
msgstr ""
msgid "<emphasis>QUICK LOOK</emphasis> List of modules"
msgstr ""
msgid "The full list of Apache standard modules can be found online. <ulink type=\"block\" url=\"http://httpd.apache.org/docs/2.4/mod/index.html\" />"
msgstr ""
msgid "Apache is a modular server, and many features are implemented by external modules that the main program loads during its initialization. The default configuration only enables the most common modules, but enabling new modules is a simple matter of running <command>a2enmod <replaceable>module</replaceable></command>; to disable a module, the command is <command>a2dismod <replaceable>module</replaceable></command>. These programs actually only create (or delete) symbolic links in <filename>/etc/apache2/mods-enabled/</filename>, pointing at the actual files (stored in <filename>/etc/apache2/mods-available/</filename>)."
msgstr ""
msgid "With its default configuration, the web server listens on port 80 (as configured in <filename>/etc/apache2/ports.conf</filename>), and serves pages from the <filename>/var/www/html/</filename> directory (as configured in <filename>/etc/apache2/sites-enabled/000-default.conf</filename>)."
msgstr ""
msgid "<emphasis>GOING FURTHER</emphasis> Adding support for SSL"
msgstr ""
msgid "<primary>HTTPS</primary>"
msgstr ""
msgid "<primary>HTTP</primary><secondary>secure</secondary>"
msgstr ""
msgid "Apache 2.4 includes the SSL module required for secure HTTP (HTTPS) out of the box. It just needs to be enabled with <command>a2enmod ssl</command>, then the required directives have to be added to the configuration files. A configuration example is provided in <filename>/etc/apache2/sites-available/default-ssl.conf</filename>. <ulink type=\"block\" url=\"http://httpd.apache.org/docs/2.4/mod/mod_ssl.html\" />"
msgstr ""
msgid "Some extra care must be taken if you want to favor SSL connections with <emphasis>Perfect Forward Secrecy</emphasis> (those connections use ephemeral session keys ensuring that a compromission of the server's secret key does not result in the compromission of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommandations in particular: <ulink type=\"block\" url=\"https://wiki.mozilla.org/Security/Server_Side_TLS#Apache\" />"
msgstr ""
msgid "<primary><emphasis>Perfect Forward Secrecy</emphasis></primary>"
msgstr ""
msgid "Configuring Virtual Hosts"
msgstr ""
msgid "A virtual host is an extra identity for the web server."
msgstr ""
msgid "<primary>virtual host</primary>"
msgstr ""
msgid "Apache considers two different kinds of virtual hosts: those that are based on the IP address (or the port), and those that rely on the domain name of the web server. The first method requires allocating a different IP address (or port) for each site, whereas the second one can work on a single IP address (and port), and the sites are differentiated by the hostname sent by the HTTP client (which only works in version 1.1 of the HTTP protocol — fortunately that version is old enough that all clients use it already)."
msgstr ""
msgid "The (increasing) scarcity of IPv4 addresses usually favors the second method; however, it is made more complex if the virtual hosts need to provide HTTPS too, since the SSL protocol hasn't always provided for name-based virtual hosting; the SNI extension (<emphasis>Server Name Indication</emphasis>) that allows such a combination is not handled by all browsers. When several HTTPS sites need to run on the same server, they will usually be differentiated either by running on a different port or on a different IP address (IPv6 can help there)."
msgstr ""
msgid "The default configuration for Apache 2 enables name-based virtual hosts. In addition, a default virtual host is defined in the <literal>/etc/apache2/sites-enabled/000-default.conf</literal> file; this virtual host will be used if no host matching the request sent by the client is found."
msgstr ""
msgid "<emphasis>CAUTION</emphasis> First virtual host"
msgstr ""
msgid "Requests concerning unknown virtual hosts will always be served by the first defined virtual host, which is why we defined <literal>www.falcot.com</literal> first here."
msgstr ""
msgid "<emphasis>QUICK LOOK</emphasis> Apache supports SNI"
msgstr ""
msgid "<primary>Server Name Indication</primary>"
msgstr ""
msgid "The Apache server supports an SSL protocol extension called <emphasis>Server Name Indication</emphasis> (SNI). This extension allows the browser to send the hostname of the web server during the establishment of the SSL connection, much earlier than the HTTP request itself, which was previously used to identify the requested virtual host among those hosted on the same server (with the same IP address and port). This allows Apache to select the most appropriate SSL certificate for the transaction to proceed."
msgstr ""
msgid "Before SNI, Apache would always use the certificate defined in the default virtual host. Clients trying to access another virtual host would then display warnings, since the certificate they received didn't match the website they were trying to access. Fortunately, most browsers now work with SNI; this includes Microsoft Internet Explorer starting with version 7.0 (starting on Vista), Mozilla Firefox starting with version 2.0, Apple Safari since version 3.2.1, and all versions of Google Chrome."
msgstr ""
msgid "The Apache package provided in Debian is built with support for SNI; no particular configuration is therefore needed."
msgstr ""
msgid "Care should also be taken to ensure that the configuration for the first virtual host (the one used by default) does enable TLSv1, since Apache uses the parameters of this first virtual host to establish secure connections, and they had better allow them!"
msgstr ""
msgid "Each extra virtual host is then described by a file stored in <filename>/etc/apache2/sites-available/</filename>. Setting up a website for the <literal>falcot.org</literal> domain is therefore a simple matter of creating the following file, then enabling the virtual host with <command>a2ensite www.falcot.org</command>."
msgstr ""
msgid "The <filename>/etc/apache2/sites-available/www.falcot.org.conf</filename> file"
msgstr ""
msgid ""
"\n"
"<VirtualHost *:80>\n"
"ServerName www.falcot.org\n"
"ServerAlias falcot.org\n"
"DocumentRoot /srv/www/www.falcot.org\n"
"</VirtualHost>"
msgstr ""
msgid "The Apache server, as configured so far, uses the same log files for all virtual hosts (although this could be changed by adding <literal>CustomLog</literal> directives in the definitions of the virtual hosts). It therefore makes good sense to customize the format of this log file to have it include the name of the virtual host. This can be done by creating a <filename>/etc/apache2/conf-available/customlog.conf</filename> file that defines a new format for all log files (with the <literal>LogFormat</literal> directive) and by enabling it with <command>a2enconf customlog</command>. The <literal>CustomLog</literal> line must also be removed (or commented out) from the <filename>/etc/apache2/sites-available/000-default.conf</filename> file."
msgstr ""
msgid "The <filename>/etc/apache2/conf.d/customlog.conf</filename> file"
msgstr ""
msgid ""
"\n"
"# New log format including (virtual) host name\n"
"LogFormat \"%v %h %l %u %t \\\"%r\\\" %>s %b \\\"%{Referer}i\\\" \\\"%{User-Agent}i\\\"\" vhost\n"
"\n"
"# Now let's use this \"vhost\" format by default\n"
"CustomLog /var/log/apache2/access.log vhost"
msgstr ""
msgid "Common Directives"
msgstr ""
msgid "This section briefly reviews some of the commonly-used Apache configuration directives."
msgstr ""
msgid "<primary>Apache directives</primary>"
msgstr ""
msgid "<primary>directives, Apache</primary>"
msgstr ""
msgid "The main configuration file usually includes several <literal>Directory</literal> blocks; they allow specifying different behaviors for the server depending on the location of the file being served. Such a block commonly includes <literal>Options</literal> and <literal>AllowOverride</literal> directives."
msgstr ""
msgid "<primary><literal>Options</literal>, Apache directive</primary>"
msgstr ""
msgid "<primary><literal>AllowOverride</literal>, Apache directive</primary>"
msgstr ""
msgid "Directory block"
msgstr ""
msgid ""
"\n"
"<Directory /var/www>\n"
"Options Includes FollowSymlinks\n"
"AllowOverride All\n"
"DirectoryIndex index.php index.html index.htm\n"
"</Directory>"
msgstr ""
msgid "The <literal>DirectoryIndex</literal> directive contains a list of files to try when the client request matches a directory. The first existing file in the list is used and sent as a response."
msgstr ""