Failed check "loops back to myself"
Carlos Velasco
I am having a weird problem of "loops back to myself" mail.
I have setup 2 postfix instances "work" and "dummy".
The "work" instance listen on IP 1.1.2.1 port 25 and deliver mail to
Internet and transport to another server for inside domains. This is
working fine.
The "dummy" instance is a new instance, listen on IP 1.1.2.1 port 12025
and its function should be simply to deliver received mail to "work"
instance on port 25.
The "dummy" instance has myhostname changed and relayhost set to:
relayhost = [1.1.2.1]:25
Problem is that "dummy" believes that destination is itself and "loops
back to myself" is logged. It is wrong because destination is really
"work" instance (port 25) not itself (port 12025).
Is there any way to solve this? Or any way to turn off this check for
this instance?
Jun 17 16:26:57 mail:info postfix-dummy/smtpd:
postfix-dummy/smtpd[2482]: connect from mx1.domain.com[1.1.2.1]
Jun 17 16:26:58 mail:info postfix-dummy/smtpd:
postfix-dummy/smtpd[2482]: 920B41E099: client=mx1.domain.com[1.1.2.1]
Jun 17 16:26:58 mail:info postfix-dummy/cleanup:
postfix-dummy/cleanup[2484]: 920B41E099:
message-id=<201006171426...@dummy-andromeda.domain.com>
Jun 17 16:26:58 mail:info postfix-dummy/qmgr: postfix-dummy/qmgr[2480]:
920B41E099: from=<fr...@srcdomain.com>, size=374, nrcpt=1 (queue active)
Jun 17 16:26:58 mail:warning postfix-dummy/smtp:
postfix-dummy/smtp[2485]: warning: relayhost configuration problem
Jun 17 16:26:58 mail:info postfix-dummy/smtp: postfix-dummy/smtp[2485]:
920B41E099: to=<desti...@dstdomain.com>, relay=none, delay=0.1,
delays=0.09/0.01/0/0, dsn=4.3.5, status=deferred (mail for 1.1.2.1 loops
back to myself)
As a workaround I can use, in "dummy" instance:
relayhost = [1.1.2.1]:2500
And then in "work" instance add the port (service) 2500 in master.cf as
smtp. This works as it seems that "loop check" is ignored if relayhost
is not to port 25, but I don't like this solution very much. Any other
way to turn this check off or so?
Regards,
Carlos Velasco
*************** AVISO LEGAL ***************
Este mensaje va dirigido, de manera exclusiva, a su destinatario y
contiene información confidencial y sujeta al secreto profesional,
cuya divulgación no está permitida por la ley. En caso de haber
recibido este mensaje por error, le rogamos que, de forma inmediata,
nos lo comunique mediante correo electrónico remitido a nuestra
atención o a través del teléfono (+34 914531200) y proceda a su
eliminación, así como a la de cualquier documento adjunto al mismo.
Asimismo, le comunicamos que la distribución, copia o utilización de
este mensaje, o de cualquier documento adjunto al mismo, cualquiera
que fuera su finalidad, están prohibidas por la ley. Le informamos,
como destinatario de este mensaje, que el correo electrónico y las
comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, así como
tampoco su integridad o su correcta recepción, por lo que el CNIC no
asume responsabilidad alguna por tales circunstancias. Si no
consintiese la utilización del correo electrónico o de las
comunicaciones vía Internet le rogamos nos lo comunique y ponga en
nuestro conocimiento de manera inmediata.
*************** LEGAL NOTICE **************
This message is intended exclusively for the person to whom it is
addressed and contains privileged and confidential information
protected from disclosure by law. If you are not the addressee
indicated in this message, you should immediately delete it and any
attachments and notify the sender by reply e-mail or by phone
(+34 914531200). In such case, you are hereby notified that any
dissemination, distribution, copying or use of this message or any
attachments, for any purpose, is strictly prohibited by law. We
hereby inform you, as addressee of this message, that e-mail and
Internet do not guarantee the confidentiality, nor the completeness
or proper reception of the messages sent and, thus, CNIC does not
assume any liability for those circumstances. Should you not agree
to the use of e-mail or to communications via Internet, you are
kindly requested to notify us immediately.
Carlos Velasco
Postfix version is 2.7.1
smtp -v shows:
Jun 17 18:36:00 mail:info postfix-dummy/smtp: postfix-dummy/smtp[4212]:
connecting to 1.1.2.1 port 25
Jun 17 18:36:00 mail:info postfix-dummy/smtp: postfix-dummy/smtp[4212]:
smtp_addr_one: host 1.1.2.1
Jun 17 18:36:00 mail:info postfix-dummy/smtp: postfix-dummy/smtp[4212]:
smtp_find_self: found self at pref 0
Jun 17 18:36:00 mail:warning postfix-dummy/smtp:
postfix-dummy/smtp[4212]: warning: relayhost configuration problem
...
Jun 17 18:36:00 mail:info postfix-dummy/smtp: postfix-dummy/smtp[4212]:
send attr action = delayed
Jun 17 18:36:00 mail:info postfix-dummy/smtp: postfix-dummy/smtp[4212]:
send attr reason = mail for 1.1.2.1 loops back to myself
Jun 17 18:36:00 mail:info postfix-dummy/smtp: postfix-dummy/smtp[4212]:
private/defer socket: wanted attribute: status
*************** AVISO LEGAL ***************
Este mensaje va dirigido, de manera exclusiva, a su destinatario y
contiene informaci�n confidencial y sujeta al secreto profesional,
cuya divulgaci�n no est� permitida por la ley. En caso de haber
recibido este mensaje por error, le rogamos que, de forma inmediata,
nos lo comunique mediante correo electr�nico remitido a nuestra
atenci�n o a trav�s del tel�fono (+34 914531200) y proceda a su
eliminaci�n, as� como a la de cualquier documento adjunto al mismo.
Asimismo, le comunicamos que la distribuci�n, copia o utilizaci�n de
este mensaje, o de cualquier documento adjunto al mismo, cualquiera
que fuera su finalidad, est�n prohibidas por la ley. Le informamos,
como destinatario de este mensaje, que el correo electr�nico y las
comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, as� como
tampoco su integridad o su correcta recepci�n, por lo que el CNIC no
asume responsabilidad alguna por tales circunstancias. Si no
consintiese la utilizaci�n del correo electr�nico o de las
comunicaciones v�a Internet le rogamos nos lo comunique y ponga en
Victor Duchovni
> The "dummy" instance has myhostname changed and relayhost set to:
> relayhost = [1.1.2.1]:25
The ":25" is not needed and best avoided.
> Problem is that "dummy" believes that destination is itself and "loops
> back to myself" is logged. It is wrong because destination is really
> "work" instance (port 25) not itself (port 12025).
Loop detection is on by default when the destination port is 25.
Loop detection matches on either banner hostnames or interfaces
or IP addresses found in inet_interfaces or proxy_addresses.
Remove 192.0.2.1 (better example address than 1.1.2.1) from
inet_interfaces in the "dummy" instance. e.g.:
inet_interfaces = 127.0.0.1
and in master.cf use
192.0.2.1:12025 smtp inet ... smtpd
to explicitly bind the IP owned (on port 25) by the other instance.
Then the IP address in question will not trigger loop detection.
Alternatively, you can override "inet_interfaces" for just the
smtp(8) delivery agent:
smtp unix ... smtp
-o inet_interfaces=127.0.0.1
Ideally, avoid port 25 forwarding between instances on the same host
where multiple instances use the same IP. So IMHO the non-default
forwarding port is the cleaner solution.
--
Viktor.
Carlos Velasco
> Loop detection matches on either banner hostnames or interfaces
> or IP addresses found in inet_interfaces or proxy_addresses.
It could be good to have a switch to turn it off for cases like this :)
> Alternatively, you can override "inet_interfaces" for just the
> smtp(8) delivery agent:
>
> smtp unix ... smtp
> -o inet_interfaces=127.0.0.1
I think I will go with this as this one doesn't need smtpd to listen on
127.0.0.1:25.
Thank you very much.
Regards
*************** AVISO LEGAL ***************
Este mensaje va dirigido, de manera exclusiva, a su destinatario y
contiene información confidencial y sujeta al secreto profesional,
cuya divulgación no está permitida por la ley. En caso de haber
recibido este mensaje por error, le rogamos que, de forma inmediata,
nos lo comunique mediante correo electrónico remitido a nuestra
atención o a través del teléfono (+34 914531200) y proceda a su
eliminación, así como a la de cualquier documento adjunto al mismo.
Asimismo, le comunicamos que la distribución, copia o utilización de
este mensaje, o de cualquier documento adjunto al mismo, cualquiera
que fuera su finalidad, están prohibidas por la ley. Le informamos,
como destinatario de este mensaje, que el correo electrónico y las
comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, así como
tampoco su integridad o su correcta recepción, por lo que el CNIC no
asume responsabilidad alguna por tales circunstancias. Si no
consintiese la utilización del correo electrónico o de las
comunicaciones vía Internet le rogamos nos lo comunique y ponga en
Victor Duchovni
> > Loop detection is on by default when the destination port is 25.
> > Loop detection matches on either banner hostnames or interfaces
> > or IP addresses found in inet_interfaces or proxy_addresses.
>
> It could be good to have a switch to turn it off for cases like this :)
>
> > Alternatively, you can override "inet_interfaces" for just the
> > smtp(8) delivery agent:
> >
> > smtp unix ... smtp
> > -o inet_interfaces=127.0.0.1
>
> I think I will go with this as this one doesn't need smtpd to listen on
> 127.0.0.1:25.
I think this is a mistake, in the sense that it is a crude work-around.
The right solution is keep the "inet_interfaces" settings of Postfix
instances *disjoint*, and to never forward mail to port 25 *within*
an instance. This keeps things clear and predictable.
- Each instance "owns" a separate pool of IPs
- Internal forwarding is never to port 25, that's
where outside mail comes in, and you never loop
it back-in again.
- Loop detection is not disabled.
Don't fight the system, work within the design.
--
Viktor.
Carlos Velasco
Sorry, but I don't see your point here.
I understand the check as to stop a mail bouncing to itself, but this is
not the case, mail is going from one instance to another. This is,
postfix is assuming that it is always listening on port 25 where this is
not the case, this instance is listening on another port (via master.cf)
and the other instance is the one listening on port 25. So the mail is
not bouncing to itself really. I looked into code and can see that the
check only applies to port 25, so I suppose it is rather an assumption
that postfix is always listening on that port. But really it is not the
case here.
As per a pool of ip addresses by instance, well, yes, it makes things
cleaner, although a bit more difficult into networking, but when we are
working with public Internet IP addresses it makes not happy to any NCC
to "waste" scarce public IP addresses for this :)
Regards,
Carlos Velasco
Wietse Venema
> > I think this is a mistake, in the sense that it is a crude work-around.
> > The right solution is keep the "inet_interfaces" settings of Postfix
> > instances *disjoint*, and to never forward mail to port 25 *within*
> > an instance. This keeps things clear and predictable.
> >
> > - Each instance "owns" a separate pool of IPs
> >
> > - Internal forwarding is never to port 25, that's
> > where outside mail comes in, and you never loop
> > it back-in again.
> >
> > - Loop detection is not disabled.
> >
> > Don't fight the system, work within the design.
> >
>
> Sorry, but I don't see your point here.
> I understand the check as to stop a mail bouncing to itself, but this is
> not the case, mail is going from one instance to another. This is,
Then,
- Give each instance its own IP address (use main.cf:inet_interfaces)
- Give each instance its own name (use main.cf:myhostname)
Work WITH the system, or else stop complaining.
Wietse
Carlos Velasco
>
> Wietse
I am NOT complaining at all, just giving my point of view. After all
this is one of the benefits of open source, to be cooperative and to see
multiple points of view, it tends to enhance products.
I am fine with the workarounds supplied and can see your point of view,
although I can't agree with a loop detected that is not a loop, I see
that it happens because inet addresses are mixed between instances and I
have my view about wasting more public ip addresses to do this as I told
before. That's all. Thank you all for your answers and comments. :)
Phil Howard
> I am NOT complaining at all, just giving my point of view. After all
> this is one of the benefits of open source, to be cooperative and to see
> multiple points of view, it tends to enhance products.
>
> I am fine with the workarounds supplied and can see your point of view,
> although I can't agree with a loop detected that is not a loop, I see
> that it happens because inet addresses are mixed between instances and I
> have my view about wasting more public ip addresses to do this as I told
> before. That's all. Thank you all for your answers and comments. :)
The original principle of the loop detection is based on where DNS MX
records would point to. That points to hostnames which point to IP
addresses. Port numbers are not part of it and are assumed to be the
SMTP port. How the detection is actually implemented could vary. But
it is traditional that the port is always 25 for mail exchange between
different servers, so assuming it is perfectly valid. There isn't a
way for you to set up a mail server that others can send mail to in
the normal way without it being on port 25. Something on another port
is just a hack for some purpose. If it's a hack, it should have work
arounds.
Victor Duchovni
> > I am fine with the workarounds supplied and can see your point of view,
> > although I can't agree with a loop detected that is not a loop, I see
> > that it happens because inet addresses are mixed between instances and I
> > have my view about wasting more public ip addresses to do this as I told
> > before. That's all. Thank you all for your answers and comments. :)
>
> The original principle of the loop detection is based on where DNS MX
> records would point to. That points to hostnames which point to IP
> addresses. Port numbers are not part of it and are assumed to be the
> SMTP port. How the detection is actually implemented could vary.
Not really, for loop detection to be effective, it must detect
cases in which remote domains specify unexpected MX records (even
127.0.0.1) or local transport tables are incomplete. When MX records
are bogus our transport tables are incomplete, the traffic will go
to port 25, so all port 25 connections must be tested.
The supported way to avoid loop detection false-positives on with
internal forwarding between Postfix instances is to:
- Ensure that each Postfix instance uses a separate set of
IP addresses.
and/or
- Not use port 25 as an internal forwarding destination when
IP address sharing is unavoidable.
This is robust and easy to document. The work-arounds I posted
also work, but are less elegant and should be avoided. If the
OP wants to use them, fine, he is fully informed...
--
Viktor.
Wietse Venema
I recommend a different myhostname per "port 25" instance. The
Postfix SMTP client verifies the HELO response and will declare a
loop when the best MX host replies to HELO with the client's own
myhostname.
Wietse
Victor Duchovni
> > This is robust and easy to document. The work-arounds I posted
> > also work, but are less elegant and should be avoided. If the
> > OP wants to use them, fine, he is fully informed...
>
> I recommend a different myhostname per "port 25" instance. The
> Postfix SMTP client verifies the HELO response and will declare a
> loop when the best MX host replies to HELO with the client's own
> myhostname.
Sure, but when the destination IP address is listed in inet_interfaces,
the connection is not even made and a loop is detected. Hostname tweaks
don't help in this case, the idea is to not forward to your own port
25, where "your own" means an IP address that is listed in instance's
"inet_interfaces".
--
Viktor.
Wietse Venema
Even if you have different IP addresses, Postfix will declare a
loop when the server responds with myhostname to HELO.
Therefore a different myhostname is NECESSARY but not sufficient.
Wietse