[Postfixbuch-users] mail loops back to myself fXr Backup MX Domaene
Sandy Drobic
postfixbuch-users at japantest.homelinux.com
Do Sep 21 20:25:50 CEST 2006
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
Mehr Informationen über die Mailingliste Postfixbuch-users