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
I do understand how it works but isn't there a way to force all smtp
connections through the proxy and make it send from there? I wouldnt think
this is so difficult given the many customizations we can do with almost
anything related to mail servers and proxying. Would an SNAT rule in
iptables or s
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
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 proxy. I already made
modi
20 matches
Mail list logo
