[Postfixbuch-users] Versende Probleme mit Mac Outlook Expressunter OS 9

[Patrick Ben Koetter]

* Maik Weidemann <maillings at jg-service.de>:
> Hallo Patrick.
> 
> Sorry, habe ebend viel zu tun, deshalb kommt jetzt erst meine Antwort.
> 
> Patrick Ben Koetter schrieb:
> > Was ist genau konfiguriert? Was sagt das log?
> 
> Log-Eintrag zu den Vorgängen:
> Mar  5 18:23:14 server postfix/smtpd[20806]: connect from p54861E3B.dip0.t-ipconnect.de[84.134.30.59]
> Mar  5 18:23:14 server postfix/smtpd[20806]: NOQUEUE: reject: RCPT from p54861E3B.dip0.t-ipconnect.de[84.134.30.59]: 504 <arbeitszimmer>: Helo command rejected: need fully-qualified hostname; from=<user at example.org> to=<user at example.org> proto=SMTP helo=<arbeitszimmer>
> Mar  5 18:23:14 server postfix/smtpd[20806]: disconnect from p54861E3B.dip0.t-ipconnect.de[84.134.30.59]

Dieser Log-Auszug verweist nicht auf einen SMTP AUTH bezogenen Fehler sondern
er besagt, dass der Client zurückgewiesen wird, weil er als HELO-Name nicht
einen FQDN gesendet hat. Die Restriktion, die einen FQDN Hostnamen im HELO
fordert, heißt (jetzt noch) reject_non_fqdn_hostname. Doku dazu findest Du
unter <http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions>,
sektion reject_non_fqdn_helo_hostname.

Ich persönlich, rate Dir ab, diese Restriktion zu verwenden, weil es viel zu
viele, schlecht konfigurierte MTAs mit legitimer Mail gibt und Du mit
reject_non_fqdn_hostname viele (gute) Mail ablehnen wirst - wenn der Server
alleine für Dich da ist, kannst Du Dir so eine Haltung ggf. leisten. ;)

Anyway... Wie kann es überhaupt dazu kommen, dass reject_non_fqdn_hostname
ausgewertet wird, denn permit_sasl_authenticated steht in Deinen
smtpd_recipient_restrictions VOR reject_non_fqdn_hostname - der Client muss
also für permit_sasl_authenticated nicht in Frage gekommen sein und Postfix
hat weitergemacht, bis der Client über reject_non_fqdn_hostname gestolpert
ist.

> postconf -n:

Ich ziehe mal SMTP AUTH relevaten Passagen raus...

> broken_sasl_auth_clients = yes

OK. Das ist notwendig für Outlook.

> inet_interfaces = all
> myhostname = server.jg-service.de
> mynetworks_style = host
> smtpd_enforce_tls = no

Das sollte immer auf "no" sein, solange der Server seine Dienste auch im INET
und nicht nur in einem privaten Netz anbietet.

> smtpd_helo_required = yes
> smtpd_recipient_restrictions = 
    reject_non_fqdn_recipient,
    reject_non_fqdn_sender,
    reject_unlisted_recipient,
    permit_sasl_authenticated,

Hier müsste der Client bereits mit OK raus sein...
    
    permit_mynetworks,
    reject_unauth_destination,
    reject_non_fqdn_hostname,

Hier erwischt es den Client, weil er keinen FQDN Hostnamen sendet...

    check_recipient_access hash:/etc/postfix/sender_abuse,
    check_sender_access regexp:/etc/postfix/sender_blacklist,
    reject_unknown_recipient_domain,
    reject_invalid_hostname,
    reject_unknown_sender_domain,
    check_sender_access regexp:/etc/postfix/sender_corrupted,
    reject_unverified_sender,
    reject_rbl_client,
    reject_unknown_client,
    reject_unauth_pipelining,
    reject_rbl_client comcast.blackholes.us,
    check_policy_service inet:127.0.0.1:10023
> smtpd_reject_unlisted_sender = yes
> smtpd_restriction_classes = check_for_valid_sender
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_local_domain = server

Welches authentication backend fragt SASL denn ab, um Benutzer zu
verifizieren? sasldb? MySQL? LDAP? /etc/shadow?

> smtpd_sasl_security_options = noanonymous

Das ist OK.

> smtpd_sender_login_maps = hash:/etc/postfix/virtual, hash:/etc/postfix/confixx_virtualUsers, hash:/usr/local/mailman/data/virtual-mailman, hash:/usr/local/mailman/data/virtual-hand
> smtpd_tls_CAfile = /etc/postfix/cert/cacert.pem
> smtpd_tls_cert_file = /etc/postfix/cert/cert.pem
> smtpd_tls_key_file = /etc/postfix/cert/key.pem
> smtpd_tls_loglevel = 0
> smtpd_tls_received_header = yes
> smtpd_tls_session_cache_timeout = 3600s
> smtpd_use_tls = yes
> 
> Wenn in Outlook SSL benutzt wird, funktioniert es einwandfrei. Mit meinem
> Thunderbird habe ich keine Probleme weder ohne,mit TLS oder mit SSL.

Ich kann in Deiner Config bisher keinen Fehler entdecken. Bleibt also die
Frage, was der Client "sieht" und um welchen Client es sich handelt.

Kannst Du von "remote" aus mal einen telnet auf Deinen Server machen und ein
EHLO ... abasetzen, damit wir sehen können, was der Server anbietet?

> Ich glaub, es Problem besteht nicht bei allen Outlook Versionen.

Kannst Du in Erfahrung bringen, welche Outlook Versionen funktionieren und
welche scheitern? Wenn diese "outlooks" in verschiedenen Netzwerken stehen,
dann wäre es sehr gut von jedem Netzwerk in dem SMTP AUTH scheitert, ein
telnet auf den Server und ein EHLO inkl. der dann folgenden capabilities-Liste
zu sehen.

p at rick

-- 
Das »Postfix«-Buch
<http://www.postfix-buch.com>
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>