On Wed, Dec 05, 2012 at 12:45:37PM +0100, d.davo...@mastertraining.it wrote:
> mydestination = mail2.mastercom, localhost.mastercom, localhost,
> mastertraining.it, registroelettronico.com, masterscuola.it,
> mastercom
> myhostname = mail.mastertraining.it
> relay_domains = $mydestination
> transport_maps = hash:/etc/postfix/transport
>
> With this config I keep having the bounce:
>
> Dec 5 12:06:10 mail2 postfix/smtp[20849]: 7FDFDA711C:
> to=<d.davo...@mastervoice.it>, relay=none, delay=0.01,
> delays=0.01/0/0/0, dsn=5.4.6, status=bounced (mail for
> mastervoice.it loops back to myself)
Remove the transport table entry responsible for this.
> I share this because it's odd enough in my eyes. I bet is some DNS
Almost certainly not, unless you have a chrooted /etc/resolv.conf
that uses an unexpected DNS server. (Debian systems like yours
often have chroot on by default).
> Anyway, I had to modify the transport table as workaround to deliver
> the email for mastervoice.it domain. Like this:
> .fax smtp:[192.168.1.211]
> mastervoice.it smtp:[ASPMX.L.GOOGLE.COM]
> autoreply.mastertraining.it gnarwl:
Are there any other entries in the transport table? Barring
explicit transport overrides the smtp(8) delivery agent uses
MX records, which it is clearly not doing.
Therefore, you may have content_filter settings in master.cf, or
a "*" entry in the transport table.
The order of precedence is roughly:
- content_filter
- transport_maps exact match
- transport_maps "*" entry
- sender_dependent_default_transport_maps,
default_transport,
sender_dependent_relayhost_maps,
- relayhost
Any of these can override the default nexthop. A wildcard possibility
is a firewall that rewrites all port 25 traffic back to your machine!
Report what you see when you telnet to the Google MX hosts from "mail2".
--
Viktor.
