[Postfixbuch-users] mail loops back to myself fXr Backup MX Domaene

[Sandy Drobic]

thorsten wrote:
> Hallo.
> 
> Die Frage klingt, als gehoerte sie in eine CentOS UserGroup, ich hab
> aber schon mit CentOS Leuten zu diesem Thema gesprochen und die konnten
> mir nicht weiter helfen.
> 
> Ich arbeite seit kurzem auf CentOS. Mein Vorgaenger hat automatische
> Updates aktiviert, was waehrend ich auf Urlaub war zu einem Update von
> Postfix gefuehrt hat (neben einiger anderer Packete).
> 
> Seitdem ist es nicht mehr moeglich, an unsere MX Backup Domaene Mails zu
> versenden. Alles andere funktioniert.
> 
> Ich hab das rpm-source packet dann neu compiliert, was einen mysql
> fehler behoben hat, aber es gibt immer noch den loops back fehler.
> 
> Ich wollte euch nun fragen, ob ihr mir sagen koennt, wie ich
> nachvollziehen kann, woher Postfix glaubt, dass die Backupdomaene das
> eigene System ist.
> 
> 
> Der Log Eintrag:
> 
> Sep 21 16:02:49 homer postfix/smtp[13985]: 10FC2118A39:
> to=<user at backupdomain.com>, relay=none, delay=1, status=bounced (mail
> for mail.backupdomain.com loops back to myself)

Von welchem Server kommt dieser Eintrag, von mail.mydomain.com oder von 
mail1.backupdomain.com?
Generell weigert sich Postfix, Mails an einen MX weiterzuleiten, der eine 
niedrigere Priorität für die Domain hat als er selbst.

> 
> dig MX mydomain.com
> 
> mydomain.com.         86400   IN      MX      20 mail1.backupdomain.com.
> mydomain.com.         86400   IN      MX      10 mail.mydomain.com.
> 
> dig MX backupdomain.com:
> 
> backupdomain.com.       7200    IN  MX  20 mail.mydomain.com.
> backupdomain.com.       7200    IN  MX  10 mail1.backupdomain.com.
> 
> 
> POSTFIX VERSION 2.2.10 (CentOS 4.4)
> 
> Meine Konfig:
> 
> 
> # postconf -n
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases, hash:/etc/mailman/aliases
> biff = no
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> daemon_directory = /usr/libexec/postfix
> debug_peer_level = 2
> default_destination_concurrency_limit = 50
> default_process_limit = 30
> delay_warning_time = 4h
> disable_vrfy_command = yes
> fallback_transport = virtual
> home_mailbox = Maildir/
> html_directory = no
> in_flow_delay = 1s
> inet_interfaces = $myhostname, localhost
> local_destination_concurrency_limit = 5
> local_recipient_maps = unix:passwd.byname $alias_maps
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> maximal_queue_lifetime = 3d
> message_size_limit = 15240000
> mydestination = $myhostname, localhost.$mydomain, $mydomain
> mydomain = mydomain.com
> myhostname = mail.mydomain.com
> mynetworks = 127.0.0.0/8 <MYOFFICENETWORKIP>
> newaliases_path = /usr/bin/newaliases.postfix
> owner_request_special = no
> 
> proxy_interfaces = <BACKUPMXIP>
> 
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.2.10/README_FILES
> relay_domains = $transport_maps

Das ist immer wieder eine Quelle von Ärger, sobald du einen Transport für 
eine fremde Domain einträgst. Ich würde empfehlen, Transport nicht für 
Relaydomains zu recyceln.

> sample_directory = /usr/share/doc/postfix-2.2.10/samples
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtpd_helo_required = yes
> smtpd_recipient_restrictions = permit_mynetworks,
> reject_rbl_client sbl-xbl.spamhaus.org, reject_unauth_destination,
> reject_non_fqdn_sender, reject_non_fqdn_recipient,
> reject_unlisted_recipient,      reject_unknown_recipient_domain,
> reject_unauth_destination
> soft_bounce = no
> 
> transport_maps = mysql:/etc/postfix/sql/transport

Ich gehe davon aus, dass hier im Zusammenhang mit $relay_domains das 
Problem ist.



> unknown_local_recipient_reject_code = 550
> virtual_gid_maps = static:507
> virtual_mailbox_base = /server/vmail
> virtual_mailbox_maps = mysql:/etc/postfix/sql/vmailbox
> virtual_minimum_uid = 500
> virtual_transport = $transport_maps

Sehr interessante Kombination. Du hast den normalen Transport, und wenn 
der nicht funktioniert, geht der Fallback auf virtual der wiederum auf 
deine Transportmap zeigt. Was da nun wieder drin steht, kannst nur du 
herausfinden.


> virtual_uid_maps = static:507
> 
> 
> postmap -q backupdomain.com mysql:/etc/postfix/sql/transport
> gibt zurueck:
> smtp:mail1.backupdomain.com

Also erkennt Postfix die Domain als seine eigene (relay_domain) an und 
weigert sich, die Mail an den BackupMX weiterzuleiten. Logisch.

Sandy

-- 
Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com