/etc/postfix/main.cf.
mail.falcot.com. Dette er det eneste spørsmålet ved oppstart, men det gir et oppsett som ikke dekker behovene til Falcot. Derfor bruker administratorene dpkg-reconfigure postfix, slik at de kan tilpasse flere parametre.
localhost, men hoveddomenet falcot.com må legges inn for hånd. Som regel bør dette spørsmålet besvares med alle domenenavnene denne maskinen skal tjene som MX-tjener for; med andre ord, alle domenenavnene DNS sier at denne maskinen vil ta imot e-post for. Denne informasjonen ender opp i mydestination-variabelen i Postfixs hovedoppsettsfil - /etc/postfix/main.cf.
192.168.0.0/16 til det forvalgte svaret. Hvis dette spørsmålet ikke stilles, er den relevante variabelen i oppsettsfilen mynetworks, slik som i eksemplet nedenfor.
procmail. Med dette verktøyet kan brukere sortere sin innkommende e-post etter regler som hver enkelt bruker kan lagre i sin ~/.procmailrc-fil. Både Postfix og Exim4 foreslår procmail som forvalg, men det finnes alternativer som maildrop, eller Sieve-filtre.
Eksempel 11.1. Innledende /etc/postfix/main.cf-fil
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may
smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname
virtual_alias_domains-variabelen, og viser til en fil med adressetilordninger i virtual_alias_maps-variabelen.
virtual_alias_domains = falcotsbrand.com virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual beskriver en tilordning med en ganske grei syntaks: Hver linje inneholder to felter adskilt med mellomrom: Det første feltet er alias-navnet, det andre feltet en liste over e-postadresser det videresendes til. Den spesielle @domain.com-syntaksen dekker alle de andre aliasene innenfor et domene.
[email protected] [email protected] [email protected] [email protected], [email protected] # Aliaset nedenfor er generisk og dekker alle adresser i domenet # falcotsbrand.com som ikke finnes andre steder i denne filen. # Disse adressene videresender e-post til brukeren med samme # navn i domenet falcot.com. @falcotsbrand.com @falcot.com
/etc/postfix/virtual, må Postfix-tabellen i /etc/postfix/virtual.db oppdateres ved hjelp av sudo postmap /etc/postfix/virtual.
virtual_mailbox_domains-variabelen, og vise til en fil med postbokstilordninger i virtual_mailbox_maps. Parameteret virtual_mailbox_base inneholder katalogen der postboksene vil bli lagret.
virtual_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts
virtual_uid_maps (og det lignende parameteret virtual_gid_maps) viser til filen som inneholder tilordningen mellom e-postadressen og systembrukeren (henholdsvis gruppen) som «eier» den tilsvarende postboksen. Syntaksen static:5000 gir en fast UID/GID (med verdien 5000) for å sørge for at alle postbokser eies av samme eier/gruppe.
/etc/postfix/vmailbox-filen ganske enkel: To felt adskilt med mellomrom. Det første feltet er en e-postadresse i ett av de virtuelle domenene, og det andre feltet plasseringen av den tilhørende postboksen (i forhold til katalogen spesifisert i virtual_mailbox_base). Hvis postboksen ender med en skråstrek (/), blir e-postene lagret i maildir-formatet; ellers blir det tradisjonelle mbox-formatet brukt. Formatet maildir bruker en hel katalog for å lagre en postboks, det vil si at hver enkelt melding blir lagret i én fil. I mbox-formatet, derimot, lagres hele postboksen i én fil, og hver linje som starter med «From » (altså From fulgt av et mellomrom), signaliserer starten på en ny e-post.
# E-posten til Jean lagres i maildir-formatet, med # en fil per e-post i en egen katalog [email protected] falcot.org/jean/ # E-posten til Sophie lagres i en tradisjonell mbox-fil, # der alle e-postene legges etter hverandre i en enkelt fil [email protected] falcot.org/sophie
soft_bounce = ja direktivet er i bruk. Ved å forutse et avvisningsdirektiv med warn_if_reject registreres bare en loggmelding i stedet for å avvise forespørselen.
smtpd_client_restrictions styrer hvilke maskiner som får lov til å kommunisere med e-posttjeneren.
Eksempel 11.2. Restriksjoner basert på klientadresse
smtpd_client_restrictions =
permit_mynetworks,
warn_if_reject reject_unknown_client_hostname,
check_client_access hash:/etc/postfix/access_clientip,
reject_rhsbl_reverse_client dbl.spamhaus.org,
reject_rhsbl_reverse_client rhsbl.sorbs.net,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client dnsbl.sorbs.netpermit_mynetworks, brukt som første regel, godtar alle e-poster som kommer fra en maskin i det lokale nettverket (som definert av oppsettsvariabelen mynetworks).
warn_if_reject-modifikatoren til som forvalg for reject_unknown_client-direktivet: Denne modifikatoren gjør avslaget til en enkel advarsel registrert i loggen. Administratorene kan deretter holde et øye med antall meldinger som ville blitt avvist hvis regelen faktisk ble håndhevet, og ta en avgjørelse senere hvis de ønsker å muliggjøre slik håndheving.
check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.
HELO (eller EHLO)-kommando, etterfulgt av navnet på e-posttjeneren som utfører forsendelsen. Det kan være interessant å sjekke gyldigheten for dette navnet. For å fullt ut håndheve restriksjonene oppført i smtpd_helo_restrictions må alternativet smtpd_helo_required aktiveres. Ellers kan klienter hoppe over restriksjonene ved å ikke sende HELO/EHLO-kommandoen.
Eksempel 11.3. Restriksjoner på navnet som er meldt i EHLO
smtpd_helo_required = ja
smtpd_helo_restrictions =
permit_mynetworks,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
warn_if_reject reject_unknown_helo_hostname,
check_helo_access hash:/etc/postfix/access_helo,
reject_rhsbl_helo multi.surbl.orgpermit_mynetworks-direktivet tillater alle maskiner på det lokale nettverket å fritt legge seg til. Dette er viktig, fordi noen e-postprogrammer ikke respekterer denne delen av SMTP-protokollen godt nok, og kan legge seg til med meningsløse navn.
reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname 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 reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.
reject_rhsbl_helo gjør det mulig å angi en svarteliste for å kontrollere vertsnavnet mot en RHSBL.
permit_mynetworks som første regel har en interessant bieffekt: De påfølgende reglene gjelder kun verter utenfor det lokale nettverket. Dette tillater svartelisting av alle verter som varsler seg selv som en del av falcot.com-nettverket, for eksempel for å legge til en falcot.com REJECT You are not in our network!-linje til /etc/postfix/access_helo-filen.
MAIL FROM-kommandoen fra SMTP-protokollen; igjen, denne informasjonen kan bli validert på flere forskjellige måter.
Eksempel 11.4. Sjekking av sender
smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/access_sender,
reject_unknown_sender_domain,
reject_unlisted_sender,
reject_non_fqdn_sender,
reject_rhsbl_sender rhsbl.sorbs.net/etc/postfix/access_sender gir en noe spesiell behandling for noen avsendere. Dette betyr vanligvis å liste noen av avsenderne i en hviteliste eller en svarteliste.
reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from [email protected] are only accepted if such an address really exists.
reject_non_fqdn_sender-regelen avviser e-post som angivelig kommer fra adresser uten fullt kvalifisert domenenavn. I praksis betyr dette å avvise e-postmeldinger som kommer fra user@machine: Adressen må annonseres enten som [email protected], eller [email protected].
reject_rhsbl_sender-regelen avviser avsendere basert på en (domenebasert) RHSBL-tjeneste.
RCPT TO-kommandoen i SMTP-protokollen. Disse adressene garanterer også validering, selv om det kan være mindre relevant enn kontrollene av avsenderadressen.
Eksempel 11.5. Sjekk av mottager
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_unlisted_recipient,
reject_non_fqdn_recipient,
permitreject_unauth_destination er den grunnleggende regelen som krever at meldinger utenfra adresseres til oss; meldinger sendt til en adresse ikke betjent med denne tjeneren blir avvist. Uten denne regelen, blir tjeneren et åpent relé som tillater spammere å sende uønsket e-post. Denne regelen er derfor obligatorisk, og tas best inn nær begynnelsen av listen, slik at ingen andre regler kan autorisere meldingen før destinasjonen er kontrollert.
reject_unlisted_recipient avviser meldinger sendt til ikke-eksisterende lokale brukere, noe som gir mening. Til sist avslår reject_non_fqdn_recipient-regelen ikke-fullt-kvalifiserte adresser; dette gjør det umulig å sende e-post til jean, eller jean@machine, og krever bruk av hele adressen i stedet, som for eksempel [email protected], eller [email protected].
permit-direktiv ved slutten er ikke nødvendig. Men det kan være nyttig på slutten av en begrensningsliste for å gjøre forvalgt praksis eksplisitt.
DATA-kommandoen til SMTP avgis før innholdet i meldingen. Den gir ikke noen informasjon per se (av seg selv), bortsett fra å annonsere hva som kommer etterpå. Den kan fortsatt være underlagt sjekk.
reject_unauth_pipelining fører til at meldingen blir avvist hvis avsenderen sender en kommando før svaret på forrige kommando har blitt sendt. Dette beskytter mot en vanlig optimalisering som brukes av spamroboter, siden de vanligvis ikke bryr seg det grann om svar, og bare fokuserer på å sende så mange e-poster som fort som mulig.
RCPT TO-kommandoen som forvalg.
EHLO-kommando, kjenner Postfix avsenderen og mottakeren når avvisningen varsles. Den kan da logge et mer eksplisitt budskap enn om transaksjonen hadde blitt avbrutt fra starten. I tillegg trenger ikke en rekke SMTP-klienter å forvente feil med de tidlige SMTP-kommandoene, og disse klientene blir mindre forstyrret av dette ved denne senere avvisningen.
smtpd_delay_reject.
Eksempel 11.7. Aktivering av innholdsbaserte filtre
header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks
Eksempel 11.8. Eksempelfil /etc/postfix/header_checks
/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane) /^Subject: *Your email contains VIRUSES/ DISCARD virus notification
GOTO Sarbacane (en samling e-postprogramvare) blir funnet, blir meldingen avvist. Det andre uttrykket styrer meldingens emne; hvis det nevner et virusvarsel, kan vi bestemme oss for ikke å avvise meldingen, men straks å forkaste den istedenfor.
check_policy_service-parameteret som ekstra begrensning:
smtpd_recipient_restrictions =
permit_mynetworks,
[...]
check_policy_service inet:127.0.0.1:10023postgrey 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.
smtpd_restriction_classes-parametret, og defineres på samme måten som smtpd_recipient_restrictions. Direktivet check_recipient_access definerer deretter en tabell som legger en gitt mottaker til det riktige settet restriksjoner.
Eksempel 11.9. Definering av begrensningsklasser i main.cf
smtpd_restriction_classes = greylisting, aggressive, permissive
greylisting = check_policy_service inet:127.0.0.1:10023
aggressive =
reject_rbl_client sbl-xbl.spamhaus.org,
check_policy_service inet:127.0.0.1:10023
permissive = permit
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
check_recipient_access hash:/etc/postfix/recipient_accessEksempel 11.10. Filen /etc/postfix/recipient_access
# Adresser som ikke filtreres [email protected] permissive [email protected] permissive [email protected] permissive # Aggressiv filtrering for noen privilegerte brukere [email protected] aggressive # Spesialregel for den som styrer e-postlisten [email protected] reject_unverified_sender # Grålisting som forvalg falcot.com greylisting
clamav fra homonymous-pakken.
clamav-milter. Et milter (kort for e-postfilter (mail filter)) er et filterprogram spesielt utviklet for å kommunisere med e-posttjenere. Et milter bruker et standard programmeringsgrensesnitt (API) som gir mye bedre ytelse enn eksterne e-posttjenerfiltre. Milters ble først introdusert av Sendmail, men Postfix kom snart etter.
dpkg-reconfigure clamav-milter. Når du blir bedt om «Kommunikasjonsgrensesnitt med Sendmail», svar «inet:[email protected]».
dpkg-reconfigure clamav-base.
/etc/postfix/main.cf:
# Virus-sjekk med ClamAV-milter smtpd_milters = inet:[127.0.0.1]:10002
systemctl reload postfix skal kjøres slik at denne endringen er tatt hensyn til.
include directive it must have one.
Name: example.org Type: TXT TTL: 3600 Data: v=spf1 a mx -all
falcot.org-oppføringen.
#host -t TXT falcot.orgfalcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"
postfix e-posttjeneren kan sjekke SPF-oppføringen for innkommende e-postmeldinger ved hjelp av postfix-policyd-spf-python-pakken, en regelagent skrevet i Python. Filen /usr/share/doc/postfix-policyd-spf-python/README.Debian beskriver de nødvendige trinnene for å integrere agenten i postfix, så vi vil ikke repetere det her.
/etc/postfix-policyd-spf-python/policyd-spf.conf, som er dokumentert i sin helhet i policyd-spf.conf(5) og /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Hovedoppsettsparameterne er HELO_reject og Mail_From_reject, som setter opp om e-postmeldinger skal avvises (Fail) eller akseptert med en topptekst som legges til (False), hvis kontroller mislykkes. Sistnevnte er ofte nyttig, når meldingen behandles videre av et søppelpostfilter.
Header_Type settes til AR.
postfix, legger til en digital signatur tilknyttet domenenavnet til hodet på en utgående e-postmeldinger. Den mottagende part kan validere meldingstekst- og hodefeltene ved å kontrollere signaturen mot en offentlig nøkkel, som hentes fra avsenderens DNS-oppføringer.
opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR som må være et unikt navn for nøkkelen. Det kan være så enkelt som "e-post", eller opprettelsesdatoen, hvis du planlegger å rotere nøkler.
Eksempel 11.11. Opprettelse av privat nøkkel for signering av e-post fra falcot.com
#opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys#chown opendkim.opendkim /etc/dkimkeys/mail.*
/etc/dkimkeys/mail.private og /etc/dkimkeys/mail.txt og sette riktig eierskap. Den første filen inneholder den private nøkkelen. Sistnevnte inneholder den offentlige nøkkelen, som må legges til i DNS:
Name: mail._domainkey Type: TXT TTL: 3600 Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"
-b 1024 for å velge en mindre nøkkelstørrelse. Hvis opendkim-testkey lykkes, er oppføringen opprettet. Syntaksen for oppføringen er forklart her:
SOCKET og RUNDIR velges i /etc/default/opendkim. Vær oppmerksom på at SOCKET må være tilgjengelig fra postfix i sitt chroot-ede miljø. Det videre oppsettet gjøres i /etc/opendkim.conf. Følgende er et utdrag av oppsettet, som sørger for at Domain "falcot.com" og alle underdomener (SubDomain) er signert av Selector "mail" og den enkle private nøkkelen (KeyFile) /etc/dkimkeys/mail.private. Den "avslappete" Canonicalization for både overskriften og kroppen tåler mild endring (for eksempel av en postlistelisteprogramvare). Filteret kjører både ved signering ("s") og verifisering ("v") Mode. Hvis en signatur ikke valideres (On-BadSignature), skal e-posten settes i karantene ("q").
[...] Domain falcot.com KeyFile /etc/dkimkeys/mail.private Selector mail [...] Canonicalization relaxed/relaxed Mode sv On-BadSignature q SubDomains yes [...] Socket inet:12345@localhost [...] UserID opendkim
KeyTable), domener (SigningTable) og angi interne eller klarerte verter (InternalHosts, ExternalIgnoreList), som kan sende e-post via tjeneren som ett av signeringsdomenene uten legitimering.
/etc/postfix/main.cf sørger for at postfix bruker filteret:
milter_default_action = accept non_smtpd_milters = inet:localhost:12345 smtpd_milters = inet:localhost:12345
/etc/postfix/master.cf i stedet.
/usr/share/doc/opendkim/ og i manualsidene opendkim(. 8) og opendkim.conf(5).
_dmarc og informasjon om handlingen som bør utføres når e-postmeldinger, som inneholder domenet ditt som avsendervert, ikke klarer å validere ved hjelp av DKIM og SPF.
#host -t TXT _dmarc.gmail.com_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]"#host -t TXT _dmarc.yahoo.com_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected];"
avvise alle e-postmeldinger som utgir seg for å bli sendt fra en Yahoo-konto, men mangler eller mislykkes med DKIM og SPF sjekker. Google Mail (Gmail) har en svært avslappet policy, der slike meldinger fra hoveddomenet fortsatt skal aksepteres (p=none). For underdomener bør de merkes som spam (sp=quarantine). Adressene som er oppgitt i rua-nøkkelen, kan brukes til å sende aggregerte DMARC-rapporter også. Den fullstendige syntaksen er forklart her:
postfix kan også bruke denne informasjonen. Pakken opendmarc inneholder det nødvendige e-postfilter. I likhet med for opendkim må SOCKET og RUNDIR velges i /etc/default/opendmarc (for Unix sockets må du sørge for at de er inne i postfix chrootet for å bli funnet). Oppsettfilen /etc/opendmarc.conf inneholder detaljerte kommentarer og er også forklart i opendmarc.conf(5). I utgangspunktet avvises ikke e-postmeldinger som ikke klarer DMARC-valideringen, men flagges, ved å legge til et passende hodefelt. Hvis du vil endre dette, kan du bruke RejectFailures true.
smtpd_milters og non_smtpd_milters. Hvis vi satte opp opendkim og opendmarc e-postfiltreret til å kjøre på porter 12345 og 54321, ser oppføringen i /etc/postfix/main.cf slik ut:
non_smtpd_milters = inet:localhost:12345,inet:localhost:54321 smtpd_milters = inet:localhost:12345,inet:localhost:54321
/etc/postfix/master.cf i stedet.
saslpasswd2-kommandoen, som krever flere parametre. Valget -u definerer godkjenningsdomenet, som må samsvare med smtpd_sasl_local_domain-parameteret i Postfix-oppsettet. Valget -c tillater å lage en bruker, og -f kan spesifisere filen som skal brukes hvis SASL-databasen må lagres på et annet sted enn opprinnelig (/etc/sasldb2).
#saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean[... skriv inn passordet til jean to ganger ...]
/etc/sasldb2 til en symbolsk lenke som peker på databasen som brukes av Postfix, med ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2-kommandoen.
postfix-brukeren legges til sasl-gruppen, slik at den kan få tilgang til SASL-kontoens database. Et par nye parametere må også til for å aktivere SASL, og smtpd_recipient_restrictions-parameteret må settes opp til å tillate at SASL-godkjente klienter fritt kan sende e-post.
Eksempel 11.12. Oppsett av SASL i /etc/postfix/main.cf
# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
[...]/etc/postfix/master.cf. Hvis du vil deaktivere godkjenning i det hele tatt for port 25 (smtpd-tjenesten), legger du til følgende direktiv:
smtp inet n - y - - smtpd
[..]
-o smtpd_sasl_auth_enable=no
[..]
AUTH command (some very old mail clients do), interoperability with them can be enabled using the broken_sasl_auth_clients directive.