Failed check "loops back to myself"
in [Postfix]
|
Prev: redirecting non local accounts to their respective domain email address
Next: redirecting non local accounts to their respective domainemail address
From: Carlos Velasco on 18 Jun 2010 08:01 > 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.
From: Wietse Venema on 18 Jun 2010 08:50 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
From: Carlos Velasco on 18 Jun 2010 09:22 > 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.
From: Phil Howard on 18 Jun 2010 10:30 On Fri, Jun 18, 2010 at 09:22, Carlos Velasco <cvelasco(a)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.
From: Victor Duchovni on 18 Jun 2010 10:43
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. |