[Postfixbuch-users] reject_non_fqdn_hostname RFC-konform?

[Robert Felber]

On Thu, Oct 19, 2006 at 10:07:01AM +0200, Ralf Hildebrandt wrote:
> * Robert Felber <r.felber at ek-muc.de>:
> 
> > Naja, dennoch sagt die RFC, dass man aufgrund kaputter HELOs, seien es 
> > non-fqdns, seien es falsche [ip] notationen, seien es invalid helos NICHT 
> > ablehnen  darf. In der Theorie duerft man nichtmal ablehnen wenn da localhost 
> > steht.
> 
> Steht wo?

Ok, *zurueckruder*: s/dennoch/interpretierbar/



Auszuege aus 2821

----------------
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.


Dummerweise sagt der Abschnitt nur was von Senden, nicht was der Empfaenger
machen darf. ECONCEPT weil Raum fuer wildeste Interpretationen.
-------------------

4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
    In situations in which the
        SMTP client system does not have a meaningful domain name
        the client SHOULD send an address literal (see section
        4.1.3), optionally followed by information that will help to identify
        the client system.

Hier wird schonmal 3.6 relativiert - SHOULD send [ip]. Ja wie denn nun, 
MUST, und nun SHOULD wenn das andere MUST nicht realisierbar ist? Was, wenn
weder MUST und SHOULD realisierbar ist, greift dann automatisch MUST, wo ist
das spezifiert? Raum fuer Interpretation. Wie auch immer klingt nur nach was 
der _Sender_ nicht machen darf.


        An SMTP server MAY verify that the domain name parameter in the EHLO
   command actually corresponds to the IP address of the client.
   However, the server MUST NOT refuse to accept a message for this
   reason if the verification fails: the information about verification
   failure is for logging and tracing only.


Das, was OP schon sagte, der Term, dass hier eigentlich nur das "Recht" auf
DNS uebereinstimmenter Vor- und Rueckwaertsaufloesung beschitten wird, ist
hier nicht zwangslaeufig _jedem_ ersichtlich. Manche interpretieren hier dann
gerne rein "im grunde darf auf HELO verification hin garnicht abgelehnt werden".

Andere RFC (weiss grad nicht welche, OP hatte 1123 erwaehnt), sagen in etwa
das gleiche, nur etwas schwammiger -> noch mehr Spielraum fuer Interpretationen.

1123 schreibt dann noch
"Note also that the HELO argument is still required to have
              valid <domain> syntax, since it will appear in a Received:
              line; otherwise, a 501 error is to be sent."

Ah, hier wird nun explizit gesagt, was der receiver machen muss, kann, sollte?
Wieso steht das eigentlich nicht in 2821, ist 1123 daraufhin ungueltig?
Verwirrung!

1123 ist auf http://www.rfc-editor.org/rfcxx00.html noch zu finden, gut, ist
also gueltig.

lesen wir weiter in 1123:
IMPLEMENTATION:
              When HELO parameter validation fails, a suggested
              procedure is to insert a note about the unknown
              authenticity of the sender into the message header (e.g.,
              in the "Received:"  line).

Validation, verification? Gehts um syntax validation oder dns verification?
Huh? Vorher stand, 501 is to be sent, nun wird empfohlen (implizit) anzunehmen 
und eben eine entspr. received line zu generieren.

Doch halt, 2821 sagt ja so ganz oben:
updates RFC 1123 (replaces the
   mail transport materials of RFC 1123).

Knurks! Heist, was der Empfaenger machen darf, ist nicht mehr in 1123 
beschrieben. Der geneigte Leser gibt spaetestens hier dann auf, irgendeinen Wert
auf 2821 und 1123 zu legen und sagt sich "ok, ich sollte lieber einen 
zuverlaessigeren Weg waehlen, die Korrektheit/Aufloesbarkeit von HELO-Argumenten
zu waehlen und befolge Regel: be strict in what you send, be tolerant in what
you accept".

Dass das im Grunde sich ja alles ganz anders verhaelt, ist mir klar. Wenn jetzt
aber ein Korinthenkacker daherkommt und sagt "so what, kdidjfi fails a 
(resolveable) verification|validation, so above stament means you MUST not 
refuse it" oder "any non-fqdn fails (dns-)verification|validation so you MUST
not refuse on it" etc.

Wie auch immer, man kann seinen Spass mit RFCs haben, und - man kann sagen was
man will, es wird immer einer kommen "Ist doch eigentlich aber auch anders
zu verstehen - guck mal in die und die RFC, lies mal das SHOULD als SHOULD und
nicht als SHALL" - etc pp. Es aendert nichts daran, dass man bei gewissen
Sachen die regelmaessig RFC inkonform sind (HELOs) lieber etwas zurueckhaltent
sein sollte - ausser man hat Bock auf langatmige RFC Diskussionen bzw ist ein
BOFH.

Um des OPs Frage zu beantworten, du darfst aufgrund 
zeichensatz-syntaktisch/domain-syntaktisch invalider HELO ablehnen.

zeichensatz-syntaktisch: reject_invalid_helo_hostname
domain-syntaktisch:      reject_non_fqdn_helo_hostname

(zumindest nach 2821)
Ob du Spass dabei haben wirst, steht auf einem anderen Blatt.

-- 
    Robert Felber (PGP: 896CF30B)
    Munich, Germany