Re: Failed check loops back to myself
On Thu, Jun 17, 2010 at 06:55:33PM +0200, Carlos Velasco wrote: 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. 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 *** 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.
Re: Failed check loops back to myself
Carlos Velasco: 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
Re: Failed check loops back to myself
Work WITH the system, or else stop complaining. 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. :) 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.
Re: Failed check loops back to myself
On Fri, Jun 18, 2010 at 09:22, Carlos Velasco cvela...@cnic.es wrote: 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.
Re: Failed check loops back to myself
On Fri, Jun 18, 2010 at 10:30:35AM -0400, Phil Howard wrote: 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.
Re: Failed check loops back to myself
Victor Duchovni: On Fri, Jun 18, 2010 at 10:30:35AM -0400, Phil Howard wrote: 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... 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
Re: Failed check loops back to myself
On Fri, Jun 18, 2010 at 11:41:46AM -0400, Wietse Venema wrote: 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.
Re: Failed check loops back to myself
Victor Duchovni: On Fri, Jun 18, 2010 at 11:41:46AM -0400, Wietse Venema wrote: 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. 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
Re: Failed check loops back to myself
Some additional information. 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 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.
Re: Failed check loops back to myself
On Thu, Jun 17, 2010 at 06:01:33PM +0200, Carlos Velasco wrote: 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.
Re: Failed check loops back to myself
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. 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 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.
Re: Failed check loops back to myself
On Thu, Jun 17, 2010 at 06:55:33PM +0200, Carlos Velasco wrote: 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.
