[Postfixbuch-users] Probleme bei Postfix

[Matthias Haegele]

Bjoern Rudloff schrieb:
> -------- Original-Nachricht --------
> Datum: Thu, 15 Feb 2007 10:15:10 +0100
> Von: Matthias Haegele <mhaegele at linuxrocks.dyndns.org>
> An: "Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein." <postfixbuch-users at listi.jpberlin.de>
> CC: 
> Betreff: Re: [Postfixbuch-users] Probleme bei Postfix
> 
>> Bjoern Rudloff schrieb:
>>> -------- Original-Nachricht --------
>>> Datum: Thu, 15 Feb 2007 09:48:34 +0100
>>> Von: Matthias Haegele <mhaegele at linuxrocks.dyndns.org>
>>> An: "Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein."
>> <postfixbuch-users at listi.jpberlin.de>
>>> CC: 
>>> Betreff: Re: [Postfixbuch-users] Probleme bei Postfix
>>>
>>>> Bjoern Rudloff schrieb:
>>>>> Hallo,
>>>> Hallo!
>>>>
>>>>> ich hatte mich ja schon mal mit dem Problem "too many errors" an Euch
>>>> gewandt. Er tritt leider immer noch auf und ich wiess imme rnoch nciht
>> warum.
>>>>> An der Postfix-Konfiguration wurde nichts geändert. Es wurde "nur"
>> auf
>>>> procmail und spamassassin umgestellt. Der Fehler trat aber schon vorher
>>>> auf.
>>>>> Anbei mal ein Log-Auszug:
>>>>>
>>>>> Feb 15 08:36:52 mailx postfix/smtpd[18632]: < unknown[xxx]: DATA
>>>>> Feb 15 08:36:54 mailx postfix/smtpd[18632]: > unknown[xxx]: 554 Error:
>>>> no valid recipients
>> Bei mir kommt da zwar ein 550 statt ein 554 ansonsten sieht es bei einem 
>> Test aber ähnlich aus:
>>
>>> Feb 15 10:02:41 hermes postfix/smtpd[20427]: NOQUEUE: reject: RCPT from
>> xxxxx.dip.t-dialin.net[xx.xx.xx.249]: 550
>> <nicht_vorhandener_user at meinedomain.dyndns.org>: Recipient address rejected: User unknown in local recipient
>> table; from=<valide_adresse at t-online.de>
>> to=<nicht_existenter_user at meinedomain.dyndns.org> proto=ESMTP helo=<host.blablub.de>
>>
>>
>>>> Wie lautet der Empfänger?
>>>>
>>>> Ist denn der Empfänger bei dir bekannt? Wenn nein ist es ja ok, da 
>>>> Postfix diesen nicht kennt und folgerichtig ablehnt.
>>>> Falls ja (der Empfänger ist "valide") hast du irgendwo einen "Bock" in
>>>> deiner Konfiguration.
>>>> Vermutung: aliases/Authentifizierung.
>>> Nein die Fehlermeldung ist richtig, der Empfänger ist nicht bekannt.
>> Bloss daraufhin taucht halt der "too many errors" Eintrag auf, es läuft auch
>> nen ganze zeit durch und dann kommt der Fehler und dann läuft er wieder
>> druch und dann fängt es von vorne an.
>>
>> Na dann.
>>
>>>>> Feb 15 08:36:55 mail2 postfix/smtpd[18632]: > unknown[xxx]: 421
>>>> mailx.xxx.de Error: too many errors
>>>>> Feb 15 08:36:56 mail2 postfix/smtpd[18632]: match_hostname: unknown ~?
>>>> xxx
>>>>> Feb 15 08:36:56 mail2 postfix/smtpd[18632]: match_hostaddr: xxx ~? xxx
>>>>> Feb 15 08:36:56 mail2 postfix/smtpd[18632]: too many errors after DATA
>>>> from unknown[xxx]
>> Das verhalten ist afaik auch legitim.
>> Da versucht halt (ein potent. Spammer?) noch irgendwelchen Müll bei dir 
>> abzuladen.
>> Falls ich selbigen von mir gebe bitte korrigiert mich ...
>>
>>>>> Feb 15 08:36:56 mail2 postfix/smtpd[18632]: disconnect from
>> unknown[xxx]
>>>>> Wer kann mir hier vielleicht nen Tip geben. Er scheint ja schon beim
>>>> Empfang der Mails die Probleme zu haben.
>>>>
>>>> Zeig nochmal postconf -n.
>>>> und evtl. auch die aliases (virtual etc. auch). (Kann man ja logisch 
>>>> umschreiben wenn man Datenschutzbedenken hat ...)
>>> Als Aliasedatei, wird nur die /etc/aliases benutzt, die ist auch ok.
>>>
>>> Ausgabe von postconf -n
>>>
>>> alias_maps = hash:/etc/aliases
>>> biff = no
>>> broken_sasl_auth_clients = yes
>>> canonical_maps = hash:/etc/postfix/canonical
>>> command_directory = /usr/sbin
>>> config_directory = /etc/postfix
>>> daemon_directory = /usr/lib/postfix
>>> debug_peer_level = 2
>>> defer_transports =
>>> disable_dns_lookups = no
>>> html_directory = /usr/share/doc/packages/postfix/html
>>> inet_interfaces = all
>>> inet_protocols = all
>>> mail_owner = postfix
>>> mail_spool_directory = /var/mail
>>> mailbox_command = /usr/bin/procmail
>>> mailbox_size_limit = 0
>>> mailbox_transport =
>>> mailq_path = /usr/bin/mailq
>>> manpage_directory = /usr/share/man
>>> masquerade_classes = envelope_sender, header_sender, header_recipient
>>> masquerade_domains = $mydomain
>>> masquerade_exceptions = root
>>> message_size_limit = 50000000
>>> mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
>>> mydomain = xxx.de
>>> myhostname = xxx.xxx.de
>>> mynetworks = ip-provider, ip2-provider
>>> myorigin = $mydomain
>>> newaliases_path = /usr/bin/newaliases
>>> queue_directory = /var/spool/postfix
>>> readme_directory = /usr/share/doc/packages/postfix/README_FILES
>>> relay_domains = $mydomain
>>> relayhost =
>>> relocated_maps = hash:/etc/postfix/relocated
>>> sample_directory = /usr/share/doc/packages/postfix/samples
>>> sender_canonical_maps = hash:/etc/postfix/sender_canonical
>>> sendmail_path = /usr/sbin/sendmail
>>> setgid_group = maildrop
>> k. A. ob es relevant ist, du sagtest was von procmail?
>>
>>> smtp_sasl_auth_enable = no
>>> smtp_use_tls = no
>>> smtpd_client_restrictions = permit_mynetworks,
>> permit_sasl_authenticated, reject
>>> smtpd_delay_reject = yes
>>> smtpd_helo_required = no
>> Das sollte man schon anschalten?
> 
> Da die Mails alle von einem Provider kommen, ist des glaube ich egal, der sendet auf jedenfall ein helo. Und von anderen IPs nimmt die Firewall keine smtp-Connections an.

Ich bin da immer ein bisschen paranoid lieber 2 Sicherungen falls eine 
mal ausfällt ...


Hmm. Firewall macht die vielleicht irgendwelchen Mist?
Oder der Provider sendet irgendwelche "ungültigen Kommandos"
Vielleicht könntest du mal einen *kompletten* Log-Auszug einer 
Verbindung mit dem Provider posten,
evtl. gibt es ja erfolgreiche und nicht erfolgreiche zum Vergleichen.

Oder:
*Temporär* mal eine IP-Adresse für einen Telnet-Test von ausserhalb 
(Firewall und Postfix: mynetworks) freischalten und da mal versuchen 
Mails auf deinem Server abzusetzen und die Log-Einträge beobachten ob 
das anstandslos funktioniert ...

Ansonsten würde mir nur noch "mitsniffen" der Verbindung einfallen, wenn 
die Logs nix hergeben, das erfordert allerdings auch ein bisschen Erfahrung.

Vielleicht gibt es ja einen freundlichen Admin beim Provider der bei der 
Fehlersuche kooperiert?

[...]

>>>> Grüsse & hth
>>>> MH