inet_interfaces

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

inet_interfaces

@lbutlr
I changed my inet_interfaces setting this morning, and stopped and started postfix (postfix stop; postfix start)

# postconf -n inet_interfaces
inet_interfaces = 127.0.0.1, 65.121.55.42

But when I am trying to send emails to a certain company, I am getting an SPF error (even though my entire netblock is in the SPF settings) that claims I am connecting from a different IP (an IP that is assigned to the same physical machine as postfix) than specified in inet_interfaces.

status=bounced (host mail.synology.com[59.124.61.242] said: 550 5.7.1 <[hidden email]>: Recipient address rejected: Message rejected due to: SPF fail - not authorized. Please see http://www.openspf.net/Why?s=mfrom;id=(*munged*);ip=65.121.55.45;r=support@... (in reply to RCPT TO command))

covisp.net.             86400   IN      TXT     "v=spf1 mx a ip4:65.121.55.40/29 -all"

I know this is problem with the receiver, but I am concerned that it is reporting an IP that postfix shouldn't be using (.45 instead of .42).

<http://www.postfix.org/postconf.5.html#inet_interfaces>
When inet_interfaces specifies just one IPv4 and/or IPv6 address that is not a loopback address, the Postfix SMTP client will use this address as the IP source address for outbound mail. Support for IPv6 is available in Postfix version 2.2 and later.



Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces

Viktor Dukhovni


> On Apr 23, 2018, at 3:30 PM, @lbutlr <[hidden email]> wrote:
>
> I changed my inet_interfaces setting this morning, and stopped and started postfix (postfix stop; postfix start)
>
> # postconf -n inet_interfaces
> inet_interfaces = 127.0.0.1, 65.121.55.42
>
> But when I am trying to send emails to a certain company, I am getting an SPF error (even though my entire netblock is in the SPF settings) that claims I am connecting from a different IP (an IP that is assigned to the same physical machine as postfix) than specified in inet_interfaces.

You're looking for:

        smtp_bind_address = 65.121.55.42

The inet_interfaces setting controls what interfaces Postfix listens on,
not the local address of outgoing connections.

If you do make any connections to localhost for content filters and
the like, you'll need to unset smtp_bind_address for the transport
that connects to loopback addresses.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces

@lbutlr
On 2018-04-23 (13:38 MDT), Viktor Dukhovni <[hidden email]> wrote:

>
>> On Apr 23, 2018, at 3:30 PM, @lbutlr <[hidden email]> wrote:
>>
>> I changed my inet_interfaces setting this morning, and stopped and started postfix (postfix stop; postfix start)
>>
>> # postconf -n inet_interfaces
>> inet_interfaces = 127.0.0.1, 65.121.55.42
>>
>> But when I am trying to send emails to a certain company, I am getting an SPF error (even though my entire netblock is in the SPF settings) that claims I am connecting from a different IP (an IP that is assigned to the same physical machine as postfix) than specified in inet_interfaces.
>
> You're looking for:
>
> smtp_bind_address = 65.121.55.42

That would break many things.

> The inet_interfaces setting controls what interfaces Postfix listens on,
> not the local address of outgoing connections.

That does not match what the documentation says, which I quoted. Here it is again.

<http://www.postfix.org/postconf.5.html#inet_interfaces>
When inet_interfaces specifies just one IPv4 and/or IPv6 address that is not a loopback address, the Postfix SMTP client will use this address as the IP source address for outbound mail. Support for IPv6 is available in Postfix version 2.2 and later.


Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces

Viktor Dukhovni


> On Apr 23, 2018, at 3:50 PM, @lbutlr <[hidden email]> wrote:
>
> That does not match what the documentation says, which I quoted. Here it is again.
>
> <http://www.postfix.org/postconf.5.html#inet_interfaces>
> When inet_interfaces specifies just one IPv4 and/or IPv6 address that is not a loopback address, the Postfix SMTP client will use this address as the IP source address for outbound mail. Support for IPv6 is available in Postfix version 2.2 and later.

The conditions are:

   * Exactly one address (of the appropriate address family)
   * That address is not a loopback address

The text could be read as:

   * Exactly one non-loopback address (of the appropriate address family)

but that's not what is implemented.  If you also list "127.0.0.1" the bind address will not be set.  This makes sense, because either address may be needed for some subset of the connections.  The text could be more clear, but bottom line you need to set smtp_bind_address explicitly, possibly per-transport, if some transports deliver to localhost.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces

@lbutlr
On 2018-04-23 (14:13 MDT), Viktor Dukhovni <[hidden email]> wrote:
>
> On Apr 23, 2018, at 3:50 PM, @lbutlr <[hidden email]> wrote:
>> <http://www.postfix.org/postconf.5.html#inet_interfaces>
>> When inet_interfaces specifies just one IPv4 and/or IPv6 address that is not a loopback address, the Postfix SMTP client will use this address as the IP source address for outbound mail. Support for IPv6 is available in Postfix version 2.2 and later.
>
> The conditions are:
>
>   * Exactly one address (of the appropriate address family)
>   * That address is not a loopback address

That is not how I read it, I read it as one IPv4 and/or one IPv6 address (that is not a loopback which you can certainly have also because obviously you are almost certainly doing to have a loopback).

> The text could be read as:
>
>   * Exactly one non-loopback address (of the appropriate address family)

If that is what is intended, that would be much clearer, yes.

> but that's not what is implemented.  If you also list "127.0.0.1" the bind address will not be set.  This makes sense, because either address may be needed for some subset of the connections.  The text could be more clear, but bottom line you need to set smtp_bind_address explicitly, possibly per-transport, if some transports deliver to localhost.

OK, so I will simply write-off synology as a company that cannot do email properly. I'm not going to jump through a bunch of hoops just to try to please their broken server. Sadly, they cannot do webforms either as their form appears to only work in Chrome, so I'm not super impressed with them today.

Thanks for the explanation, but I do think the documentation needs to be clearer.


Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces

Viktor Dukhovni


> On Apr 23, 2018, at 5:09 PM, @lbutlr <[hidden email]> wrote:
>
>> If you also list "127.0.0.1" the bind address will not be set.  This makes sense, because either address may be needed for some subset of the connections.  The text could be more clear, but bottom line you need to set smtp_bind_address explicitly, possibly per-transport, if some transports deliver to localhost.
>
> OK, so I will simply write-off synology as a company that cannot do email properly. I'm not going to jump through a bunch of hoops just to try to please their broken server.

I don't think that splitting off traffic destined for 127.0.0.1 onto a separate transport is much work, in fact generally a good idea anyway, see for example the "scan" transport in:

        http://www.postfix.org/FILTER_README.html#advanced_filter 

With separate transports, one can have "-o smtp_bind_address=127.0.0.1" and the stock "smtp" and "relay" transports can have "-o smtp_bind_address=192.0.2.1" (or whatever you have for an external address).  Seems pretty light-weight to me, but you call of course for your systems...

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces

@lbutlr
On 2018-04-23 (15:30 MDT), Viktor Dukhovni <[hidden email]> wrote:
>
> With separate transports, one can have "-o smtp_bind_address=127.0.0.1" and the stock "smtp" and "relay" transports can have "-o smtp_bind_address=192.0.2.1" (or whatever you have for an external address). Seems pretty light-weight to me, but you call of course for your systems...

It's not weather it is light weight or not, it's simply finding all the places I would need to do this, sleeping track or it, all to try to fix someone else's broken server. It's not like this has ever been a problem with anyone else.



Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces

Benny Pedersen-2
In reply to this post by @lbutlr
@lbutlr skrev den 2018-04-23 21:30:

> covisp.net.             86400   IN      TXT     "v=spf1 mx a
> ip4:65.121.55.40/29 -all"

this domain have duplicates ipv4 in spf
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces

@lbutlr
On 2018-04-23 (20:33 MDT), Benny Pedersen <[hidden email]> wrote:
>
> @lbutlr skrev den 2018-04-23 21:30:
>
>> covisp.net.             86400   IN      TXT     "v=spf1 mx a
>> ip4:65.121.55.40/29 -all"
>
> this domain have duplicates ipv4 in spf

? SPF checks out fine at <https://mxtoolbox.com/SuperTool.aspx?action=spf%3acovisp.net&run=toolpage> and that range is my IP block.

I don't see anything duplicated.


Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces

Benny Pedersen-2
@lbutlr skrev den 2018-04-24 15:02:

> On 2018-04-23 (20:33 MDT), Benny Pedersen <[hidden email]> wrote:
>>
>> @lbutlr skrev den 2018-04-23 21:30:
>>
>>> covisp.net.             86400   IN      TXT     "v=spf1 mx a
>>> ip4:65.121.55.40/29 -all"
>>
>> this domain have duplicates ipv4 in spf
>
> ? SPF checks out fine at
> <https://mxtoolbox.com/SuperTool.aspx?action=spf%3acovisp.net&run=toolpage>
> and that range is my IP block.
>
> I don't see anything duplicated.

https://dmarcian.com/spf-survey/ test it here

we have now duplicated time on it
Reply | Threaded
Open this post in threaded view
|

Re: inet_interfaces

Bill Shirley
In reply to this post by @lbutlr
My approach would be to SNAT it with iptables.
-s pub.lic.adr.1 -m policy --pol none --dir out -j SNAT --to-source pub.lic.adr.2

Bill

On 4/23/2018 6:38 PM, @lbutlr wrote:
On 2018-04-23 (15:30 MDT), Viktor Dukhovni [hidden email] wrote:
With separate transports, one can have "-o smtp_bind_address=127.0.0.1" and the stock "smtp" and "relay" transports can have "-o smtp_bind_address=192.0.2.1" (or whatever you have for an external address). Seems pretty light-weight to me, but you call of course for your systems...
It's not weather it is light weight or not, it's simply finding all the places I would need to do this, sleeping track or it, all to try to fix someone else's broken server. It's not like this has ever been a problem with anyone else.