Das schlimmste, was uns passieren kann, wäre der Betrieb eines offenen Mailrelais gefolgt von einem Mailserver der sich beharrlich weigert eMails anzunehmen, zu versenden und weiterzuleiten. Mit unserer Grundinstallation haben wir schon mal den wichtigsten Part Mailrelay mit den Definitionen in der main.cf erschlagen und sichergestellt, dass kein Fremder Nachrichten an Dritte verschickt, für die unser MX sich nicht zuständig und verantwortlich fühlt.
Auch wurde der Versand unserer eMail bereits entsprechend berücksichtigt.
Damit aber nun unser Mailserver nicht jeden Dreck - aka SPAM & Co - annimmt und auch versendet, definieren wir uns nun ein Regelwerk, mit Hilfe dessen wir festlegen, wann unser Server Mails annehmen oder ablehnen soll. Diese Festlegungen erfolgt mit Hilfe der Restrictions.
Der entscheidenste Moment, an dem wir nicht nur SPAM sondern auch all die anderen unerwünschten Nachrichten abzuwehren, ist der Einlieferungszeitpunkt! Was wir nicht annehmen brauchen wir auch später nicht weiterverarbeiten bzw. beachten. Analog dem Briefverkehr legen wir quasi fest, welche Sendungen überhaupt in unseren Briefkasten geworfen werden können und dürfen.
Wie bereits auch schon bei der Grundkonfiguration wurden die wichtigsten Details mit Hilfe der Postfix-Bibel erarbeitet, bzw. den dortigen Beispielen entnommen. Die Bemerkungen in den nachfolgenden Restriction-Definitionen verweisen auf einzelne Kapitel im Buch!
Bevor wir uns nun die einzelnen Konfigurationsdateien ansehen, werfen wir noch einen Blick in die nachfolgende Übersicht um festzustellen, wann die einzelnen Restriction-Tables in der Mailbearbeitung gezogen werden, also überhaupt einen Einfluß haben.
Die nachfolgenden Lookup-Tabelle greift lediglich, wenn die eMails per SMTP beim smtpd-Modul eingeliefert werden. Bei lokal zugestellten Nachrichten, die beim pickup-Modul eingeliefert werden, greifen diese Tabellen nicht!
Nachfolgende Definitionen fügen wir nun am Ende der /etc/postfix/main.cf ein. Hierzu benutzen wir wie immer den Editor unserer Wahl.
# vim /etc/postfix/main.cf
# # Schutz durch Restrictions für unser SOHO # Eingetragen am 2008-10-05 # smtpd_recipient_restrictions = # Postmaster, abuse und andere aufgaben- oder funktionsgebundene E-Mail-Adressen (Role-Accounts) whitelisten check_recipient_access btree:/etc/postfix/access_recipient-rfc, # Black- und Whitelisting (Kapitel 8.2.3 White- und Blacklisting) check_client_access cidr:/etc/postfix/access_client, check_helo_access btree:/etc/postfix/access_helo, check_sender_access btree:/etc/postfix/access_sender, check_recipient_access btree:/etc/postfix/access_recipient, # Unsauberer eMails nicht annehmen (Kapitel 8.2.4 Anforderungen an Mailadressen) reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, # Unsere eigenen Nutzer zulassen-/erlauben (Kapitel 8.2.2 Relaying erlauben und verbieten) permit_sasl_authenticated, permit_tls_clientcerts, permit_mynetworks, # RBL überprüfen (Kapitel 10.11 Realtime Blackhole Lists) reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.njabl.org, reject_rhsbl_client multi.uribl.com, # Dynamische Prüfung auf existente Relay-Empfänger (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung) # reject_unverified_recipient, # Backupserver (MX) erlauben # permit_mx_backup, # alles andere an relaying verbieten (Kapitel 8.2.2 Relaying erlauben und verbieten) reject_unauth_destination, # Zu guter Letzt alles durchlassen, was bis jetzt noch nicht beanstandet wurde permit
Bei den Lookup-Tabellen verwenden wir das performantere btree-Tabellenformat .
Damit wir später unsere Datenbankfiles einfach durch den Aufruf
# postmap <lookup-table>
anlegen können, setzen wir noch den Wert default_database_type auf btree. Anderen Falls müssten wir bei jedem Aufruf von postmap den Datenbanktabellentyp mit angeben!
# postmap btree:<lookup-table>
Hierzu tragen wir in die main.cf noch nachfolgende Zeilen ein.
# vim /etc/postfix/main.cf
# Django : 2012-02-06 # default default_database_type = hash # default Datenbank Typ auf das performantere btree umgestellt default_database_type = btree
Für jede der vorgenannten Restriction-Regeln benötigen wir nun eine passende Lookup-Tabelle. Nachfolgend betrachten wir nun die einzelnen Dateien und gehen kurz auf die Bedeutung und deren Möglichkeiten ein.
In unserem Konfigurationsverzeichnis /etc/postfix/ finden wir die Manpage für die access - Postfix SMTP server access table.
# less /etc/postfix/access
# ACCESS(5) ACCESS(5) # # NAME # access - Postfix SMTP server access table # # SYNOPSIS # postmap /etc/postfix/access # # postmap -q "string" /etc/postfix/access # # postmap -q - /etc/postfix/access <inputfile # # DESCRIPTION # This document describes access control on remote SMTP # client information: host names, network addresses, and # envelope sender or recipient addresses; it is implemented # by the Postfix SMTP server. See header_checks(5) or # body_checks(5) for access control on the content of email # messages. # # Normally, the access(5) table is specified as a text file # that serves as input to the postmap(1) command. The # result, an indexed file in dbm or db format, is used for # fast searching by the mail system. Execute the command # "postmap /etc/postfix/access" to rebuild an indexed file # after changing the corresponding text file. # # When the table is provided via other means such as NIS, # LDAP or SQL, the same lookups are done as for ordinary # indexed files. # # Alternatively, the table can be provided as a regular- # expression map where patterns are given as regular expres- # sions, or lookups can be directed to TCP-based server. In # those cases, the lookups are done in a slightly different # way as described below under "REGULAR EXPRESSION TABLES" # or "TCP-BASED TABLES". # # CASE FOLDING # The search string is folded to lowercase before database # lookup. As of Postfix 2.3, the search string is not case # folded with database types such as regexp: or pcre: whose # lookup fields can match both upper and lower case. # # TABLE FORMAT # The input format for the postmap(1) command is as follows: # # pattern action # When pattern matches a mail address, domain or host # address, perform the corresponding action. # # blank lines and comments # Empty lines and whitespace-only lines are ignored, # as are lines whose first non-whitespace character # is a `#'. # # multi-line text # A logical line starts with non-whitespace text. A # line that starts with whitespace continues a logi- # cal line. # # EMAIL ADDRESS PATTERNS # With lookups from indexed files such as DB or DBM, or from # networked tables such as NIS, LDAP or SQL, patterns are # tried in the order as listed below: # # user@domain # Matches the specified mail address. # # domain.tld # Matches domain.tld as the domain part of an email # address. # # The pattern domain.tld also matches subdomains, but # only when the string smtpd_access_maps is listed in # the Postfix parent_domain_matches_subdomains con- # figuration setting (note that this is the default # for some versions of Postfix). Otherwise, specify # .domain.tld (note the initial dot) in order to # match subdomains. # # user@ Matches all mail addresses with the specified user # part. # # Note: lookup of the null sender address is not possible # with some types of lookup table. By default, Postfix uses # <> as the lookup key for such addresses. The value is # specified with the smtpd_null_access_lookup_key parameter # in the Postfix main.cf file. # # EMAIL ADDRESS EXTENSION # When a mail address localpart contains the optional recip- # ient delimiter (e.g., user+foo@domain), the lookup order # becomes: user+foo@domain, user@domain, domain, user+foo@, # and user@. # # HOST NAME/ADDRESS PATTERNS # With lookups from indexed files such as DB or DBM, or from # networked tables such as NIS, LDAP or SQL, the following # lookup patterns are examined in the order as listed: # # domain.tld # Matches domain.tld. # # The pattern domain.tld also matches subdomains, but # only when the string smtpd_access_maps is listed in # the Postfix parent_domain_matches_subdomains con- # figuration setting. Otherwise, specify .domain.tld # (note the initial dot) in order to match subdo- # mains. # # net.work.addr.ess # # net.work.addr # # net.work # # net Matches the specified IPv4 host address or subnet- # work. An IPv4 host address is a sequence of four # decimal octets separated by ".". # # Subnetworks are matched by repeatedly truncating # the last ".octet" from the remote IPv4 host address # string until a match is found in the access table, # or until further truncation is not possible. # # NOTE 1: The access map lookup key must be in canon- # ical form: do not specify unnecessary null charac- # ters, and do not enclose network address informa- # tion with "[]" characters. # # NOTE 2: use the cidr lookup table type to specify # network/netmask patterns. See cidr_table(5) for # details. # # net:work:addr:ess # # net:work:addr # # net:work # # net Matches the specified IPv6 host address or subnet- # work. An IPv6 host address is a sequence of three # to eight hexadecimal octet pairs separated by ":". # # Subnetworks are matched by repeatedly truncating # the last ":octetpair" from the remote IPv6 host # address string until a match is found in the access # table, or until further truncation is not possible. # # NOTE 1: the truncation and comparison are done with # the string representation of the IPv6 host address. # Thus, not all the ":" subnetworks will be tried. # # NOTE 2: The access map lookup key must be in canon- # ical form: do not specify unnecessary null charac- # ters, and do not enclose network address informa- # tion with "[]" characters. # # NOTE 3: use the cidr lookup table type to specify # network/netmask patterns. See cidr_table(5) for # details. # # IPv6 support is available in Postfix 2.2 and later. # # ACCEPT ACTIONS # OK Accept the address etc. that matches the pattern. # # all-numerical # An all-numerical result is treated as OK. This for- # mat is generated by address-based relay authoriza- # tion schemes such as pop-before-smtp. # # REJECT ACTIONS # Postfix version 2.3 and later support enhanced status # codes as defined in RFC 3463. When no code is specified # at the beginning of the text below, Postfix inserts a # default enhanced status code of "5.7.1" in the case of # reject actions, and "4.7.1" in the case of defer actions. # See "ENHANCED STATUS CODES" below. # # 4NN text # # 5NN text # Reject the address etc. that matches the pattern, # and respond with the numerical three-digit code and # text. 4NN means "try again later", while 5NN means # "do not try again". # # The following responses have special meaning for # the Postfix SMTP server: # # 421 text (Postfix 2.3 and later) # # 521 text (Postfix 2.6 and later) # After responding with the numerical three- # digit code and text, disconnect immediately # from the SMTP client. This frees up SMTP # server resources so that they can be made # available to another SMTP client. # # Note: The "521" response should be used only # with botnets and other malware where inter- # operability is of no concern. The "send 521 # and disconnect" behavior is NOT defined in # the SMTP standard. # # REJECT optional text... # Reject the address etc. that matches the pattern. # Reply with "$access_map_reject_code optional # text..." when the optional text is specified, oth- # erwise reply with a generic error response message. # # DEFER optional text... # Reject the address etc. that matches the pattern. # Reply with "$access_map_defer_code optional # text..." when the optional text is specified, oth- # erwise reply with a generic error response message. # # This feature is available in Postfix 2.6 and later. # # DEFER_IF_REJECT optional text... # Defer the request if some later restriction would # result in a REJECT action. Reply with # "$access_map_defer_code 4.7.1 optional text..." # when the optional text is specified, otherwise # reply with a generic error response message. # # Prior to Postfix 2.6, the SMTP reply code is 450. # # This feature is available in Postfix 2.1 and later. # # DEFER_IF_PERMIT optional text... # Defer the request if some later restriction would # result in a an explicit or implicit PERMIT action. # Reply with "$access_map_defer_code 4.7.1 optional # text..." when the optional text is specified, oth- # erwise reply with a generic error response message. # # Prior to Postfix 2.6, the SMTP reply code is 450. # # This feature is available in Postfix 2.1 and later. # # OTHER ACTIONS # restriction... # Apply the named UCE restriction(s) (permit, reject, # reject_unauth_destination, and so on). # # BCC user@domain # Send one copy of the message to the specified # recipient. # # If multiple BCC actions are specified within the # same SMTP MAIL transaction, only the last action # will be used. # # This feature is not part of the stable Postfix # release. # # DISCARD optional text... # Claim successful delivery and silently discard the # message. Log the optional text if specified, oth- # erwise log a generic message. # # Note: this action currently affects all recipients # of the message. To discard only one recipient # without discarding the entire message, use the # transport(5) table to direct mail to the discard(8) # service. # # This feature is available in Postfix 2.0 and later. # # DUNNO Pretend that the lookup key was not found. This # prevents Postfix from trying substrings of the # lookup key (such as a subdomain name, or a network # address subnetwork). # # This feature is available in Postfix 2.0 and later. # # FILTER transport:destination # After the message is queued, send the entire mes- # sage through the specified external content filter. # The transport:destination syntax is described in # the transport(5) manual page. More information # about external content filters is in the Postfix # FILTER_README file. # # Note: this action overrides the content_filter set- # ting, and currently affects all recipients of the # message. # # This feature is available in Postfix 2.0 and later. # # HOLD optional text... # Place the message on the hold queue, where it will # sit until someone either deletes it or releases it # for delivery. Log the optional text if specified, # otherwise log a generic message. # # Mail that is placed on hold can be examined with # the postcat(1) command, and can be destroyed or # released with the postsuper(1) command. # # Note: use "postsuper -r" to release mail that was # kept on hold for a significant fraction of $maxi- # mal_queue_lifetime or $bounce_queue_lifetime, or # longer. Use "postsuper -H" only for mail that will # not expire within a few delivery attempts. # # Note: this action currently affects all recipients # of the message. # # This feature is available in Postfix 2.0 and later. # # PREPEND headername: headervalue # Prepend the specified message header to the mes- # sage. When more than one PREPEND action executes, # the first prepended header appears before the sec- # ond etc. prepended header. # # Note: this action must execute before the message # content is received; it cannot execute in the con- # text of smtpd_end_of_data_restrictions. # # This feature is available in Postfix 2.1 and later. # # REDIRECT user@domain # After the message is queued, send the message to # the specified address instead of the intended # recipient(s). # # Note: this action overrides the FILTER action, and # currently affects all recipients of the message. # # This feature is available in Postfix 2.1 and later. # # WARN optional text... # Log a warning with the optional text, together with # client information and if available, with helo, # sender, recipient and protocol information. # # This feature is available in Postfix 2.1 and later. # # ENHANCED STATUS CODES # Postfix version 2.3 and later support enhanced status # codes as defined in RFC 3463. When an enhanced status # code is specified in an access table, it is subject to # modification. The following transformations are needed # when the same access table is used for client, helo, # sender, or recipient access restrictions; they happen # regardless of whether Postfix replies to a MAIL FROM, RCPT # TO or other SMTP command. # # o When a sender address matches a REJECT action, the # Postfix SMTP server will transform a recipient DSN # status (e.g., 4.1.1-4.1.6) into the corresponding # sender DSN status, and vice versa. # # o When non-address information matches a REJECT # action (such as the HELO command argument or the # client hostname/address), the Postfix SMTP server # will transform a sender or recipient DSN status # into a generic non-address DSN status (e.g., # 4.0.0). # # REGULAR EXPRESSION TABLES # This section describes how the table lookups change when # the table is given in the form of regular expressions. For # a description of regular expression lookup table syntax, # see regexp_table(5) or pcre_table(5). # # Each pattern is a regular expression that is applied to # the entire string being looked up. Depending on the appli- # cation, that string is an entire client hostname, an # entire client IP address, or an entire mail address. Thus, # no parent domain or parent network search is done, # user@domain mail addresses are not broken up into their # user@ and domain constituent parts, nor is user+foo broken # up into user and foo. # # Patterns are applied in the order as specified in the ta- # ble, until a pattern is found that matches the search # string. # # Actions are the same as with indexed file lookups, with # the additional feature that parenthesized substrings from # the pattern can be interpolated as $1, $2 and so on. # # TCP-BASED TABLES # This section describes how the table lookups change when # lookups are directed to a TCP-based server. For a descrip- # tion of the TCP client/server lookup protocol, see tcp_ta- # ble(5). This feature is not available up to and including # Postfix version 2.4. # # Each lookup operation uses the entire query string once. # Depending on the application, that string is an entire # client hostname, an entire client IP address, or an entire # mail address. Thus, no parent domain or parent network # search is done, user@domain mail addresses are not broken # up into their user@ and domain constituent parts, nor is # user+foo broken up into user and foo. # # Actions are the same as with indexed file lookups. # # EXAMPLE # The following example uses an indexed file, so that the # order of table entries does not matter. The example per- # mits access by the client at address 1.2.3.4 but rejects # all other clients in 1.2.3.0/24. Instead of hash lookup # tables, some systems use dbm. Use the command "postconf # -m" to find out what lookup tables Postfix supports on # your system. # # /etc/postfix/main.cf: # smtpd_client_restrictions = # check_client_access hash:/etc/postfix/access # # /etc/postfix/access: # 1.2.3 REJECT # 1.2.3.4 OK # # Execute the command "postmap /etc/postfix/access" after # editing the file. # # BUGS # The table format does not understand quoting conventions. # # SEE ALSO # postmap(1), Postfix lookup table manager # smtpd(8), SMTP server # postconf(5), configuration parameters # transport(5), transport:nexthop syntax # # README FILES # Use "postconf readme_directory" or "postconf html_direc- # tory" to locate this information. # SMTPD_ACCESS_README, built-in SMTP server access control # DATABASE_README, Postfix lookup table overview # # LICENSE # The Secure Mailer license must be distributed with this # software. # # AUTHOR(S) # Wietse Venema # IBM T.J. Watson Research # P.O. Box 704 # Yorktown Heights, NY 10598, USA # # ACCESS(5)
Wir editieren nun aber nicht diese Vorlage- und Musterdateien, sondern legen uns für die einzelnen Anwendungsfälle eigene Dateien an, auch wenn diese eventuell erst einmal ohne Inhalt sind. Wir haben so später kein Problem mehr, wenn wir ad hoc auf eine Anforderung schnell reagieren müssen.
Bei den einzelnen folgenden Access-Tabellen stehen uns folgende Access-Aktionen zur Verfügung:
| Steuerwort | Ergebnis |
|---|---|
| OK | Die Anfrage wird zugelassen |
| BCCuser@domäne.tld | Sendet die empfangene eMail an einen gesonderten Empfänger als Blindcopy bcc |
| DEFER_IF_REJECT | Wenn ein nachfolgender Test einen fatalen REJECT liefern würde, wird an den Client ein temporärer Fehler (4xx) signalisiert. |
| DEFER_IF_PERMIT | Signalisiert an den Client einen temporären Fehler (4xx), obwohl die eMail sonst angenommen worden wäre. |
| DISCARD | Die eMail wird für alle Empfänger verworfen, sobald nur ein einzelner Empfänger diesen DISCARD auslöst! Dem einliefernden Client wird eine erfolgreiche Zustellung signalisiert. |
| DUNNO | Die Anfrage wird nicht abgelehnt, liefert jedoch auch kein ausdrückliches OK zurück. Die Access-Prüfung wird beendet - weitere Prüfungen können jedoch nich erfolgen. |
| FILTERnexthop | Routet die eMail an nexthop und überschreibt dabei die Einstellung content_Filter |
| HOLD | Nimmt die eMail entgegen und stellt diese in die hold-Queue |
| PREPENDMailheader:Wert | Fügt in den Mailheader der eMail den Mailheader:Wert ein. |
| REDIRECTuser@domäne.tld | Leitet die eMail an die neue eMail-Adresse um und verwirft dabei alle anderen angegebenen Empfänger! |
| REJECT | Die Anfrage wird mit einem fatalen Fehlercode 5xx abgelehnt |
| REJECTHinweistext | Die Anfrage wird abgelehnt und der Text Hinweistext ausgegeben |
| 4xxHinweistext | Die Anfrage wird mit einem temporären Fehlercode 4xx und dem Text Hinweistext abgelehnt |
| 5xxHinweistext | Die Anfrage wird mit einem fatalen Fehlercode 5xx und dem Text Hinweistext abgelehnt |
| WARNHinweistext | Im Maillog des Mailservers wird ein Logeintrag mit den Informationen: - Absender - Empfänger - HELO - etc. zusammen mit dem Hinweistext eingefügt. |
# vim /etc/postfix/access_client
# Django : 2012-02-06 # Kapitel 5.2.7 access-Tabelle: Wer darf, wer darf nicht? # Tabelle zum black- und whitelisten einzelner Hosts auf Basis ihrer IP-Adressen # nach dem Ändern und/oder Erweitern der Tabelle, muß ein laufender Postfix über die Änderungen # mit einem reload informiert werden. Es muss hier keine Datenbank mit postmap erzeugt werden, da # Postfix die ASCII-Konfigurationsdatei direkt auswertet! #
# vim /etc/postfix/access_helo
# Django : 2012-02-06 # Kapitel 5.2.7 access-Tabelle: Wer darf, wer darf nicht? # Tabelle zum black- und whitelisten einzelner Hosts auf Grund seines HELO-Namens # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/access_helo # die zugehörige Datenbank erzeugt werden. #
# vim /etc/postfix/access_recipient-rfc
# Django : 2012-02-06 # Postmaster, abuse und andere aufgaben- oder funktionsgebundene E-Mail-Adressen (Role-Accounts) whitelisten. # Nach dem Ändern und/oder Erweiterrn der Tabelle, muß noch mittels $ postmap /etc/postfix/access_recipient-rfc # die zugehörige Datenbank erzeugt werden. abuse@ OK postmaster@ OK
# vim /etc/postfix/access_recipient
# Django : 2012-02-06 # Kapitel 5.2.7 access-Tabelle: Wer darf, wer darf nicht? # Tabelle zum black- und whitelisten einzelne Empfänger auf Basis ihrer eMail-Adresse # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/access_recipient # die zugehörige Datenbank erzeugt werden. #
# vim /etc/postfix/access_sender
# Django : 2012-02-06 # Kapitel 5.2.7 access-Tabelle: Wer darf, wer darf nicht? # Tabelle zum black- und whitelisten einzelner Absender auf Basis ihrer eMail-Adresse # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/access_sender # die zugehörige Datenbank erzeugt werden. #
Zur Nutzung der nachfolgenden Lookup-Tabellen ergänzen wir nun die Konfigurationsdatei main.cf unseres Postfix-Mailservers.
# vim /etc/postfix/main.cf
# Django : 2012-02-06 # Lookup-Tabelle zum Umschreibungen von Absender eMail-Adressen im SMTP-Envelop und im Header der eMail sender_canonical_maps = btree:/etc/postfix/sender_canonical_maps # # Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail recipient_canonical_maps = btree:/etc/postfix/recipient_canonical_maps # # Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail # das Umschreiben erfolgt beim Verlassen des Systems via LMTP lmtp_generic_maps = btree:/etc/postfix/lmtp_generic_maps # # Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail # das Umschreiben erfolgt beim Verlassen des Systems via SMTP smtp_generic_maps = btree:/etc/postfix/smtp_generic_maps # # Lookup-Tabelle zum Aktivieren einer alternativen Mailrouting bei der Zustellung an einen weiteren Mailserver transport_maps = btree:/etc/postfix/transport_maps # # Lookup-Tabelle zum Aktivieren von "Bounce-Nachrichten" an den Absender einer eMail über nicht existierende # eMailadressen mit Angabe der neu zu nutzenden eMailadresse des Empfängers relocated_maps = btree:/etc/postfix/relocated_maps # # Lookup-Tabelle zum Verwalten der virtuellen Domains virtual_alias_domains = btree:/etc/postfix/virtual_alias_domains # # Lookup-Tabelle zum Verwalten der virtuellen eMail-Adressen virtual_alias_maps = btree:/etc/postfix/virtual_alias_maps
# vim /etc/aliases
# # Aliases in this file will NOT be expanded in the header from # Mail, but WILL be visible over networks or from /bin/mail. # # >>>>>>>>>> The program "newaliases" must be run after # >> NOTE >> this file is updated for any changes to # >>>>>>>>>> show through to sendmail. # # Basic system aliases -- these MUST be present. mailer-daemon: postmaster postmaster: root # General redirections for pseudo accounts. bin: root daemon: root adm: root lp: root sync: root shutdown: root halt: root mail: root news: root uucp: root operator: root games: root gopher: root ftp: root nobody: root radiusd: root nut: root dbus: root vcsa: root canna: root wnn: root rpm: root nscd: root pcap: root apache: root webalizer: root dovecot: root fax: root quagga: root radvd: root pvm: root amanda: root privoxy: root ident: root named: root xfs: root gdm: root mailnull: root postgres: root sshd: root smmsp: root postfix: root netdump: root ldap: root squid: root ntp: root mysql: root desktop: root rpcuser: root rpc: root nfsnobody: root ingres: root system: root toor: root manager: root dumper: root abuse: root newsadm: news newsadmin: news usenet: news ftpadm: ftp ftpadmin: ftp ftp-adm: ftp ftp-admin: ftp www: webmaster webmaster: root noc: root security: root hostmaster: root info: postmaster marketing: postmaster sales: postmaster support: postmaster # trap decode to catch security attacks decode: root # Person who should get root's mail #root: marc
Achtung: Die aliases-Tabelle wird nur vom Postfix-Modul local ausgewertet, wenn diese lokal zugestellt werden. Erfolgt die Zustellung mit Hilfe von LMTP oder SMTP oder anderen Transportmethoden, wird die aliases-Tabelle ignoriert!
# less /etc/postfix/canonical
# CANONICAL(5) CANONICAL(5) # # NAME # canonical - Postfix canonical table format # # SYNOPSIS # postmap /etc/postfix/canonical # # postmap -q "string" /etc/postfix/canonical # # postmap -q - /etc/postfix/canonical <inputfile # # DESCRIPTION # The optional canonical(5) table specifies an address map- # ping for local and non-local addresses. The mapping is # used by the cleanup(8) daemon, before mail is stored into # the queue. The address mapping is recursive. # # Normally, the canonical(5) table is specified as a text # file that serves as input to the postmap(1) command. The # result, an indexed file in dbm or db format, is used for # fast searching by the mail system. Execute the command # "postmap /etc/postfix/canonical" to rebuild an indexed # file after changing the corresponding text file. # # When the table is provided via other means such as NIS, # LDAP or SQL, the same lookups are done as for ordinary # indexed files. # # Alternatively, the table can be provided as a regular- # expression map where patterns are given as regular expres- # sions, or lookups can be directed to TCP-based server. In # those cases, the lookups are done in a slightly different # way as described below under "REGULAR EXPRESSION TABLES" # or "TCP-BASED TABLES". # # By default the canonical(5) mapping affects both message # header addresses (i.e. addresses that appear inside mes- # sages) and message envelope addresses (for example, the # addresses that are used in SMTP protocol commands). This # is controlled with the canonical_classes parameter. # # NOTE: Postfix versions 2.2 and later rewrite message head- # ers from remote SMTP clients only if the client matches # the local_header_rewrite_clients parameter, or if the # remote_header_rewrite_domain configuration parameter spec- # ifies a non-empty value. To get the behavior before Post- # fix 2.2, specify "local_header_rewrite_clients = # static:all". # # Typically, one would use the canonical(5) table to replace # login names by Firstname.Lastname, or to clean up # addresses produced by legacy mail systems. # # The canonical(5) mapping is not to be confused with vir- # tual alias support or with local aliasing. To change the # destination but not the headers, use the virtual(5) or # aliases(5) map instead. # # CASE FOLDING # The search string is folded to lowercase before database # lookup. As of Postfix 2.3, the search string is not case # folded with database types such as regexp: or pcre: whose # lookup fields can match both upper and lower case. # # TABLE FORMAT # The input format for the postmap(1) command is as follows: # # pattern result # When pattern matches a mail address, replace it by # the corresponding result. # # blank lines and comments # Empty lines and whitespace-only lines are ignored, # as are lines whose first non-whitespace character # is a `#'. # # multi-line text # A logical line starts with non-whitespace text. A # line that starts with whitespace continues a logi- # cal line. # # TABLE SEARCH ORDER # With lookups from indexed files such as DB or DBM, or from # networked tables such as NIS, LDAP or SQL, patterns are # tried in the order as listed below: # # user@domain address # Replace user@domain by address. This form has the # highest precedence. # # This is useful to clean up addresses produced by # legacy mail systems. It can also be used to pro- # duce Firstname.Lastname style addresses, but see # below for a simpler solution. # # user address # Replace user@site by address when site is equal to # $myorigin, when site is listed in $mydestination, # or when it is listed in $inet_interfaces or # $proxy_interfaces. # # This form is useful for replacing login names by # Firstname.Lastname. # # @domain address # Replace other addresses in domain by address. This # form has the lowest precedence. # # Note: @domain is a wild-card. When this form is # applied to recipient addresses, the Postfix SMTP # server accepts mail for any recipient in domain, # regardless of whether that recipient exists. This # may turn your mail system into a backscatter # source: Postfix first accepts mail for non-existent # recipients and then tries to return that mail as # "undeliverable" to the often forged sender address. # # RESULT ADDRESS REWRITING # The lookup result is subject to address rewriting: # # o When the result has the form @otherdomain, the # result becomes the same user in otherdomain. # # o When "append_at_myorigin=yes", append "@$myorigin" # to addresses without "@domain". # # o When "append_dot_mydomain=yes", append ".$mydomain" # to addresses without ".domain". # # ADDRESS EXTENSION # When a mail address localpart contains the optional recip- # ient delimiter (e.g., user+foo@domain), the lookup order # becomes: user+foo@domain, user@domain, user+foo, user, and # @domain. # # The propagate_unmatched_extensions parameter controls # whether an unmatched address extension (+foo) is propa- # gated to the result of table lookup. # # REGULAR EXPRESSION TABLES # This section describes how the table lookups change when # the table is given in the form of regular expressions. For # a description of regular expression lookup table syntax, # see regexp_table(5) or pcre_table(5). # # Each pattern is a regular expression that is applied to # the entire address being looked up. Thus, user@domain mail # addresses are not broken up into their user and @domain # constituent parts, nor is user+foo broken up into user and # foo. # # Patterns are applied in the order as specified in the ta- # ble, until a pattern is found that matches the search # string. # # Results are the same as with indexed file lookups, with # the additional feature that parenthesized substrings from # the pattern can be interpolated as $1, $2 and so on. # # TCP-BASED TABLES # This section describes how the table lookups change when # lookups are directed to a TCP-based server. For a descrip- # tion of the TCP client/server lookup protocol, see tcp_ta- # ble(5). This feature is not available up to and including # Postfix version 2.4. # # Each lookup operation uses the entire address once. Thus, # user@domain mail addresses are not broken up into their # user and @domain constituent parts, nor is user+foo broken # up into user and foo. # # Results are the same as with indexed file lookups. # # BUGS # The table format does not understand quoting conventions. # # CONFIGURATION PARAMETERS # The following main.cf parameters are especially relevant. # The text below provides only a parameter summary. See # postconf(5) for more details including examples. # # canonical_classes # What addresses are subject to canonical address # mapping. # # canonical_maps # List of canonical mapping tables. # # recipient_canonical_maps # Address mapping lookup table for envelope and # header recipient addresses. # # sender_canonical_maps # Address mapping lookup table for envelope and # header sender addresses. # # propagate_unmatched_extensions # A list of address rewriting or forwarding mecha- # nisms that propagate an address extension from the # original address to the result. Specify zero or # more of canonical, virtual, alias, forward, # include, or generic. # # Other parameters of interest: # # inet_interfaces # The network interface addresses that this system # receives mail on. You need to stop and start Post- # fix when this parameter changes. # # local_header_rewrite_clients # Rewrite message header addresses in mail from these # clients and update incomplete addresses with the # domain name in $myorigin or $mydomain; either don't # rewrite message headers from other clients at all, # or rewrite message headers and update incomplete # addresses with the domain specified in the # remote_header_rewrite_domain parameter. # # proxy_interfaces # Other interfaces that this machine receives mail on # by way of a proxy agent or network address transla- # tor. # # masquerade_classes # List of address classes subject to masquerading: # zero or more of envelope_sender, envelope_recipi- # ent, header_sender, header_recipient. # # masquerade_domains # List of domains that hide their subdomain struc- # ture. # # masquerade_exceptions # List of user names that are not subject to address # masquerading. # # mydestination # List of domains that this mail system considers # local. # # myorigin # The domain that is appended to locally-posted mail. # # owner_request_special # Give special treatment to owner-xxx and xxx-request # addresses. # # remote_header_rewrite_domain # Don't rewrite message headers from remote clients # at all when this parameter is empty; otherwise, re- # write message headers and append the specified # domain name to incomplete addresses. # # SEE ALSO # cleanup(8), canonicalize and enqueue mail # postmap(1), Postfix lookup table manager # postconf(5), configuration parameters # virtual(5), virtual aliasing # # README FILES # Use "postconf readme_directory" or "postconf html_direc- # tory" to locate this information. # DATABASE_README, Postfix lookup table overview # ADDRESS_REWRITING_README, address rewriting guide # # LICENSE # The Secure Mailer license must be distributed with this # software. # # AUTHOR(S) # Wietse Venema # IBM T.J. Watson Research # P.O. Box 704 # Yorktown Heights, NY 10598, USA # # CANONICAL(5)
sender_canonical_maps Lookup-Tabelle zum Umschreibungen von Absender eMail-Adressen im SMTP-Envelop und im Header der eMail.
sender_canonical_maps.db Datenbankfile zur sender_canonical_maps-Datei.
# vim /etc/postfix/sender_canonical_maps
# Django : 2012-02-06 # Kapitel 5.2.3 canonical-Tabelle: Ich versteck' mich # Lookup-Tabelle zum Umschreibungen von Absender eMail-Adressen im SMTP-Envelop und im Header der eMail. # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/sender_canonical_maps # die zugehörige Datenbank erzeugt werden. # # catch all @pml100200.intra.nausch.org @nausch.org # # einzelnen Nutzer umschreiben weather news@wetterstation-pliening.info # # genau eine Adresse umschreiben admin@pml100201.intra.nausch.org webmaster@nausch.org
recipient_canonical_maps Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail.
recipient_canonical_maps.db Datenbankfile zur recipient_canonical_maps-Datei.
# vim /etc/postfix/recipient_canonical_maps
# Django : 2012-02-06 # Kapitel 5.2.3 canonical-Tabelle: Ich versteck' mich # Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail. # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/sender_canonical_maps # die zugehörige Datenbank erzeugt werden. # # catch all @omni128.de @nausch.org # # genau eine Adresse umschreiben swat@nausch.org abuse@nausch.org
# less /etc/postfix/generic
# GENERIC(5) GENERIC(5) # # NAME # generic - Postfix generic table format # # SYNOPSIS # postmap /etc/postfix/generic # # postmap -q "string" /etc/postfix/generic # # postmap -q - /etc/postfix/generic <inputfile # # DESCRIPTION # The optional generic(5) table specifies an address mapping # that applies when mail is delivered. This is the opposite # of canonical(5) mapping, which applies when mail is # received. # # Typically, one would use the generic(5) table on a system # that does not have a valid Internet domain name and that # uses something like localdomain.local instead. The # generic(5) table is then used by the smtp(8) client to # transform local mail addresses into valid Internet mail # addresses when mail has to be sent across the Internet. # See the EXAMPLE section at the end of this document. # # The generic(5) mapping affects both message header # addresses (i.e. addresses that appear inside messages) and # message envelope addresses (for example, the addresses # that are used in SMTP protocol commands). # # Normally, the generic(5) table is specified as a text file # that serves as input to the postmap(1) command. The # result, an indexed file in dbm or db format, is used for # fast searching by the mail system. Execute the command # "postmap /etc/postfix/generic" to rebuild an indexed file # after changing the corresponding text file. # # When the table is provided via other means such as NIS, # LDAP or SQL, the same lookups are done as for ordinary # indexed files. # # Alternatively, the table can be provided as a regular- # expression map where patterns are given as regular expres- # sions, or lookups can be directed to TCP-based server. In # those case, the lookups are done in a slightly different # way as described below under "REGULAR EXPRESSION TABLES" # or "TCP-BASED TABLES". # # CASE FOLDING # The search string is folded to lowercase before database # lookup. As of Postfix 2.3, the search string is not case # folded with database types such as regexp: or pcre: whose # lookup fields can match both upper and lower case. # # TABLE FORMAT # The input format for the postmap(1) command is as follows: # # pattern result # When pattern matches a mail address, replace it by # the corresponding result. # # blank lines and comments # Empty lines and whitespace-only lines are ignored, # as are lines whose first non-whitespace character # is a `#'. # # multi-line text # A logical line starts with non-whitespace text. A # line that starts with whitespace continues a logi- # cal line. # # TABLE SEARCH ORDER # With lookups from indexed files such as DB or DBM, or from # networked tables such as NIS, LDAP or SQL, patterns are # tried in the order as listed below: # # user@domain address # Replace user@domain by address. This form has the # highest precedence. # # user address # Replace user@site by address when site is equal to # $myorigin, when site is listed in $mydestination, # or when it is listed in $inet_interfaces or # $proxy_interfaces. # # @domain address # Replace other addresses in domain by address. This # form has the lowest precedence. # # RESULT ADDRESS REWRITING # The lookup result is subject to address rewriting: # # o When the result has the form @otherdomain, the # result becomes the same user in otherdomain. # # o When "append_at_myorigin=yes", append "@$myorigin" # to addresses without "@domain". # # o When "append_dot_mydomain=yes", append ".$mydomain" # to addresses without ".domain". # # ADDRESS EXTENSION # When a mail address localpart contains the optional recip- # ient delimiter (e.g., user+foo@domain), the lookup order # becomes: user+foo@domain, user@domain, user+foo, user, and # @domain. # # The propagate_unmatched_extensions parameter controls # whether an unmatched address extension (+foo) is propa- # gated to the result of table lookup. # # REGULAR EXPRESSION TABLES # This section describes how the table lookups change when # the table is given in the form of regular expressions. For # a description of regular expression lookup table syntax, # see regexp_table(5) or pcre_table(5). # # Each pattern is a regular expression that is applied to # the entire address being looked up. Thus, user@domain mail # addresses are not broken up into their user and @domain # constituent parts, nor is user+foo broken up into user and # foo. # # Patterns are applied in the order as specified in the ta- # ble, until a pattern is found that matches the search # string. # # Results are the same as with indexed file lookups, with # the additional feature that parenthesized substrings from # the pattern can be interpolated as $1, $2 and so on. # # TCP-BASED TABLES # This section describes how the table lookups change when # lookups are directed to a TCP-based server. For a descrip- # tion of the TCP client/server lookup protocol, see tcp_ta- # ble(5). This feature is not available up to and including # Postfix version 2.4. # # Each lookup operation uses the entire address once. Thus, # user@domain mail addresses are not broken up into their # user and @domain constituent parts, nor is user+foo broken # up into user and foo. # # Results are the same as with indexed file lookups. # # EXAMPLE # The following shows a generic mapping with an indexed # file. When mail is sent to a remote host via SMTP, this # replaces his@localdomain.local by his ISP mail address, # replaces her@localdomain.local by her ISP mail address, # and replaces other local addresses by his ISP account, # with an address extension of +local (this example assumes # that the ISP supports "+" style address extensions). # # /etc/postfix/main.cf: # smtp_generic_maps = hash:/etc/postfix/generic # # /etc/postfix/generic: # his@localdomain.local hisaccount@hisisp.example # her@localdomain.local heraccount@herisp.example # @localdomain.local hisaccount+local@hisisp.example # # Execute the command "postmap /etc/postfix/generic" when- # ever the table is changed. Instead of hash, some systems # use dbm database files. To find out what tables your sys- # tem supports use the command "postconf -m". # # BUGS # The table format does not understand quoting conventions. # # CONFIGURATION PARAMETERS # The following main.cf parameters are especially relevant. # The text below provides only a parameter summary. See # postconf(5) for more details including examples. # # smtp_generic_maps # Address mapping lookup table for envelope and # header sender and recipient addresses while deliv- # ering mail via SMTP. # # propagate_unmatched_extensions # A list of address rewriting or forwarding mecha- # nisms that propagate an address extension from the # original address to the result. Specify zero or # more of canonical, virtual, alias, forward, # include, or generic. # # Other parameters of interest: # # inet_interfaces # The network interface addresses that this system # receives mail on. You need to stop and start Post- # fix when this parameter changes. # # proxy_interfaces # Other interfaces that this machine receives mail on # by way of a proxy agent or network address transla- # tor. # # mydestination # List of domains that this mail system considers # local. # # myorigin # The domain that is appended to locally-posted mail. # # owner_request_special # Give special treatment to owner-xxx and xxx-request # addresses. # # SEE ALSO # postmap(1), Postfix lookup table manager # postconf(5), configuration parameters # smtp(8), Postfix SMTP client # # README FILES # Use "postconf readme_directory" or "postconf html_direc- # tory" to locate this information. # ADDRESS_REWRITING_README, address rewriting guide # DATABASE_README, Postfix lookup table overview # STANDARD_CONFIGURATION_README, configuration examples # # LICENSE # The Secure Mailer license must be distributed with this # software. # # HISTORY # A genericstable feature appears in the Sendmail MTA. # # This feature is available in Postfix 2.2 and later. # # AUTHOR(S) # Wietse Venema # IBM T.J. Watson Research # P.O. Box 704 # Yorktown Heights, NY 10598, USA # # GENERIC(5)
lmtp_generic_maps Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail. Das Umschreiben erfolgt beim Verlassen des Systems via LMTP.
lmtp_generic_maps.db Datenbankfile zur lmtp_generic_maps-Datei.
# vim /etc/postfix/lmtp_generic_maps
# Kapitel 5.2.4 generic-Tabelle: Umschreiben bei ausgehenden eMails # Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail. # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/lmtp_generic_maps # die zugehörige Datenbank erzeugt werden. # # catch all @omni128.de @nausch.org # # genau eine Adresse umschreiben swat@nausch.org abuse@nausch.org
smtp_generic_maps Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail. Das Umschreiben erfolgt beim Verlassen des Systems via SMTP.
smtp_generic_maps.db Datenbankfile zur smtp_generic_maps-Datei.
# vim /etc/postfix/smtp_generic_maps
# Kapitel 5.2.4 generic-Tabelle: Umschreiben bei ausgehenden eMails # Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail. # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/smtp_generic_maps # die zugehörige Datenbank erzeugt werden. # # catch all @omni128.de @nausch.org # # genau eine Adresse umschreiben swat@nausch.org abuse@nausch.org
# less /etc/postfix/transport
# TRANSPORT(5) TRANSPORT(5) # # NAME # transport - Postfix transport table format # # SYNOPSIS # postmap /etc/postfix/transport # # postmap -q "string" /etc/postfix/transport # # postmap -q - /etc/postfix/transport <inputfile # # DESCRIPTION # The optional transport(5) table specifies a mapping from # email addresses to message delivery transports and next- # hop destinations. Message delivery transports such as # local or smtp are defined in the master.cf file, and next- # hop destinations are typically hosts or domain names. The # table is searched by the trivial-rewrite(8) daemon. # # This mapping overrides the default transport:nexthop # selection that is built into Postfix: # # local_transport (default: local:$myhostname) # This is the default for final delivery to domains # listed with mydestination, and for [ipaddress] des- # tinations that match $inet_interfaces or # $proxy_interfaces. The default nexthop destination # is the MTA hostname. # # virtual_transport (default: virtual:) # This is the default for final delivery to domains # listed with virtual_mailbox_domains. The default # nexthop destination is the recipient domain. # # relay_transport (default: relay:) # This is the default for remote delivery to domains # listed with relay_domains. In order of decreasing # precedence, the nexthop destination is taken from # relay_transport, sender_dependent_relayhost_maps, # relayhost, or from the recipient domain. # # default_transport (default: smtp:) # This is the default for remote delivery to other # destinations. In order of decreasing precedence, # the nexthop destination is taken from # default_transport, sender_dependent_relayhost_maps, # relayhost, or from the recipient domain. # # Normally, the transport(5) table is specified as a text # file that serves as input to the postmap(1) command. The # result, an indexed file in dbm or db format, is used for # fast searching by the mail system. Execute the command # "postmap /etc/postfix/transport" to rebuild an indexed # file after changing the corresponding transport table. # # When the table is provided via other means such as NIS, # LDAP or SQL, the same lookups are done as for ordinary # indexed files. # # Alternatively, the table can be provided as a regular- # expression map where patterns are given as regular expres- # sions, or lookups can be directed to TCP-based server. In # those case, the lookups are done in a slightly different # way as described below under "REGULAR EXPRESSION TABLES" # or "TCP-BASED TABLES". # # CASE FOLDING # The search string is folded to lowercase before database # lookup. As of Postfix 2.3, the search string is not case # folded with database types such as regexp: or pcre: whose # lookup fields can match both upper and lower case. # # TABLE FORMAT # The input format for the postmap(1) command is as follows: # # pattern result # When pattern matches the recipient address or # domain, use the corresponding result. # # blank lines and comments # Empty lines and whitespace-only lines are ignored, # as are lines whose first non-whitespace character # is a `#'. # # multi-line text # A logical line starts with non-whitespace text. A # line that starts with whitespace continues a logi- # cal line. # # The pattern specifies an email address, a domain name, or # a domain name hierarchy, as described in section "TABLE # LOOKUP". # # The result is of the form transport:nexthop and specifies # how or where to deliver mail. This is described in section # "RESULT FORMAT". # # TABLE SEARCH ORDER # With lookups from indexed files such as DB or DBM, or from # networked tables such as NIS, LDAP or SQL, patterns are # tried in the order as listed below: # # user+extension@domain transport:nexthop # Deliver mail for user+extension@domain through # transport to nexthop. # # user@domain transport:nexthop # Deliver mail for user@domain through transport to # nexthop. # # domain transport:nexthop # Deliver mail for domain through transport to nex- # thop. # # .domain transport:nexthop # Deliver mail for any subdomain of domain through # transport to nexthop. This applies only when the # string transport_maps is not listed in the par- # ent_domain_matches_subdomains configuration set- # ting. Otherwise, a domain name matches itself and # its subdomains. # # * transport:nexthop # The special pattern * represents any address (i.e. # it functions as the wild-card pattern, and is # unique to Postfix transport tables). # # Note 1: the null recipient address is looked up as # $empty_address_recipient@$myhostname (default: mailer-dae- # mon@hostname). # # Note 2: user@domain or user+extension@domain lookup is # available in Postfix 2.0 and later. # # RESULT FORMAT # The lookup result is of the form transport:nexthop. The # transport field specifies a mail delivery transport such # as smtp or local. The nexthop field specifies where and # how to deliver mail. # # The transport field specifies the name of a mail delivery # transport (the first name of a mail delivery service entry # in the Postfix master.cf file). # # The interpretation of the nexthop field is transport # dependent. In the case of SMTP, specify a service on a # non-default port as host:service, and disable MX (mail # exchanger) DNS lookups with [host] or [host]:port. The [] # form is required when you specify an IP address instead of # a hostname. # # A null transport and null nexthop result means "do not # change": use the delivery transport and nexthop informa- # tion that would be used when the entire transport table # did not exist. # # A non-null transport field with a null nexthop field # resets the nexthop information to the recipient domain. # # A null transport field with non-null nexthop field does # not modify the transport information. # # EXAMPLES # In order to deliver internal mail directly, while using a # mail relay for all other mail, specify a null entry for # internal destinations (do not change the delivery trans- # port or the nexthop information) and specify a wildcard # for all other destinations. # # my.domain : # .my.domain : # * smtp:outbound-relay.my.domain # # In order to send mail for example.com and its subdomains # via the uucp transport to the UUCP host named example: # # example.com uucp:example # .example.com uucp:example # # When no nexthop host name is specified, the destination # domain name is used instead. For example, the following # directs mail for user@example.com via the slow transport # to a mail exchanger for example.com. The slow transport # could be configured to run at most one delivery process at # a time: # # example.com slow: # # When no transport is specified, Postfix uses the transport # that matches the address domain class (see DESCRIPTION # above). The following sends all mail for example.com and # its subdomains to host gateway.example.com: # # example.com :[gateway.example.com] # .example.com :[gateway.example.com] # # In the above example, the [] suppress MX lookups. This # prevents mail routing loops when your machine is primary # MX host for example.com. # # In the case of delivery via SMTP, one may specify host- # name:service instead of just a host: # # example.com smtp:bar.example:2025 # # This directs mail for user@example.com to host bar.example # port 2025. Instead of a numerical port a symbolic name may # be used. Specify [] around the hostname if MX lookups must # be disabled. # # The error mailer can be used to bounce mail: # # .example.com error:mail for *.example.com is not deliverable # # This causes all mail for user@anything.example.com to be # bounced. # # REGULAR EXPRESSION TABLES # This section describes how the table lookups change when # the table is given in the form of regular expressions. For # a description of regular expression lookup table syntax, # see regexp_table(5) or pcre_table(5). # # Each pattern is a regular expression that is applied to # the entire address being looked up. Thus, # some.domain.hierarchy is not looked up via its parent # domains, nor is user+foo@domain looked up as user@domain. # # Patterns are applied in the order as specified in the ta- # ble, until a pattern is found that matches the search # string. # # The trivial-rewrite(8) server disallows regular expression # substitution of $1 etc. in regular expression lookup # tables, because that could open a security hole (Postfix # version 2.3 and later). # # TCP-BASED TABLES # This section describes how the table lookups change when # lookups are directed to a TCP-based server. For a descrip- # tion of the TCP client/server lookup protocol, see tcp_ta- # ble(5). This feature is not available up to and including # Postfix version 2.4. # # Each lookup operation uses the entire recipient address # once. Thus, some.domain.hierarchy is not looked up via # its parent domains, nor is user+foo@domain looked up as # user@domain. # # Results are the same as with indexed file lookups. # # CONFIGURATION PARAMETERS # The following main.cf parameters are especially relevant. # The text below provides only a parameter summary. See # postconf(5) for more details including examples. # # empty_address_recipient # The address that is looked up instead of the null # sender address. # # parent_domain_matches_subdomains # List of Postfix features that use domain.tld pat- # terns to match sub.domain.tld (as opposed to # requiring .domain.tld patterns). # # transport_maps # List of transport lookup tables. # # SEE ALSO # trivial-rewrite(8), rewrite and resolve addresses # master(5), master.cf file format # postconf(5), configuration parameters # postmap(1), Postfix lookup table manager # # README FILES # Use "postconf readme_directory" or "postconf html_direc- # tory" to locate this information. # ADDRESS_REWRITING_README, address rewriting guide # DATABASE_README, Postfix lookup table overview # FILTER_README, external content filter # # LICENSE # The Secure Mailer license must be distributed with this # software. # # AUTHOR(S) # Wietse Venema # IBM T.J. Watson Research # P.O. Box 704 # Yorktown Heights, NY 10598, USA # # TRANSPORT(5)
transport_maps Lookup-Tabelle zum Aktivieren einer alternativen Mailrouting bei der Zustellung an einen weiteren Mailserver.
transport_maps.db Datenbankfile zur transport_maps-Datei.
# vim /etc/postfix/transport_maps
# Kapitel 5.2.5 transport-Tabelle: Abweichende Zustellung # Lookup-Tabelle zum Aktivieren einer alternativen Mailrouting bei der Zustellung an einen weiteren Mailserver # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/transport_maps # die zugehörige Datenbank erzeugt werden. # # Alle eMails, die an Subdomains von nausch.org gerichtet sind ("." am Anfang der Zeile!) # werden an den/die Mailserver von intra.nausch.org (MX-Records) weitergeleitet. (keine "["-Klammern!) .nausch.org smtp:intra.nausch.org # Mails an backup.nausch.org werden an den Mailserver auf Port 25 mit Namen mail.intra.nausch.org geschickt. backup.nausch.org smtp:[mail.intra.nausch.org]:25
# less /etc/postfix/relocated
# RELOCATED(5) RELOCATED(5) # # NAME # relocated - Postfix relocated table format # # SYNOPSIS # postmap /etc/postfix/relocated # # DESCRIPTION # The optional relocated(5) table provides the information # that is used in "user has moved to new_location" bounce # messages. # # Normally, the relocated(5) table is specified as a text # file that serves as input to the postmap(1) command. The # result, an indexed file in dbm or db format, is used for # fast searching by the mail system. Execute the command # "postmap /etc/postfix/relocated" to rebuild an indexed # file after changing the corresponding relocated table. # # When the table is provided via other means such as NIS, # LDAP or SQL, the same lookups are done as for ordinary # indexed files. # # Alternatively, the table can be provided as a regular- # expression map where patterns are given as regular expres- # sions, or lookups can be directed to TCP-based server. In # those case, the lookups are done in a slightly different # way as described below under "REGULAR EXPRESSION TABLES" # or "TCP-BASED TABLES". # # Table lookups are case insensitive. # # CASE FOLDING # The search string is folded to lowercase before database # lookup. As of Postfix 2.3, the search string is not case # folded with database types such as regexp: or pcre: whose # lookup fields can match both upper and lower case. # # TABLE FORMAT # The input format for the postmap(1) command is as follows: # # o An entry has one of the following form: # # pattern new_location # # Where new_location specifies contact information # such as an email address, or perhaps a street # address or telephone number. # # o Empty lines and whitespace-only lines are ignored, # as are lines whose first non-whitespace character # is a `#'. # # o A logical line starts with non-whitespace text. A # line that starts with whitespace continues a logi- # cal line. # # TABLE SEARCH ORDER # With lookups from indexed files such as DB or DBM, or from # networked tables such as NIS, LDAP or SQL, patterns are # tried in the order as listed below: # # user@domain # Matches user@domain. This form has precedence over # all other forms. # # user Matches user@site when site is $myorigin, when site # is listed in $mydestination, or when site is listed # in $inet_interfaces or $proxy_interfaces. # # @domain # Matches other addresses in domain. This form has # the lowest precedence. # # ADDRESS EXTENSION # When a mail address localpart contains the optional recip- # ient delimiter (e.g., user+foo@domain), the lookup order # becomes: user+foo@domain, user@domain, user+foo, user, and # @domain. # # REGULAR EXPRESSION TABLES # This section describes how the table lookups change when # the table is given in the form of regular expressions or # when lookups are directed to a TCP-based server. For a # description of regular expression lookup table syntax, see # regexp_table(5) or pcre_table(5). For a description of the # TCP client/server table lookup protocol, see tcp_table(5). # This feature is not available up to and including Postfix # version 2.4. # # Each pattern is a regular expression that is applied to # the entire address being looked up. Thus, user@domain mail # addresses are not broken up into their user and @domain # constituent parts, nor is user+foo broken up into user and # foo. # # Patterns are applied in the order as specified in the ta- # ble, until a pattern is found that matches the search # string. # # Results are the same as with indexed file lookups, with # the additional feature that parenthesized substrings from # the pattern can be interpolated as $1, $2 and so on. # # TCP-BASED TABLES # This section describes how the table lookups change when # lookups are directed to a TCP-based server. For a descrip- # tion of the TCP client/server lookup protocol, see tcp_ta- # ble(5). This feature is not available up to and including # Postfix version 2.4. # # Each lookup operation uses the entire address once. Thus, # user@domain mail addresses are not broken up into their # user and @domain constituent parts, nor is user+foo broken # up into user and foo. # # Results are the same as with indexed file lookups. # # BUGS # The table format does not understand quoting conventions. # # CONFIGURATION PARAMETERS # The following main.cf parameters are especially relevant. # The text below provides only a parameter summary. See # postconf(5) for more details including examples. # # relocated_maps # List of lookup tables for relocated users or sites. # # Other parameters of interest: # # inet_interfaces # The network interface addresses that this system # receives mail on. You need to stop and start Post- # fix when this parameter changes. # # mydestination # List of domains that this mail system considers # local. # # myorigin # The domain that is appended to locally-posted mail. # # proxy_interfaces # Other interfaces that this machine receives mail on # by way of a proxy agent or network address transla- # tor. # # SEE ALSO # trivial-rewrite(8), address resolver # postmap(1), Postfix lookup table manager # postconf(5), configuration parameters # # README FILES # Use "postconf readme_directory" or "postconf html_direc- # tory" to locate this information. # DATABASE_README, Postfix lookup table overview # ADDRESS_REWRITING_README, address rewriting guide # # LICENSE # The Secure Mailer license must be distributed with this # software. # # AUTHOR(S) # Wietse Venema # IBM T.J. Watson Research # P.O. Box 704 # Yorktown Heights, NY 10598, USA # # RELOCATED(5)
relocated_maps Lookup-Tabelle zum Aktivieren von „Bounce-Nachrichten“ an den Absender einer eMail über nicht existierende eMailadressen mit Angabe der neu zu nutzenden eMailadresse des Empfängers.
relocated_maps.db Datenbankfile zur relocated_maps-Datei.
# vim /etc/postfix/relocated_maps
# Kapitel 5.2.6 relocated-Tabelle: Empfängrt verzogen # Lookup-Tabelle zum Aktivieren von "Bounce-Nachrichten" an den Absender einer eMail über nicht # existierende eMailadressen mit Angabe der neu zu nutzenden eMailadresse des Empfängers. # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/relocated_maps # die zugehörige Datenbank erzeugt werden. # michael.nausch@omni128.de django@nausch.org
# less /etc/postfix/virtual
# VIRTUAL(5) VIRTUAL(5) # # NAME # virtual - Postfix virtual alias table format # # SYNOPSIS # postmap /etc/postfix/virtual # # postmap -q "string" /etc/postfix/virtual # # postmap -q - /etc/postfix/virtual <inputfile # # DESCRIPTION # The optional virtual(5) alias table rewrites recipient # addresses for all local, all virtual, and all remote mail # destinations. This is unlike the aliases(5) table which # is used only for local(8) delivery. Virtual aliasing is # recursive, and is implemented by the Postfix cleanup(8) # daemon before mail is queued. # # The main applications of virtual aliasing are: # # o To redirect mail for one address to one or more # addresses. # # o To implement virtual alias domains where all # addresses are aliased to addresses in other # domains. # # Virtual alias domains are not to be confused with # the virtual mailbox domains that are implemented # with the Postfix virtual(8) mail delivery agent. # With virtual mailbox domains, each recipient # address can have its own mailbox. # # Virtual aliasing is applied only to recipient envelope # addresses, and does not affect message headers. Use # canonical(5) mapping to rewrite header and envelope # addresses in general. # # Normally, the virtual(5) alias table is specified as a # text file that serves as input to the postmap(1) command. # The result, an indexed file in dbm or db format, is used # for fast searching by the mail system. Execute the command # "postmap /etc/postfix/virtual" to rebuild an indexed file # after changing the corresponding text file. # # When the table is provided via other means such as NIS, # LDAP or SQL, the same lookups are done as for ordinary # indexed files. # # Alternatively, the table can be provided as a regular- # expression map where patterns are given as regular expres- # sions, or lookups can be directed to TCP-based server. In # those case, the lookups are done in a slightly different # way as described below under "REGULAR EXPRESSION TABLES" # or "TCP-BASED TABLES". # # CASE FOLDING # The search string is folded to lowercase before database # lookup. As of Postfix 2.3, the search string is not case # folded with database types such as regexp: or pcre: whose # lookup fields can match both upper and lower case. # # TABLE FORMAT # The input format for the postmap(1) command is as follows: # # pattern result # When pattern matches a mail address, replace it by # the corresponding result. # # blank lines and comments # Empty lines and whitespace-only lines are ignored, # as are lines whose first non-whitespace character # is a `#'. # # multi-line text # A logical line starts with non-whitespace text. A # line that starts with whitespace continues a logi- # cal line. # # TABLE SEARCH ORDER # With lookups from indexed files such as DB or DBM, or from # networked tables such as NIS, LDAP or SQL, patterns are # tried in the order as listed below: # # user@domain address, address, ... # Redirect mail for user@domain to address. This # form has the highest precedence. # # user address, address, ... # Redirect mail for user@site to address when site is # equal to $myorigin, when site is listed in $mydes- # tination, or when it is listed in $inet_interfaces # or $proxy_interfaces. # # This functionality overlaps with functionality of # the local aliases(5) database. The difference is # that virtual(5) mapping can be applied to non-local # addresses. # # @domain address, address, ... # Redirect mail for other users in domain to address. # This form has the lowest precedence. # # Note: @domain is a wild-card. With this form, the # Postfix SMTP server accepts mail for any recipient # in domain, regardless of whether that recipient # exists. This may turn your mail system into a # backscatter source: Postfix first accepts mail for # non-existent recipients and then tries to return # that mail as "undeliverable" to the often forged # sender address. # # RESULT ADDRESS REWRITING # The lookup result is subject to address rewriting: # # o When the result has the form @otherdomain, the # result becomes the same user in otherdomain. This # works only for the first address in a multi-address # lookup result. # # o When "append_at_myorigin=yes", append "@$myorigin" # to addresses without "@domain". # # o When "append_dot_mydomain=yes", append ".$mydomain" # to addresses without ".domain". # # ADDRESS EXTENSION # When a mail address localpart contains the optional recip- # ient delimiter (e.g., user+foo@domain), the lookup order # becomes: user+foo@domain, user@domain, user+foo, user, and # @domain. # # The propagate_unmatched_extensions parameter controls # whether an unmatched address extension (+foo) is propa- # gated to the result of table lookup. # # VIRTUAL ALIAS DOMAINS # Besides virtual aliases, the virtual alias table can also # be used to implement virtual alias domains. With a virtual # alias domain, all recipient addresses are aliased to # addresses in other domains. # # Virtual alias domains are not to be confused with the vir- # tual mailbox domains that are implemented with the Postfix # virtual(8) mail delivery agent. With virtual mailbox # domains, each recipient address can have its own mailbox. # # With a virtual alias domain, the virtual domain has its # own user name space. Local (i.e. non-virtual) usernames # are not visible in a virtual alias domain. In particular, # local aliases(5) and local mailing lists are not visible # as localname@virtual-alias.domain. # # Support for a virtual alias domain looks like: # # /etc/postfix/main.cf: # virtual_alias_maps = hash:/etc/postfix/virtual # # Note: some systems use dbm databases instead of hash. See # the output from "postconf -m" for available database # types. # # /etc/postfix/virtual: # virtual-alias.domain anything (right-hand content does not matter) # postmaster@virtual-alias.domain postmaster # user1@virtual-alias.domain address1 # user2@virtual-alias.domain address2, address3 # # The virtual-alias.domain anything entry is required for a # virtual alias domain. Without this entry, mail is rejected # with "relay access denied", or bounces with "mail loops # back to myself". # # Do not specify virtual alias domain names in the main.cf # mydestination or relay_domains configuration parameters. # # With a virtual alias domain, the Postfix SMTP server # accepts mail for known-user@virtual-alias.domain, and # rejects mail for unknown-user@virtual-alias.domain as # undeliverable. # # Instead of specifying the virtual alias domain name via # the virtual_alias_maps table, you may also specify it via # the main.cf virtual_alias_domains configuration parameter. # This latter parameter uses the same syntax as the main.cf # mydestination configuration parameter. # # REGULAR EXPRESSION TABLES # This section describes how the table lookups change when # the table is given in the form of regular expressions. For # a description of regular expression lookup table syntax, # see regexp_table(5) or pcre_table(5). # # Each pattern is a regular expression that is applied to # the entire address being looked up. Thus, user@domain mail # addresses are not broken up into their user and @domain # constituent parts, nor is user+foo broken up into user and # foo. # # Patterns are applied in the order as specified in the ta- # ble, until a pattern is found that matches the search # string. # # Results are the same as with indexed file lookups, with # the additional feature that parenthesized substrings from # the pattern can be interpolated as $1, $2 and so on. # # TCP-BASED TABLES # This section describes how the table lookups change when # lookups are directed to a TCP-based server. For a descrip- # tion of the TCP client/server lookup protocol, see tcp_ta- # ble(5). This feature is not available up to and including # Postfix version 2.4. # # Each lookup operation uses the entire address once. Thus, # user@domain mail addresses are not broken up into their # user and @domain constituent parts, nor is user+foo broken # up into user and foo. # # Results are the same as with indexed file lookups. # # BUGS # The table format does not understand quoting conventions. # # CONFIGURATION PARAMETERS # The following main.cf parameters are especially relevant # to this topic. See the Postfix main.cf file for syntax # details and for default values. Use the "postfix reload" # command after a configuration change. # # virtual_alias_maps # List of virtual aliasing tables. # # virtual_alias_domains # List of virtual alias domains. This uses the same # syntax as the mydestination parameter. # # propagate_unmatched_extensions # A list of address rewriting or forwarding mecha- # nisms that propagate an address extension from the # original address to the result. Specify zero or # more of canonical, virtual, alias, forward, # include, or generic. # # Other parameters of interest: # # inet_interfaces # The network interface addresses that this system # receives mail on. You need to stop and start Post- # fix when this parameter changes. # # mydestination # List of domains that this mail system considers # local. # # myorigin # The domain that is appended to any address that # does not have a domain. # # owner_request_special # Give special treatment to owner-xxx and xxx-request # addresses. # # proxy_interfaces # Other interfaces that this machine receives mail on # by way of a proxy agent or network address transla- # tor. # # SEE ALSO # cleanup(8), canonicalize and enqueue mail # postmap(1), Postfix lookup table manager # postconf(5), configuration parameters # canonical(5), canonical address mapping # # README FILES # Use "postconf readme_directory" or "postconf html_direc- # tory" to locate this information. # ADDRESS_REWRITING_README, address rewriting guide # DATABASE_README, Postfix lookup table overview # VIRTUAL_README, domain hosting guide # # LICENSE # The Secure Mailer license must be distributed with this # software. # # AUTHOR(S) # Wietse Venema # IBM T.J. Watson Research # P.O. Box 704 # Yorktown Heights, NY 10598, USA # # VIRTUAL(5)
virtual_alias_domains Lookup-Tabelle zum Verwalten der virtuellen Domains.
virtual_alias_domains.db Datenbankfile zur virtual_alias_domains-Datei.
# vim /etc/postfix/virtual_alias_domains
# Kapitel 5.2.2 virtual: Weiterleitung und virtuelle Mailadressen # Lookup-Tabelle zum Verwalten der virtuellen Domains. # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/virtual_alias_domains # die zugehörige Datenbank erzeugt werden. # nausch.org meine_Hauptdomäne wetter.nausch.org blaablubb omni128.de meine_erste_Domain wetterstation-pliening.info erste_Info_Domain ebersberger-liedersammlung.de Piraten
virtual_alias_maps Lookup-Tabelle zum Verwalten der virtuellen eMail-Adressen.
virtual_alias_maps.db Datenbankfile zur virtual_alias_maps-Datei.
# vim /etc/postfix/virtual_alias_maps
# Kapitel 5.2.2 virtual: Weiterleitung und virtuelle Mailadressen # Lookup-Tabelle zum Verwalten der virtuellen eMailadressen. # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels $ postmap /etc/postfix/virtual_alias_maps # die zugehörige Datenbank erzeugt werden. # # catch all - Sämtliche eMailadressen werden 1:1 umgeschrieben. Aus webmaster@wetter.nausch.org wird webmaster@nausch.org. @wetter.nausch.org @nausch.org # eine einzelne Adresse gezielt umschreiben. Alle Nachrichten die an admin@wetterstation-pliening.info # addressiert sind, gehen an michael@nausch.org. admin@wetterstation-pliening.info michael@nausch.org
Da wir ja nicht nur englischsprachige Nutzer haben, die bei unserem MX Post abliefern dürfen, möchten wir unter Umständen auch individuelle Bouncemessages verwenden.
Hierzu laden wir uns erst einmal mustergültiges Nachrichtentemplate von den beiden Spezialisten Patrick Koetter und Ralf Hildebrandt aus dem Web herunter.
# cd /etc/postfix
# wget http://postfix.state-of-mind.de/bounce-templates/bounce.de-DE.cf
Anschließend erweitern wir unsere Postfixkonfiguration entsprechend.
# vim /etc/postfix/main.cf
# Django : 2012-02-06 # Benutzerdefinierte Bounce Messages mit deutsch- und englischsprachigen Texten aktiviert bounce_template_file = /etc/postfix/bounce.de-DE.cf
Zum Aktivieren starten wir unseren Postfix einmal durch.
# service postfix restart
Zum Schluß überprüfen wir noch, ob die Variablen in dem Templatefile zu unseren Postfixvariablendefinitionen passen.
postconf -b /etc/postfix/bounce.de-DE.cf
expanded_failure_text = <<EOF
Dies ist eine automatisch generierte Nachricht des Postfix E-Mail-Dienstes.
Dieser Dienst wird auf dem Server vml000080.dmz.nausch.org betrieben und teilt Ihnen
folgendes mit:
Ihre Nachricht konnte an einen oder mehrere Empfaenger nicht zugestellt
werden. Ein Problem-Bericht, sowie Ihre uspruengliche Nachricht wurden an
das Ende dieser Nachricht angehaengt.
Fuer weitere Hilfe kontaktieren Sie bitte den fuer Sie zustaendigen
<postmaster>.
Senden Sie dazu den an diese E-Mail angefuegten Problem-Bericht mit.
Den Inhalt Ihrer urspruenglichen Nachricht koennen Sie - zum Schutz Ihrer
Privatsphaere - entfernen; er ist fuer eine Fehler-Diagnose nicht zwingend
notwendig.
Der Postfix E-Mail-Dienst
INTERNATIONAL VERSION
This is the Postfix program at host vml000080.dmz.nausch.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
EOF
expanded_delay_text = <<EOF
Dies ist eine automatisch generierte Nachricht des Postfix E-Mail-Dienstes.
Dieser Dienst wird auf dem Server vml000080.dmz.nausch.org betrieben und teilt Ihnen
folgendes mit:
Eine von Ihnen gesendete Nachricht konnte seit 0
Stunden nicht zugestellt werden.
Sie muessen die Nachricht nicht noch einmal senden. Der Postfix
E-Mail-Dienst wird so lange versuchen Ihre Nachricht zuzustellen,
bis sie 5 Tage alt ist.
Sollte eine Zustellung bis in 5 Tagen nicht
gelingen, wird der Postfix E-Mail-Dienst die Zustellung abbrechen und
Sie davon in Kenntnis setzen.
Fuer weitere Hilfe kontaktieren Sie bitte den fuer Sie zustaendigen
<postmaster>.
Senden Sie dazu den, in dieser E-Mail angefuegten, Problem-Bericht mit.
Den Inhalt Ihrer urspruenglichen Nachricht koennen Sie, zum Schutz Ihrer
Privatsphaere, entfernen; er ist fuer eine Fehler-Diagnose nicht zwingend
notwendig.
Der Postfix E-Mail-Dienst
INTERNATIONAL VERSION
This is the Postfix program at host vml000080.dmz.nausch.org.
####################################################################
# THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. #
####################################################################
Your message could not be delivered for 0 hour(s).
It will be retried until it is 5 day(s) old.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The Postfix program
EOF
expanded_success_text = <<EOF
Dies ist eine automatisch generierte Nachricht des Postfix E-Mail-Dienstes.
Dieser Dienst wird auf dem Server vml000080.dmz.nausch.org betrieben und teilt Ihnen
folgendes mit:
Ihre Nachricht wurde erfolgreich an die E-Mail-Server der am Ende dieser
E-Mail aufgelisteten Empfaenger ausgeliefert.
Falls Sie eine Zustellbericht angefordet haben und der empfangende
E-Mail-Server diese Funktionalitaet unterstuetzt erhalten Sie
auch von diesem E-Mail-Server eine entsprechende Benachrichtigung.
Der Postfix E-Mail-Dienst
INTERNATIONAL VERSION
This is the Postfix program at host vml000080.dmz.nausch.org.
Your message was successfully delivered to the destination(s)
listed below. If the message was delivered to mailbox you will
receive no further notifications. Otherwise you may still receive
notifications of mail delivery errors from other systems.
The Postfix program
EOF
expanded_verify_text = <<EOF
Dies ist eine automatisch generierte Nachricht des Postfix E-Mail-Dienstes.
Dieser Dienst wird auf dem Server vml000080.dmz.nausch.org betrieben und teilt Ihnen
folgendes mit:
Sie haben einen Empfaenger-Adressen-Bericht angefordert. Der Bericht wurde
an diese Nachricht angehaengt.
Der Postfix E-Mail-Dienst
INTERNATIONAL VERSION
This is the Postfix program at host vml000080.dmz.nausch.org.
Enclosed is the mail delivery report that you requested.
The Postfix program
EOF
DSN5) zu verbergen, kann ein wünschenswerter Zustand sein. Was geht schon einem externen der interne Aufbau unserer eMail-Infrastruktur an.
Wir erlauben also beim abgehenden Verkehr die Möglichkeit für unsere eigenen User, nach außen schotten wir uns jedoch ab. Dazu tragen wir in unserer /etc/postfix/main.cf folgende Zeile nach.
# vim /etc/postfix/main.cf
# DSN selectiv aktivieren, bzw. sperren (Kapitel 13.11.2 DSN verbieten) # Eingetragen am 21.11.2008 smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/esmtp_access
Die zugehörige cidr-Tabelle mit den Netzdefinitionen legen wir anschließend auch noch an.
# vim /etc/postfix/esmtp_access
# DSN selectiv aktivieren, bzw. sperren (Kapitel 13.11.2 DSN verbieten) # DSN requests werden nur aus dem eignen Netz erlaubt 10.100.10.0/24 silent-discard 10.10.100.0/24 silent-discard 0.0.0.0/0 silent-discard, dsn
Abschließend starten wir den MX einmal durch.
# service postfix restart
Bei Änderungen an der Datei ist lediglich ein service postfix reload notwendig.
Damit wir später die einfache Möglichkeiten haben, basierend auf bestimmte Inhalte im Mailheader bzw. Mailbody, Nachrichten zu bewerten oder gar zu manipulieren, werden wir nun noch unsere Postfix-Hauptkonfigurationsdatei main.cf erweitern.
# vim /etc/postfix/main.cf
# Django : 2012-02-06 # Lookup-Tabelle zum Verwalten der Routinen zur inhaltliche Prüfung der eMail-Header header_checks = pcre:/etc/postfix/header_check_maps # # Lookup-Tabelle zum Verwalten der Routinen zur inhaltliche Prüfung der eMail-Bodies body_checks = pcre:/etc/postfix/body_check_maps
Voraussetzung hierzu (Perl Compatible Regular Expressions) ist natürlich die Unterstützung des installierten Postfix. Mit folgender Abfrage können wir überprüfen, ob pcre unterstützt wird.
# postconf -m | grep pcre
pcre
Die pcre-Unterstützung beim Postfix unter CentOS 6.x ist also bereits vorhanden!
Trifft das gewählte Suchmuster bei unseren PRCE zu, so haben wir unter anderem folgene Möglichkeiten:
Im Konfigurationsverzeichnis von Postfix finden wir für weitere Beschreibungen die Manpage für den Einsatz und die Verwendung der body- und header-checks.
# vim /etc/postfix/header_checks
# HEADER_CHECKS(5) HEADER_CHECKS(5) # # NAME # header_checks - Postfix built-in content inspection # # SYNOPSIS # header_checks = pcre:/etc/postfix/header_checks # mime_header_checks = pcre:/etc/postfix/mime_header_checks # nested_header_checks = pcre:/etc/postfix/nested_header_checks # body_checks = pcre:/etc/postfix/body_checks # # postmap -q "string" pcre:/etc/postfix/filename # postmap -q - pcre:/etc/postfix/filename <inputfile # # DESCRIPTION # This document describes access control on the content of # message headers and message body lines; it is implemented # by the Postfix cleanup(8) server before mail is queued. # See access(5) for access control on remote SMTP client # information. # # Each message header or message body line is compared # against a list of patterns. When a match is found the # corresponding action is executed, and the matching process # is repeated for the next message header or message body # line. # # For examples, see the EXAMPLES section at the end of this # manual page. # # Postfix header or body_checks are designed to stop a flood # of mail from worms or viruses; they do not decode attach- # ments, and they do not unzip archives. See the documents # referenced below in the README FILES section if you need # more sophisticated content analysis. # # Postfix supports four built-in content inspection classes: # # header_checks # These are applied to initial message headers # (except for the headers that are processed with # mime_header_checks). # # mime_header_checks (default: $header_checks) # These are applied to MIME related message headers # only. # # This feature is available in Postfix 2.0 and later. # # nested_header_checks (default: $header_checks) # These are applied to message headers of attached # email messages (except for the headers that are # processed with mime_header_checks). # # This feature is available in Postfix 2.0 and later. # # body_checks # These are applied to all other content, including # multi-part message boundaries. # # With Postfix versions before 2.0, all content after # the initial message headers is treated as body con- # tent. # # Note: message headers are examined one logical header at a # time, even when a message header spans multiple lines. # Body lines are always examined one line at a time. # # COMPATIBILITY # With Postfix version 2.2 and earlier specify "postmap -fq" # to query a table that contains case sensitive patterns. By # default, regexp: and pcre: patterns are case insensitive. # # TABLE FORMAT # This document assumes that header and body_checks rules # are specified in the form of Postfix regular expression # lookup tables. Usually the best performance is obtained # with pcre (Perl Compatible Regular Expression) tables, but # the slower regexp (POSIX regular expressions) support is # more widely available. Use the command "postconf -m" to # find out what lookup table types your Postfix system sup- # ports. # # The general format of Postfix regular expression tables is # given below. For a discussion of specific pattern or # flags syntax, see pcre_table(5) or regexp_table(5), # respectively. # # /pattern/flags action # When /pattern/ matches the input string, execute # the corresponding action. See below for a list of # possible actions. # # !/pattern/flags action # When /pattern/ does not match the input string, # execute the corresponding action. # # if /pattern/flags # # endif Match the input string against the patterns between # if and endif, if and only if the same input string # also matches /pattern/. The if..endif can nest. # # Note: do not prepend whitespace to patterns inside # if..endif. # # if !/pattern/flags # # endif Match the input string against the patterns between # if and endif, if and only if the same input string # does not match /pattern/. The if..endif can nest. # # blank lines and comments # Empty lines and whitespace-only lines are ignored, # as are lines whose first non-whitespace character # is a `#'. # # multi-line text # A pattern/action line starts with non-whitespace # text. A line that starts with whitespace continues # a logical line. # # TABLE SEARCH ORDER # For each line of message input, the patterns are applied # in the order as specified in the table. When a pattern is # found that matches the input line, the corresponding # action is executed and then the next input line is # inspected. # # TEXT SUBSTITUTION # Substitution of substrings from the matched expression # into the action string is possible using the conventional # Perl syntax ($1, $2, etc.). The macros in the result # string may need to be written as ${n} or $(n) if they # aren't followed by whitespace. # # Note: since negated patterns (those preceded by !) return # a result when the expression does not match, substitutions # are not available for negated patterns. # # ACTIONS # Action names are case insensitive. They are shown in upper # case for consistency with other Postfix documentation. # # DISCARD optional text... # Claim successful delivery and silently discard the # message. Log the optional text if specified, oth- # erwise log a generic message. # # Note: this action disables further header or # body_checks inspection of the current message and # affects all recipients. To discard only one recip- # ient without discarding the entire message, use the # transport(5) table to direct mail to the discard(8) # service. # # This feature is available in Postfix 2.0 and later. # # DUNNO Pretend that the input line did not match any pat- # tern, and inspect the next input line. This action # can be used to shorten the table search. # # For backwards compatibility reasons, Postfix also # accepts OK but it is (and always has been) treated # as DUNNO. # # This feature is available in Postfix 2.1 and later. # # FILTER transport:destination # Write a content filter request to the queue file, # and inspect the next input line. After the com- # plete message is received it will be sent through # the specified external content filter. More infor- # mation about external content filters is in the # Postfix FILTER_README file. # # Note: this action overrides the content_filter set- # ting, and affects all recipients of the message. In # the case that multiple FILTER actions fire, only # the last one is executed. # # This feature is available in Postfix 2.0 and later. # # HOLD optional text... # Arrange for the message to be placed on the hold # queue, and inspect the next input line. The mes- # sage remains on hold until someone either deletes # it or releases it for delivery. Log the optional # text if specified, otherwise log a generic message. # # Mail that is placed on hold can be examined with # the postcat(1) command, and can be destroyed or # released with the postsuper(1) command. # # Note: use "postsuper -r" to release mail that was # kept on hold for a significant fraction of $maxi- # mal_queue_lifetime or $bounce_queue_lifetime, or # longer. Use "postsuper -H" only for mail that will # not expire within a few delivery attempts. # # Note: this action affects all recipients of the # message. # # This feature is available in Postfix 2.0 and later. # # IGNORE Delete the current line from the input, and inspect # the next input line. # # PREPEND text... # Prepend one line with the specified text, and # inspect the next input line. # # Notes: # # o The prepended text is output on a separate # line, immediately before the input that # triggered the PREPEND action. # # o The prepended text is not considered part of # the input stream: it is not subject to # header/body checks or address rewriting, and # it does not affect the way that Postfix adds # missing message headers. # # o When prepending text before a message header # line, the prepended text must begin with a # valid message header label. # # o This action cannot be used to prepend multi- # line text. # # This feature is available in Postfix 2.1 and later. # # REDIRECT user@domain # Write a message redirection request to the queue # file, and inspect the next input line. After the # message is queued, it will be sent to the specified # address instead of the intended recipient(s). # # Note: this action overrides the FILTER action, and # affects all recipients of the message. If multiple # REDIRECT actions fire, only the last one is exe- # cuted. # # This feature is available in Postfix 2.1 and later. # # REPLACE text... # Replace the current line with the specified text, # and inspect the next input line. # # This feature is available in Postfix 2.2 and later. # The description below applies to Postfix 2.2.2 and # later. # # Notes: # # o When replacing a message header line, the # replacement text must begin with a valid # header label. # # o The replaced text remains part of the input # stream. Unlike the result from the PREPEND # action, a replaced message header may be # subject to address rewriting and may affect # the way that Postfix adds missing message # headers. # # REJECT optional text... # Reject the entire message. Reply with optional # text... when the optional text is specified, other- # wise reply with a generic error message. # # Note: this action disables further header or # body_checks inspection of the current message and # affects all recipients. # # Postfix version 2.3 and later support enhanced sta- # tus codes. When no code is specified at the begin- # ning of optional text..., Postfix inserts a default # enhanced status code of "5.7.1". # # WARN optional text... # Log a warning with the optional text... (or log a # generic message), and inspect the next input line. # This action is useful for debugging and for testing # a pattern before applying more drastic actions. # # BUGS # Empty lines never match, because some map types mis-behave # when given a zero-length search string. This limitation # may be removed for regular expression tables in a future # release. # # Many people overlook the main limitations of header and # body_checks rules. # # o These rules operate on one logical message header # or one body line at a time. A decision made for one # line is not carried over to the next line. # # o If text in the message body is encoded (RFC 2045) # then the rules need to be specified for the encoded # form. # # o Likewise, when message headers are encoded (RFC # 2047) then the rules need to be specified for the # encoded form. # # Message headers added by the cleanup(8) daemon itself are # excluded from inspection. Examples of such message headers # are From:, To:, Message-ID:, Date:. # # Message headers deleted by the cleanup(8) daemon will be # examined before they are deleted. Examples are: Bcc:, Con- # tent-Length:, Return-Path:. # # CONFIGURATION PARAMETERS # body_checks # Lookup tables with content filter rules for message # body lines. These filters see one physical line at # a time, in chunks of at most $line_length_limit # bytes. # # body_checks_size_limit # The amount of content per message body segment # (attachment) that is subjected to $body_checks fil- # tering. # # header_checks # # mime_header_checks (default: $header_checks) # # nested_header_checks (default: $header_checks) # Lookup tables with content filter rules for message # header lines: respectively, these are applied to # the initial message headers (not including MIME # headers), to the MIME headers anywhere in the mes- # sage, and to the initial headers of attached mes- # sages. # # Note: these filters see one logical message header # at a time, even when a message header spans multi- # ple lines. Message headers that are longer than # $header_size_limit characters are truncated. # # disable_mime_input_processing # While receiving mail, give no special treatment to # MIME related message headers; all text after the # initial message headers is considered to be part of # the message body. This means that header_checks is # applied to all the initial message headers, and # that body_checks is applied to the remainder of the # message. # # Note: when used in this manner, body_checks will # process a multi-line message header one line at a # time. # # EXAMPLES # Header pattern to block attachments with bad file name # extensions. For convenience, the PCRE /x flag is speci- # fied, so that there is no need to collapse the pattern # into a single line of text. The purpose of the # [[:xdigit:]] sub-expressions is to recognize Windows CLSID # strings. # # /etc/postfix/main.cf: # header_checks = pcre:/etc/postfix/header_checks.pcre # # /etc/postfix/header_checks.pcre: # /^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)( # ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe| # hlp|ht[at]| # inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws| # \{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}| # ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf| # vb[esx]?|vxd|ws[cfh]))(\?=)?"?\s*(;|$)/x # REJECT Attachment name "$2" may not end with ".$4" # # Body pattern to stop a specific HTML browser vulnerability # exploit. # # /etc/postfix/main.cf: # body_checks = regexp:/etc/postfix/body_checks # # /etc/postfix/body_checks: # /^<iframe src=(3D)?cid:.* height=(3D)?0 width=(3D)?0>$/ # REJECT IFRAME vulnerability exploit # # SEE ALSO # cleanup(8), canonicalize and enqueue Postfix message # pcre_table(5), format of PCRE lookup tables # regexp_table(5), format of POSIX regular expression tables # postconf(1), Postfix configuration utility # postmap(1), Postfix lookup table management # postsuper(1), Postfix janitor # postcat(1), show Postfix queue file contents # RFC 2045, base64 and quoted-printable encoding rules # RFC 2047, message header encoding for non-ASCII text # # README FILES # Use "postconf readme_directory" or "postconf html_direc- # tory" to locate this information. # DATABASE_README, Postfix lookup table overview # CONTENT_INSPECTION_README, Postfix content inspection overview # BUILTIN_FILTER_README, Postfix built-in content inspection # BACKSCATTER_README, blocking returned forged mail # # LICENSE # The Secure Mailer license must be distributed with this # software. # # AUTHOR(S) # Wietse Venema # IBM T.J. Watson Research # P.O. Box 704 # Yorktown Heights, NY 10598, USA # # HEADER_CHECKS(5)
Wollen wir nun Nachrichten von bestimmten Absendern oder anderen Einträgen in den Headerzeilen generell blocken, so legen wir uns folgende Konfigurationsdatei /etc/postfix/header_check_maps an.
# vim /etc/postfix/header_check_maps
# Django : 2012-02-06 # Kapitel 13.5 Filtern von eMails nach Inhalt # In der Postfix-Konfigurationsdatei /etc/postfix/main.cf muss # body_checks = pcre:/etc/postfix/header_check_maps gesetzt sein! # # Nach dem Ändern der Datei ist ein service postfix reload durchzuführen! # # Die Nummern hinter dem REJECT tauchen später als SMTP-Error und auch im Mailserver-Log auf. # Die auslösende Filter-Regel, die den Block ausgeloest hat, ist somit leicht quwieder zu finden. # # Ausnahmeregelung für den sicheren IT-/Mailbetrieb im heimischen Netzwerk # # Domeus hat bis heute nicht den Unterschied zwischen Mailheader-To und # SMTP-Envelope-To verstanden und fabriziert seit nunmehr über sieben Jahren in # schöner Regelmäßigkeit Mailschleifen im vier/fünfstelligen Bereich. # /^Received:.*domeus\.com/ REJECT Domeus baut Mailschleifen und hat wichtige RFCs nicht verstanden # # Dauerhaft genutzte Regelungen: # =============================================== # [Immer mit aufsteiger Nummer sauber eintragen!] # If /^Subject:/i /^Subject:.*Webcam Luder.*/ REJECT Header-Subject-Spamschutzregel Subj-1002 /^Subject:.*Potenzprobleme.*/ REJECT Header-Subject-Spamschutzregel Subj-1001 /^Subject:.*RedBull fur Ihr bestes Stueck/ REJECT Header-Subject-Spamschutzregel Subj-1000 Endif # # und das Ganze nach Header-From # ============================== # If /^From:/i /^From: .*Royal Club Casino.*/ REJECT Header-From-Spamschutzregel From-1002 /^From: .*Euro Dice Casino.*/ REJECT Header-From-Spamschutzregel From-1001 /^From:.*happydigits.de/ REJECT Header-From-Spamschutzregel From-1000 Endif # # generelle Filerregelungen nach den üblichen Verdächtigen # ======================================================== # /^Date: .* 200[0-7]/ REJECT Your email has a date from the past. Fix your system clock and try again. /^Date: .* 19[0-9][0-9]/ REJECT Your email has a date from the past. Fix your system clock and try again. If /^X-Mailer:/i /^X-Mailer: 0001/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: Avalanche/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: Crescent Internet Tool/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: DiffondiCool/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: E-Mail Delivery Agent/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: Emailer Platinum/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: Entity/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: Extractor/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: Floodgate/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: GOTO Software Sarbacane/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: MailWorkz/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: MassE-Mail/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: MaxBulk.Mailer/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: News Breaker Pro/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: SmartMailer/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: StormPort/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. /^X-Mailer: SuperMail-2/ REJECT You used an email program that is used almost exclusively for spam. We do not accept email sent using this program. Endif
Damit Postfix das neue Regelwerk auch verwenden kann, ost ein reload des laufenden Daemon durchzuführen.
# service postfix reload
Reloading postfix: [ OK ]
Wollen wir nun Nachrichten von bestimmten Absendern oder anderen Einträgen in den Headerzeilen generell blocken, so legen wir uns folgende Konfigurationsdatei /etc/postfix/body_check_maps an.
# vim /etc/postfix/body_check_maps
# Django : 2012-02-06 # Kapitel 13.5 Filtern von eMails nach Inhalt # In der Postfix-Konfigurationsdatei /etc/postfix/main.cf muss # body_checks = pcre:/etc/postfix/body_check_maps gesetzt sein! # # Nach dem Ändern der Datei ist ein service postfix reload durchzuführen! # # Die Nummern hinter dem REJECT tauchen später als SMTP-Error und auch im Mailserver-Log auf. # Die auslösende Filter-Regel, die den Block ausgeloest hat, ist somit leicht wieder zu finden. # /.*http:\/\/www.csu.de:80\/.*/ REJECT Body_Check_Rule_4_Dummies: 0002 /.*was@qualys.com.*/ REJECT Body_Check_Rule_4_Dummies: 0001
Damit Postfix das neue Regelwerk auch verwenden kann, ost ein reload des laufenden Daemon durchzuführen.
# service postfix reload
Reloading postfix: [ OK ]
Über die nachfolgenden Parameter können wir definieren, wie groß einzelne eMails, einzelne MailDir-Files und wieviel wir bei einem Bounce, wenn er denn nötig werden sollte, zurück an den Absender schicken wollen. All diese Festlegungen werden pber die main.cf vorgenommen.
# vim /etc/postfix/main.cf
# Django : 2012-02-06 # Maximale Nachrichtengröße einer Nachricht incl. der Headerinformationen: 50MB # ( 52428800 = 50*1024*1024 ), darüber verweigert Postfix die Annahme. # default: message_size_limit = 10240000 message_size_limit = 52428800 # Django : 2012-02-06 # Maximale Mailboxgröße einer einzelnen Mailbox bzw. Maildir-Fiels. Darf nicht kleiner # als die maximale Nachrichtengröße (message_size_limit) sein # default: mailbox_size_limit = 10240000 mailbox_size_limit = 52428800 # Django : 2012-02-06 # Anteil der Originalnachricht (Größe) die bei einem Bounce zurück an den Absender geschickt wird. # default : bounce_size_limit = 50000 bounce_size_limit = 8192
Anschließend starten wir unseren Postfix einmal durch.
# service postfix restart
Mit Hilfe des Moduls anvil ist Postfix in der Lage, basierend auf den Verbindungsstatistiken, eine Trafficlimitierung vorzunehmen. In der Konfigurationsdatei master.cf ist hierzu folgende Zeile notwendig, die bereits eingetragen und auch schon aktiviert ist.
# grep anvil /etc/postfix/master.cf
anvil unix - - n - 1 anvil
In der Konfigurationsdatei main.cf tragen wir nun beu Bedarf folgende Parameter ein:
# vim /etc/postfix/main.cf
# Django : 2012-02-06 # maximale Zustellungen limitieren (Kapitel 13.14 Rate-Limiting gegenüber Clients durchsetzen) # (DOS-Attacken verhindern) # # Basiszeiteinheit für die Kalkulation der rate-limits anvil_rate_time_unit = 60s # # maximale Anzahl gleichzeitiger Verbindungen pro einliefernenden Host # default : smtpd_client_connection_count_limit = 50 smtpd_client_connection_count_limit = 20 # # maximale Anzahl von Verbindungsversuchen je definierter Zeiteinheit # (anvil_rate_time_unit) pro einliefernden Host smtpd_client_connection_rate_limit = 20 # # maximale Anzahl von erlaubten Empfänger Adressen je definierter Zeiteinheit # (anvil_rate_time_unit) pro einliefernden Host smtpd_client_recipient_rate_limit = 50 # # maximale Anzahl von erlaubten Anzahl von eMails je definierter Zeiteinheit # (anvil_rate_time_unit) pro einliefernden Host smtpd_client_message_rate_limit = 50
Zur Aktivierung starten wir unseren Mailserver einmal durch.
# service postfix restart
Mit Hilfe des SMTP-Befehles VRFY ist es möglich, ohne die Verwendung des SMTP-Befehles MAIL FROM die Existenz eines Postfachs abzuprüfen. Will man diese Abfragemöglichkeit unterbinden, so trägt man in die Konfigurationsdatei folgende Zeilen ein.
# vim /etc/postfix/main.cf
# Django : 2012-02-06 # SMTP vrfy sperren (Kapitel 2.1 SMTP richtig sprechen) disable_vrfy_command=yes
Anschließend starten wir den Mailserver zur Aktivierung einmal durch.
# service postfix restart
Mit unter ist es wünschenswert, die Zeitspanne für die Dauer unserer Zustellversuche bei anderen Mailservern anzupassen. Standardmäßig würde Postfix versuchen 7 Tage lang die Nachricht abzusetzen. In der main.cf tragen wir hierzu folgende Zeilen ein.
# vim /etc/postfix/main.cf
# Django : 2012-02-06 # lifetime auf drei Tage runtersetzen maximal_queue_lifetime_days = 3d # Defininiert die maximale Zeit, die der # MX versuchen darf, eine Nachricht zuzustellen delay_warning_time_hours = 0h # Legt fest, wieviel Zeit vergehen muss, bevor # eine Warnung versendet wird
Zum Aktivieren der Option starten wir den Mailserver einmal durch.
# service postfix restart