Vieri Di Paola:
> On Wed, Apr 15, 2020 at 3:35 PM Wietse Venema <wie...@porcupine.org> wrote:
> >
> > Vieri Di Paola:
> > > Hi,
> > >
> > > I'm using postfix as an smtp filter (antispam) which then forwards the
> > > messages to another mail server with user mailboxes.
> > >
> > > This server has private IP addr. 10.0.0.1, and the mailbox server has
> > > private IP addr. 10.0.0.10.
> > > So, external e-mails are first received by this filter and then
> > > forwarded to the mailboxes.
> > >
> > > It has been working fine for years, but a few days ago some e-mails
> > > were not coming in anymore, and the logs on the filtering server show
> > > messages such as this one:
> > >
> > > postfix/smtp[13093]: A306E1240B1: to=<m...@mydomain.org>, relay=none,
> > > delay=0.06, delays=0.06/0/0/0, dsn=5.4.6, status=bounced (mail for
> > > 10.0.0.10 loops back to myself)
> >
> > What has changed?
> >
> > > I'm still trying to understand what that means exactly.
> >
> > 1) It means that postfix/smtp[13093] received a request to deliver
> >    mail for mydomain.org.
> >
> >    ***Perhaps it should not have received that request.***
> 
> Yes, it should receive requests for mydomain.org. It is the antispam
> server where all e-mail for mydomain.org should go through first
> before being handed over to the mailbox server at 10.0.0.10.
> 
> > 2) It means that postfix/smtp[13093] looked up the MX for mydomain.org
> >    and found that Postfix itself (through the inet_interfaces and
> >    proxy_interfaces parameter values) is MX for mydomain.org.
> >
> >    ***Perhaps inet_interfaces or proxy_interfaces are in error.***
> >
> > Either way, the Postfix SMTP client will not deliver mail to an IP
> > address that Postfix is already receiving mail on.
> 
> Sorry if I might sound foolish, but why? Isn't what "transport" is for?

With this:

    /etc/postfix/transport:mydomain.org     smtp:[10.0.0.10]

mail was bounced because postfix/smtp[13093] found that
10.0.0.10 matches inet_interfaces or proxy_interfaces.

Why did postfix/smtp[13093] find this match? I suppose because
proxy_interfaces uses hostnames, which introduces a dependency
on DNS or /etc/hosts which are subject to change.

If the sender was external, the undeliverable mail will have been
returned there. If the sender was in mydomain.org, then there was
no way to deliver the non-delivery notification.  As defined in
SMTP standards, a non-delivery notification is discarded instead
of being bounced, as the latter would result in an infinite loop.

        Wietse

Reply via email to