Dnia 1.08.2022 o godz. 14:55:32 post...@ptld.com pisze:
> What is unclear to me is what will postfix try to use when making an
> outbound connection when the server has two interfaces, first interface
> only has one public IP, and the 2nd interface has only one private
> (192.168.x.x) IP. Will po
On Mon, Aug 01, 2022 at 01:36:17PM -0400, post...@ptld.com wrote:
> On a server with two network interfaces, the first interface has one
> public IP, the seconds interface has one private (192.168.x.x) IP.
>
> inet_interfaces = all
> inet_protocols = all
>
will listen to ALL and bind to 0.0.0.0:25
With inet_interfaces=all,
- The Postfix server code does not choose a specific IP address;
instead (it listens on 0.0.0.0. It does this whether a machine has
one interface or 1000.
- The Postfix SMTP client will not choose a specific IP address
unless
> As you can see above, with "inet_interfaces = all" Postfix will
> LISTEN on all available IPv4 (or IPv6) interface addresses, and it
> will NOT BIND to a specific IPv4 (or IPv6) address.
Sorry if I'm being slow.
Yes postfix will listen to ALL and bind to 0.0.0.0:25
What is unclear to me is what
aces = all
> > inet_protocols = all
> > #smtp_bind_address =
> > #smtp_bind_address6 =
> >
> > With the following configuration it binds as such
> >
> > tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 21067/master
> > tcp6 0 0 :::25
>> The docs say
>>
>> when inet_interfaces specifies no more than one IPv4 address,
>> and that address is a non-loopback address, it is automatically
>> used as the smtp_bind_address
>
> That text was written before IPv6 wsupport was added. Ther
post...@ptld.com:
> Just to clarify my understanding:
>
> On a server with two network interfaces, the first interface has one public
> IP, the seconds interface has one private (192.168.x.x) IP.
>
> inet_interfaces = all
> inet_protocols = all
>
On Tue, 2 Aug 2022 at 00:04, wrote:
>
> >> No, the gateway is left blank on that interface. The private interfaces
> >> are just cabled together via a switch.
>
> > Then Postfix should not make any attempt to deliver mail using the
> > private address since it doesn't have a network route to deli
>> No, the gateway is left blank on that interface. The private interfaces are
>> just cabled together via a switch.
> Then Postfix should not make any attempt to deliver mail using the
> private address since it doesn't have a network route to deliver the
> mail through that interface anyways.
>
On Mon, 1 Aug 2022 at 23:33, wrote:
>
> > Hi,
> > Does your Private address 192.168.x.x have a default gateway as well?
> > Rgds/DP
>
> No, the gateway is left blank on that interface. The private interfaces are
> just cabled together via a switch.
>
> In systemd:
> [ipv4]
> address1=192.
> Hi,
> Does your Private address 192.168.x.x have a default gateway as well?
> Rgds/DP
No, the gateway is left blank on that interface. The private interfaces are
just cabled together via a switch.
In systemd:
[ipv4]
address1=192.168.0.200/24
may-fail=true
method=manual
inet_protocols = all
> #smtp_bind_address =
> #smtp_bind_address6 =
>
> With the following configuration it binds as such
>
> tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 21067/master
> tcp6 0 0 :::25 :::* LISTEN 21067/master
>
> The docs say
>
> when ine
Just to clarify my understanding:
On a server with two network interfaces, the first interface has one public IP,
the seconds interface has one private (192.168.x.x) IP.
inet_interfaces = all
inet_protocols = all
#smtp_bind_address =
#smtp_bind_address6 =
With the following
On Wed, Oct 27, 2021 at 06:36:14AM -0400, Wietse Venema
wrote:
> Dan Mahoney:
> > I've wondered this for a while, and have even suggested the day
> > job implement this in our own software.
> >
> > This feels like a reasonable place to ask. Is there a way, given
> > a new warning about compatib
Dan Mahoney:
> I've wondered this for a while, and have even suggested the day
> job implement this in our own software.
>
> This feels like a reasonable place to ask. Is there a way, given
> a new warning about compatibility_level (say you've been running
> with 3_5, and you're now running 3_6),
On Tue, Oct 26, 2021 at 08:50:38PM -0400, Viktor Dukhovni
wrote:
> On Tue, Oct 26, 2021 at 08:41:20PM -0400, Viktor Dukhovni wrote:
>
> > With `bash` inline /dev/fd/ files:
> >
> > $ diff -U0 <(postconf -x -o compatibility_level=2) <(postconf -x -o
> > compatibility_level=3.6)
>
> A hand
On Tue, Oct 26, 2021 at 08:41:20PM -0400, Viktor Dukhovni wrote:
> With `bash` inline /dev/fd/ files:
>
> $ diff -U0 <(postconf -x -o compatibility_level=2) <(postconf -x -o
> compatibility_level=3.6)
A handly abstraction to a couple function definitions would be:
compatconf() {
On Wed, Oct 27, 2021 at 11:34:57AM +1100, raf wrote:
> > Is there a way, given a new warning about compatibility_level (say
> > you've been running with 3_5, and you're now running 3_6), to see
> > what changes to your config are effectively made by enabling that
> > level? (effectively, to show a
Oct 2021 12:36:35 -0400 (EDT),
> >>> Wietse Venema wrote :
> >>>> This would require a new setting, for example to make smtp_bind_address
> >>>> failures a retryable error.
> >>>>
> >>>> smtp_bind_address_failure_action
> On Oct 26, 2021, at 4:54 PM, raf wrote:
>
> On Tue, Oct 26, 2021 at 09:42:33AM -0400, Wietse Venema
> wrote:
>
>> Vincent Pelletier:
>>> On Mon, 25 Oct 2021 12:36:35 -0400 (EDT),
>>> Wietse Venema wrote :
>>>> This would require a
On Tue, Oct 26, 2021 at 09:42:33AM -0400, Wietse Venema
wrote:
> Vincent Pelletier:
> > On Mon, 25 Oct 2021 12:36:35 -0400 (EDT),
> > Wietse Venema wrote :
> > > This would require a new setting, for example to make smtp_bind_address
> >
post...@ptld.com:
> >> It does not complicate the code. I am more concerned about
> >> discoverability (how would a user even find out that the behavior
> >> has become configurable).
> >
> > The best we can do is cross-reference the new parameter under
>
It does not complicate the code. I am more concerned about
discoverability (how would a user even find out that the behavior
has become configurable).
The best we can do is cross-reference the new parameter under
smtp_bind_address (and IPv6 equivalent), and then sufficiently
motivated
users
ter under
smtp_bind_address (and IPv6 equivalent), and then sufficiently motivated
users can find out how to make the setting a mandate rather than a
suggestion.
To me this looks like a reasonable feature request, despite the fact
that nobody else had asked for it in the first 24 years of Postfix.
So by no mea
Vincent Pelletier:
> On Mon, 25 Oct 2021 12:36:35 -0400 (EDT),
> Wietse Venema wrote :
> > This would require a new setting, for example to make smtp_bind_address
> > failures a retryable error.
> >
> > smtp_bind_address_failure_action = warn (or defer)
> >
On Mon, 25 Oct 2021 12:36:35 -0400 (EDT),
Wietse Venema wrote :
> This would require a new setting, for example to make smtp_bind_address
> failures a retryable error.
>
> smtp_bind_address_failure_action = warn (or defer)
>
> warn: current behavior
> defer: treat as a faii
o postfix stops falling back to
> no binding ?
This would require a new setting, for example to make smtp_bind_address
failures a retryable error.
smtp_bind_address_failure_action = warn (or defer)
warn: current behavior
defer: treat as a faiilure to connect
Wietse
sence of IP addresses
expected by the Postfix configuration, and add any transports whose
IP address is not configured to "defer_transports" (if not already
present) and execute "postfix reload".
You can collect the list of configured addresses via:
(
postconf -
On 25/10/2021 11:35, Vincent Pelletier wrote:
I would rather postfix just stop sending emails altogether in such case,
than send them from an unexpected ip: a delay is preferable to me to
uncertainty as to how the emails were processed by recipient SMTPs.
As a categorical prevention of postfix
thers continued to
accept the mails (and could have done all sort of bad things to them,
like file them in a spam box, ...).
The custom postfix settings I have for this setup are:
smtp_address_preference = ipv4
smtp_bind_address =
I am on postfix 3.4.14 (Debian oldstable).
I would rather po
serwer to incomming
>> 2)One server to outgoing
>>
>> All Customers in their mail clients (outgoing) use adress: smtp.foobar.org
>>
>> In main.cf I use? smtp_bind_address - for default IP send
>> and sender_dependent_default_transport_maps (for indiwydual IP)
>&g
natan:
> Hello
> I have such a solution:
>
> 1)One serwer to incomming
> 2)One server to outgoing
>
> All Customers in their mail clients (outgoing) use adress: smtp.foobar.org
>
> In main.cf I use? smtp_bind_address - for default IP send
> and sender_depende
; sending mail
>
> On 07.10.2020 12:10, natan wrote:
>> Hello
>> I have such a solution:
>>
>> 1)One serwer to incomming
>> 2)One server to outgoing
>>
>> All Customers in their mail clients (outgoing) use adress: smtp.foobar.org
>>
>> In m
eir mail clients (outgoing) use adress: smtp.foobar.org
>
> In main.cf I use smtp_bind_address - for default IP send
> and sender_dependent_default_transport_maps (for indiwydual IP)
> works fine.
>
> Is any change to "auto changing" IP in smtp_bind_address ?
> I kn
Hello
I have such a solution:
1)One serwer to incomming
2)One server to outgoing
All Customers in their mail clients (outgoing) use adress: smtp.foobar.org
In main.cf I use smtp_bind_address - for default IP send
and sender_dependent_default_transport_maps (for indiwydual IP)
works fine.
Is
Matus UHLAR - fantomas:
> Hello,
>
> we have exactly one non-looopback address in inet_interfaces. In this cause
> the address is also used as smtp_bind_address.
>
> can we still configure postfix send from any address?
>
> ...maybe smtp_bind_address=0.0.0.0 ?
Hello,
we have exactly one non-looopback address in inet_interfaces. In this cause
the address is also used as smtp_bind_address.
can we still configure postfix send from any address?
...maybe smtp_bind_address=0.0.0.0 ?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk
to send emails from that IPv4 address
> alone, instead choosing to send email from my IPv6 address about half the
> time. In main.cf <http://main.cf/>, I’ve tried every relevant combination of
> smtp_bind_address, smtp_bind_address6, inet_interfaces, and mynetworks that
> I can t
like to use to send emails.
> The problem is that Postfix refuses to send emails from that IPv4 address
> alone, instead choosing to send email from my IPv6 address about half the
> time. In main.cf, I’ve tried every relevant combination of
> smtp_bind_address, smtp_bind_address6, inet
send emails from that IPv4 address
alone, instead choosing to send email from my IPv6 address about half the
time. In main.cf, I’ve tried every relevant combination of
smtp_bind_address, smtp_bind_address6, inet_interfaces, and mynetworks that
I can think of. I’ve also tried setting smtp_bind_address
Rafa? Michalak:
> Hello
> I have small problem with smtp_bind_address
>
> When I set smtp_bind_address the second IP 195.x.x.27 it does not work,
> always sends using 195.x.x.26
>
> my "ip addr"
> 3: eth1: mtu 1500 qdisc mq state UP group
> default qle
Hello
I have small problem with smtp_bind_address
When I set smtp_bind_address the second IP 195.x.x.27 it does not work,
always sends using 195.x.x.26
my "ip addr"
3: eth1: mtu 1500 qdisc mq state UP group
default qlen 1000
inet 195.x.x.26/29 scope global eth1
valid_l
On Tue, Nov 01, 2016 at 11:17:10AM -0400, D'Arcy Cain wrote:
> I am not sure what I want. The smtp_bind_address has been in the
> config for ages, possibly added by someone else. I don't mind if
> Postfix listens on all interfaces and I can't even imagine a
> sce
D'Arcy Cain:
> I am not sure what I want. The smtp_bind_address has been in the config
> for ages, possibly added by someone else. I don't mind if Postfix
> listens on all interfaces and I can't even imagine a scenario where I
> would want to limit outgo
On 2016-10-31 03:39 PM, /dev/rob0 wrote:
On Mon, Oct 31, 2016 at 03:20:29PM -0400, D'Arcy Cain wrote:
Is this expected behaviour? I set smtp_bind_address to our
external interface to receive email
It affects outbound *only* ... it has nothing to do with mail
reception.
Doh! I
On Mon, Oct 31, 2016 at 03:39:59PM -0400, Bill Cole wrote:
> >I set smtp_bind_address to our external interface to receive email
>
> For symmetry perhaps there should be a smtpd_bind_address, but there is not.
> Instead there is inet_interfaces, which is (from the man page):
On 10/31/2016 2:20 PM, D'Arcy Cain wrote:
> Is this expected behaviour? I set smtp_bind_address to our external
> interface to receive email but I want to be able to send email
> internally. I do not need to receive on the the internal address.
smtp_bind_address is for sen
On 31 Oct 2016, at 15:20, D'Arcy Cain wrote:
Is this expected behaviour?
Yes. This is what smtp_bind_address *IS*
From the postconf(5) man page:
smtp_bind_address (default: empty)
An optional numerical network address that the Postfix SMTP
client
should bind to when maki
On Mon, Oct 31, 2016 at 03:20:29PM -0400, D'Arcy Cain wrote:
> Is this expected behaviour? I set smtp_bind_address to our
> external interface to receive email
It affects outbound *only* ... it has nothing to do with mail
reception.
smtp_* settings are for smtp(8), the Postfix
Is this expected behaviour? I set smtp_bind_address to our external
interface to receive email but I want to be able to send email
internally. I do not need to receive on the the internal address.
When I send mail to our internal network I just get a "Connection timed
out" error
7.102 netmask 0xfff8
> > broadcast 199.102.77.103 nd6
> > options=29
> > # postconf inet_interfaces
> > inet_interfaces = 199.102.77.99, localhost
> >
> > # postconf smtp_bind_address
> > smtp_bind_address =
> >
> > And on
s=29
> # postconf inet_interfaces
> inet_interfaces = 199.102.77.99, localhost
>
> # postconf smtp_bind_address
> smtp_bind_address =
>
> And on the destination server, the mail log says:
>
> Jun 5 19:23:52 barrida postfix/smtpd[57612]: connect from
> smtpc.telissant.net[19
t:
> >
> > # postconf inet_interfaces
> > inet_interfaces = 199.233.231.177, localhost
> >
> > But, the mail log on the destination server says:
> >
> > Jun 5 13:43:52 barrida postfix/smtpd[54769]: connect from
> > gtxd.x.rootbsd.net[162.217.
server says:
Jun 5 13:43:52 barrida postfix/smtpd[54769]: connect from
gtxd.x.rootbsd.net[162.217.113.30]
So, I added to the main.cf file:
# postconf smtp_bind_address
smtp_bind_address = 199.233.231.177
And now Postfix sends mail from the desired IP address,
199.233.231.177.
Jun 5 16:24
But, the mail log on the destination server says:
Jun 5 13:43:52 barrida postfix/smtpd[54769]: connect from
gtxd.x.rootbsd.net[162.217.113.30]
So, I added to the main.cf file:
# postconf smtp_bind_address
smtp_bind_address = 199.233.231.177
And now Postfix sends mail from the desired IP address
On 4/16/2015 6:32 AM, a jalela wrote:
> Hello
>
> We have setup postfix using smtp_bind_address with 100 ips having
> below configuration
>
> #
>
> #ip=10.11.17.13 host=multi328.postfix.example.com
> <http:
Hello
We have setup postfix using smtp_bind_address with 100 ips having below
configuration
#
#ip=10.11.17.13 host=multi328.postfix.example.com
10.11.17.13:25 inet n - n - 500 smtpd
-o content_filter=dksign
I knew something was wrong with this setup. The unauthorized agents sending
mail and the fact that I felt the MTA sending outbound directly was strange.
What was strange was what I thought!
--
View this message in context:
http://postfix.1071664.n5.nabble.com/smtp-bind-address-not-working-throu
You guys have been very helpful. Even if I needed a proxy, I should go with
another postfix as proxy and not something else like nginx. The best
solution is just a WAN facing postfix/dovecot but still use nginx for my
actual web. I fear a web exploit would gain access to everything including
the da
I'm glad you posted this. I have been seeing these various agents sending
email to me from addresses of my own domain that I don't even have. I have
been looking at the logs and these "agents" are being sent all day. It was
also a mess getting the smtp proxy to work both with imap proxy with nginx
Am 17.04.2014 19:04, schrieb sedandgrep:
> Yes you are correct. MTAs do send direct to other domains. But if there isn't
> a way to get postfix to send via the proxy, it defeats the purpose for my
> use. A workaround is simply to place the postfix/dovecot server on a
> completely separate box and
On Thu, Apr 17, 2014 at 10:04:26AM -0700, sedandgrep wrote:
> Yes you are correct. MTAs do send direct to other domains. But if there isn't
> a way to get postfix to send via the proxy, it defeats the purpose for my
> use. A workaround is simply to place the postfix/dovecot server on a
> completel
sedandgrep:
> Just the backend. The nginx is an smtp/imap proxy and both work fine. The
> only issue is that postfix seems to send directly to external domains, which
> I find strange.
In that case smtp_bind_address is not the solution. Instead
ise relayhost or transport_maps.
Wietse
Yes you are correct. MTAs do send direct to other domains. But if there isn't
a way to get postfix to send via the proxy, it defeats the purpose for my
use. A workaround is simply to place the postfix/dovecot server on a
completely separate box and run no smtp/imap proxy at all. I would have
better
On Thu, Apr 17, 2014 at 09:51:04AM -0700, sedandgrep wrote:
> Just the backend. The nginx is an smtp/imap proxy and both work fine. The
> only issue is that postfix seems to send directly to external domains, which
> I find strange.
This is a new use of the word "strange" I've never seen before.
Just the backend. The nginx is an smtp/imap proxy and both work fine. The
only issue is that postfix seems to send directly to external domains, which
I find strange.
--
View this message in context:
http://postfix.1071664.n5.nabble.com/smtp-bind-address-not-working-through-proxy-tp67034p67112.
sedandgrep:
> Any way to have the backend send through the proxy outbound? Would appreciate
> some input. Thanks again
Which of these runs Postfix?
Wietse
Any way to have the backend send through the proxy outbound? Would appreciate
some input. Thanks again
--
View this message in context:
http://postfix.1071664.n5.nabble.com/smtp-bind-address-not-working-through-proxy-tp67034p67109.html
Sent from the Postfix Users mailing list archive at Nabble.
lists:
While you were posting your response, I had just posted something right
before. My postfix machine is the one doing the sending to external domains,
bypassing the proxy somehow.
--
View this message in context:
http://postfix.1071664.n5.nabble.com/smtp-bind-address-not-working-through-p
es or smtp_bind_address help in this case?
--
View this message in context:
http://postfix.1071664.n5.nabble.com/smtp-bind-address-not-working-through-proxy-tp67034p67050.html
Sent from the Postfix Users mailing list archive at Nabble.com.
Am 16.04.2014 19:52, schrieb sedandgrep:
> The SPF record is defined only for the proxy machine and defining the actual
> backend postfix would reveal the backend IP. Are you saying that in this
> case SPF will not work unless I add a record for my backend postfix IP?
you need to understand SPF,
Ok. I actually am mistaken. I am at a different location. I was testing the
emails outbound from my actual postfix backend connected to my LAN (a
machine within the LAN) so the public ip will always appear as the one
mentioned. But the truth is, it isn't showing SPF failing based on the
client, but
The SPF record is defined only for the proxy machine and defining the actual
backend postfix would reveal the backend IP. Are you saying that in this
case SPF will not work unless I add a record for my backend postfix IP?
--
View this message in context:
http://postfix.1071664.n5.nabble.com/smt
Am 16.04.2014 19:07, schrieb sedandgrep:
> Upon inspection of the headers to an external domain (an email address I have
> at gmail), they show the SPF failing claiming that the ip of the client is
> not designated to send emails for our domain (the domain of our postfix of
> course)
you need to
Upon inspection of the headers to an external domain (an email address I have
at gmail), they show the SPF failing claiming that the ip of the client is
not designated to send emails for our domain (the domain of our postfix of
course)
--
View this message in context:
http://postfix.1071664.n5
sedandgrep:
> Hello,
>
> I have an imap/smtp proxy in a remote location that handles everything for
> the postfix backend. However, when sending to external domains such as
> gmail, those headers show my SPF as failing since the email seems to be
> coming from the actual client and not from the pr
modifications to master.cf as such and even included an SNAT rule in
iptables but I am new to SNAT'ing so that may be wrong:
master.cf
smtp unix - - - - - smtp
-o smtp_bind_address=43.38.30.84
relay unix - - - - - smtp
Smtp_bind_address behaves as documented; where did you define it?
This should normally go on a specific smtp service in master.cf, to override
that particular transport.
-Original Message-
From: "fr...@3dn.nl"
Sent: 20-1-2014 12:34
To: "postfix-us...@cloud9.net&quo
On 20.01.2014 14:47, Jose Ildefonso Camargo Tolosa wrote:
On Mon, Jan 20, 2014 at 7:25 AM, wrote:
On 20.01.2014 12:42, li...@rhsoft.net [3] wrote:
Am 20.01.2014 12:25, schrieb fr...@3dn.nl [1]:
Im trying to have postfix use smtp_bind_address with the address
set to multiple IP-aliasses (eg. e
On Mon, Jan 20, 2014 at 7:25 AM, wrote:
> On 20.01.2014 12:42, li...@rhsoft.net wrote:
>
>> Am 20.01.2014 12:25, schrieb fr...@3dn.nl:
>>
>>> I'm trying to have postfix use smtp_bind_address with the address set to
>>> multiple IP-aliasses (eg. eth1:0, et
Am 20.01.2014 12:55, schrieb fr...@3dn.nl:
> On 20.01.2014 12:42, li...@rhsoft.net wrote:
>> Am 20.01.2014 12:25, schrieb fr...@3dn.nl:
>>> I'm trying to have postfix use smtp_bind_address with the address set to
>>> multiple IP-aliasses (eg. eth1:0, eth1:1
>>
On 20.01.2014 12:42, li...@rhsoft.net wrote:
Am 20.01.2014 12:25, schrieb fr...@3dn.nl:
I'm trying to have postfix use smtp_bind_address with the address
set to multiple IP-aliasses (eg. eth1:0, eth1:1
etc.). As the default gateway is on eth0 and IP packets get routed
based on
Am 20.01.2014 12:25, schrieb fr...@3dn.nl:
> I'm trying to have postfix use smtp_bind_address with the address set to
> multiple IP-aliasses (eg. eth1:0, eth1:1
> etc.). As the default gateway is on eth0 and IP packets get routed based on
> their destination, it still seems t
Hi,
I'm trying to have postfix use smtp_bind_address with the address set
to multiple IP-aliasses (eg. eth1:0, eth1:1 etc.). As the default
gateway is on eth0 and IP packets get routed based on their destination,
it still seems that despite the smtp_bind_address setting, packets get
dir
On Wed, Jul 10, 2013 at 10:32:19AM +0530, Ram wrote:
> I guess I understand that. But I think the requirement would be
> reasonable If I have 2 networks I may need to have different bind
> addresses.
The code that implements smtp_bind_address is in smtp_connect_addr()
in src/smtp/smtp_
Ram:
>
> On 07/09/2013 05:33 PM, Wietse Venema wrote:
> > Ram:
> >> On 07/09/2013 04:24 PM, Wietse Venema wrote:
> >>> Ram:
> >>>> Today I use in master.cf
> >>>>
> >>>> smtp unix - - n
On 07/09/2013 05:33 PM, Wietse Venema wrote:
Ram:
On 07/09/2013 04:24 PM, Wietse Venema wrote:
Ram:
Today I use in master.cf
smtp unix - - n - - smtp
-o smtp_bind_address=X.X.X.X
-o fallback_relay=newhost
But I have a requirement that the
Ram:
> On 07/09/2013 04:24 PM, Wietse Venema wrote:
> > Ram:
> >> Today I use in master.cf
> >>
> >> smtp unix - - n - - smtp
> >> -o smtp_bind_address=X.X.X.X
> >> -o fallback_relay=newhost
>
On 07/09/2013 04:24 PM, Wietse Venema wrote:
Ram:
Today I use in master.cf
smtp unix - - n - - smtp
-o smtp_bind_address=X.X.X.X
-o fallback_relay=newhost
But I have a requirement that the fallback mails should be sent via a
different
Ram:
> Today I use in master.cf
>
> smtp unix - - n - - smtp
> -o smtp_bind_address=X.X.X.X
> -o fallback_relay=newhost
>
>
> But I have a requirement that the fallback mails should be sent via a
> different smtp_bind_addre
Today I use in master.cf
smtp unix - - n - - smtp
-o smtp_bind_address=X.X.X.X
-o fallback_relay=newhost
But I have a requirement that the fallback mails should be sent via a
different smtp_bind_address
How can I specify this in smtp fallback
Antonio Tommasi:
> Hi to all,
> i need to set smtp_bind_address dynamically with a query in mysql
> table but it dowesn't work.
The following may come as a surprise.
The smtp_bind_address feature works exactly as documented at
http://www.postfix.org/postconf.5.html#smtp_bind_add
Hi to all,
i need to set smtp_bind_address dynamically with a query in mysql table but it
dowesn't work.
Is it possible with another parameter?
thanks
--
Ing. Antonio Tommasi
Area Informatica
Area Infrastrutture - Servizio Posta Elettronica
Università del Salento - Lecce
tel. 0832 297373
week or so. However, while the DNS was propagating, we were
getting rejected mail from some remote servers that complained that
our forward and reverse lookups didn't match because our mail was
still going out the old IP.
http://www.postfix.org/postconf.5.html#smtp_bind_address saved our
bacon. We
On Fri, Jul 08, 2011 at 11:42:51PM +0200, Ansgar Wiechers wrote:
> is perfectly fine. And unless you have rather strict security
> requirements (in which case your ruleset would allow far less protocols
> to begin with), you can simply accept everything in the OUTPUT chain:
>
> iptables -P OUTPU
Okay.
Got it.
Thanks for the hollers.
I will do what I can.
On 7/8/2011 5:42 PM, Ansgar Wiechers wrote:
On 2011-07-08 Jeffrey Starin wrote:
When I turn off the firewall (which I am loath to do) to my VPS I am
able to use the command smtp_bind_address just fine.
Otherwise, with firewall
On 2011-07-08 Jeffrey Starin wrote:
> When I turn off the firewall (which I am loath to do) to my VPS I am
> able to use the command smtp_bind_address just fine.
>
> Otherwise, with firewall turned on, I am getting these time out
> errors in my maillog files:
>
> Jul 7
On Fri, Jul 08, 2011 at 04:37:58PM -0400, Jeffrey Starin wrote:
> On 7/8/2011 4:21 PM, Jeroen Geilman wrote:
> > On 2011-07-08 21:06, Jeffrey Starin wrote:
> >> When I turn off the firewall (which I am loath to do) to my VPS I am
> >> able to use the command
Am 08.07.2011 22:56, schrieb Jeffrey Starin:
> Are you saying I need an explicit rule for that smtp_bind_address to
> 127.0.0.1 for port 10027?
no you should fix your rules generally because it is a wonder that
this machine works as expected - never heard that anybody limits
the lo
I turn off the firewall (which I am loath to do) to my
VPS I am able to use the command smtp_bind_address just fine.
Otherwise, with firewall turned on, I am getting these time
out errors in my maillog files:
Jul 7 13:00:34 who postfix/smtp[40187]: connect to
127.0.0.1[127.0.0.1
1 - 100 of 132 matches
Mail list logo
