[Postfixbuch-users] Matching IP<->PTR<->IP

[Thomas Schwenski]

Sandy Drobic schrieb:
>> Postfix überprüft ja, ob der zur IP-Adresse eines Client-Mailservers als
>> PTR angegebene Hostname wieder auf diese IP-Adresse aufgelöst werden kann.
>>
>> Klappt das nicht (oder fehlt der PTR gänzlich) sieht Postfix die
>> Konstellation als unknown an und verweigert bei Verwendung von
>> reject_unknown_client die Annahme von Mails mit "cannot find your
>> hostname [IP]".

Hallo Sandy,

und erstmal Danke für's Stöbern.
Was mir allerdings fehlt ist die "Vorschrift", dass eine IP zu einem
Hostnamen und dieser wieder zu genau dieser IP auflösbar sein "muss".

Übersehe ich da was in Deinen Zitaten oder verstehe ich da was falsch?

Eben weil die Auflösung des ermittelten Hostnamens auf die ursprüngliche
IP nicht möglich ist, sieht mein Postfix den sendenden Mailserver als
"unknown" an.

Dass diese Restriktion auch manche valide Server erwischt ist mir
bewusst, jedoch ist meine Erfahrung hier der Art, dass dies' nur ein
verschwindend geringer Anteil ist und diese Fälle relativ zeitnah
aufgedeckt werden.
(In der Regel erwarten meine User, dass eine Mail innerhalb von 5
Minuten nach dem Absenden bei Ihnen ankommt und werden andernfalls
schnell hibbelig.)
Meist sind die Mails da noch in der Queue des sendenden Mailservers.

In solchen Fällen gibt es einen Whitelist-Eintrag und eine Infomail an
den Absender und dessen Postmaster.
Die maximal 3-4 Einträge in der Whitelist pro Monat sind vergleichsweise
wenig Arbeit gegenüber den gesparten Ressourcen für die Bearbeitung des
dadurch geblockten Spams.

Ich möchte also nur gerne genau wissen, wie "zwingend erforderlich"
diese Auflösbarkeit der IP zu sich selbst ist.


Thomas


> Sämtliche Zitate hier stammen aus dem RFC2821:
> 
> 2.3.4 Host
> 
>    For the purposes of this specification, a host is a computer system
>    attached to the Internet (or, in some cases, to a private TCP/IP
>    network) and supporting the SMTP protocol.  Hosts are known by names
>    (see "domain"); identifying them by numerical address is discouraged.
> 
> 2.3.5 Domain
> 
>    A domain (or domain name) consists of one or more dot-separated
>    components.  These components ("labels" in DNS terminology [22]) are
>    restricted for SMTP purposes to consist of a sequence of letters,
>    digits, and hyphens drawn from the ASCII character set [1].  Domain
>    names are used as names of hosts and of other entities in the domain
>    name hierarchy.  For example, a domain may refer to an alias (label
>    of a CNAME RR) or the label of Mail eXchanger records to be used to
>    deliver mail instead of representing a host name.  See [22] and
>    section 5 of this specification.
> 
>    The domain name, as described in this document and in [22], is the
>    entire, fully-qualified name (often referred to as an "FQDN").  A
>    domain name that is not in FQDN form is no more than a local alias.
>    Local aliases MUST NOT appear in any SMTP transaction.
> 
> [...]
> 
> 3.6 Domains
> 
>    Only resolvable, fully-qualified, domain names (FQDNs) are permitted
>    when domain names are used in SMTP.  In other words, names that can
>    be resolved to MX RRs or A RRs (as discussed in section 5) are
>    permitted, as are CNAME RRs whose targets can be resolved, in turn,
>    to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
>    used.  There are two exceptions to the rule requiring FQDNs:
> 
>    -  The domain name given in the EHLO command MUST BE either a primary
>       host name (a domain name that resolves to an A RR) or, if the host
>       has no name, an address literal as described in section 4.1.1.1.
> 
> Diese letzte Anforderung an den sendenden Server zeigt sehr deutlich, dass
> selbst ein sendender Server ohne auflösbaren DNS-Namen fehl am Platze ist.
> 
> [...]
> 
> 4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
> 
>    These commands are used to identify the SMTP client to the SMTP
>    server.  The argument field contains the fully-qualified domain name
>    of the SMTP client if one is available.  In situations in which the
>    SMTP client system does not have a meaningful domain name (e.g., when
>    its address is dynamically allocated and no reverse mapping record is
>    available), the client SHOULD send an address literal (see section
>    4.1.3), optionally followed by information that will help to identify
>    the client system.  The SMTP server identifies itself to the SMTP
>    client in the connection greeting reply and in the response to this
>    command.
> 
> 
> 7.7 Scope of Operation of SMTP Servers
> 
>    It is a well-established principle that an SMTP server may refuse to
>    accept mail for any operational or technical reason that makes sense
>    to the site providing the server.  However, cooperation among sites
>    and installations makes the Internet possible.  If sites take
>    excessive advantage of the right to reject traffic, the ubiquity of
>    email availability (one of the strengths of the Internet) will be
>    threatened; considerable care should be taken and balance maintained
>    if a site decides to be selective about the traffic it will accept
>    and process.