Dnia 6.10.2020 o godz. 18:30:28 Rick King pisze:
>
> Now our customer has subscribed to Shopify, which apparently sends
> messages using the customer's email address as the FROM address. Which
> results in a rejection with a 553 5.7.1 Sender address rejected: not
> logged in.
So I understand you
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 an
Hi
I thinking about rotate via iptables like
iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o
eth0 -m statistic --mode nth --packet 1 --every 2 -j SNAT --to-source IP1
iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o
eth0 -m statistic --mode nth --pa
Hello
Another problem is "Hello"
Does anyone have a solution to this IP rotation problem?
On 07.10.2020 12:46, natan wrote:
> Hi
> I thinking about rotate via iptables like
>
> iptables -t nat -I POSTROUTING -m state --state NEW -p tcp --dport 25 -o
> eth0 -m statistic --mode nth --packet 1 --eve
I'm trying to get smtpd_sender_login_maps to allow any sasl-auth'd user
to only send from the domain they are logged in as.
So SASL user "t...@example.com" would be able to send only from
"@example.com".
So far I have no luck turning the lookup table into this, is it even
possible?
Thanks
On Wed, Oct 7, 2020 at 2:34 PM Tom Sommer wrote:
>
> So SASL user "t...@example.com" would be able to send only from
> "@example.com".
smtpd_sender_login_maps = pcre:/etc/postfix/login_maps.pcre
content of /etc/postfix/login_maps.pcre:
/^(.*)@your(own)?domain\.org$/ ${1}
This would force sasl
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_dependent_default_transport_maps (for indiwy
Hi
Wietse thanks for replay - now I have that solutions
sender_dependent_default_transport_maps =
pcre:/etc/postfix/vipout.pcre,
1) memcache:/etc/postfix/memcache_sender_dependent_cache.cf,
2) memcache:/etc/postfix/memcache_sender_dependent_default_cache.cf
1) query to private IP for dom
On Wed, 7 Oct 2020 at 14:04, Vieri Di Paola wrote:
>
> On Wed, Oct 7, 2020 at 2:34 PM Tom Sommer wrote:
> >
> > So SASL user "t...@example.com" would be able to send only from
> > "@example.com".
>
> smtpd_sender_login_maps = pcre:/etc/postfix/login_maps.pcre
>
> content of /etc/postfix/login_map
Wietse;
I made the change but no luck. What I don't understand is how some
regex's work and others don't considering regex's themselves are so simple.
I mean, they should all work or they should all now work.
Thanks;
Frank
-Original Message-
From: owner-postfix-us...@postfix.org
[mai
Frank DiGennaro:
> Thanks for the reply. This is what I have in my 'virtual_users' file
> verbatim. I've even kept the domain names and users the same.
>
> # Regexp # User to forward to
> /\d{10,}@fax.mobilepbx.net/ asterisk (I've tried both
Wietse:
I apologize. I'm an idiot. I thought that I was showing you what I did. I
showed how I defined the virtual_alias_maps in man.cf, added the regex's
into the file 'virtual_users', and ran several tests such as 'postmap -q
555...@mobilepbx.net pcre:/etc/postfix/virtual_users'. What am I not
showin
Frank DiGennaro:
> Thanks for the reply. This is what I have in my 'virtual_users' file
> verbatim. I've even kept the domain names and users the same.
>
> # Regexp # User to forward to
> /\d{10,}@fax.mobilepbx.net/ asterisk (I've tried both
Wietse:
On Wed, Oct 07, 2020 at 02:44:47PM -0400, Frank DiGennaro wrote:
> I apologize. I'm an idiot. I thought that I was showing you what I did. I
> showed how I defined the virtual_alias_maps in man.cf, added the regex's
> into the file 'virtual_users', and ran several tests such as 'postmap -q
> 5
I went back and made the changes Noel Jones suggested Like so.
/^[0-9]+@fax.mobilepbx.net/ asterisk
/^[0-9]+@mobilepbx.net/ asterisk
This now works. Thank you very, very much.
Regards;
FSD
-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@po
Thanks for the heads up. I will do that.
Regards;
Frank
-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Viktor Dukhovni
Sent: Wednesday, October 7, 2020 3:09 PM
To: postfix-users@postfix.org
Subject: Re: Forward email based on
> On Oct 7, 2020, at 5:24 PM, Frank DiGennaro wrote:
>
> I went back and made the changes Noel Jones suggested Like so.
But these are not what Noel suggested:
> /^[0-9]+@fax.mobilepbx.net/ asterisk
> /^[0-9]+@mobilepbx.net/ asterisk
>
> This now works. Thank you very, very much.
-
Hi Viktor,
thanks a lot for your opinion.
Could you explain to me which would be the benefits of implementing
such behaviour on a filter or milter instead of doing it on
header_checks?
Also, do you know in which cases would be useful to allow or make use
of multiple From addresses? Just in case
On Wed, Oct 07, 2020 at 10:35:39PM +, Pau Peris wrote:
> Could you explain to me which would be the benefits of implementing
> such behaviour on a filter or milter instead of doing it on
> header_checks?
As I wrote upthread, and you quoted in your message:
> > RFC5322.From syntax is rather n
Yet it will still match regardless, so what's your point? I'm sorry if
my question was "beneath" you all and according to Wietz I "wasted" your
time with my question but it's not obvious to anyone that \d is not
supported. Bottom line, fuck you and all of you, I'm sorry that I wasted all
of you
On Wed, Oct 07, 2020 at 06:54:10PM -0400, Frank DiGennaro wrote:
> Yet it will still match regardless, so what's your point?
My point, and I am sorry if it is not welcome, is that a regular
expression has to not only match the things it SHOULD match, it *also*
needs to NOT match the things it SHO
Is there something I should be doing to mitigate this problem?
Oct 8 02:11:42 myserver postfix/smtpd[11630]: connect from
unknown[180.123.163.212]
Oct 8 02:11:43 myserver postfix/smtpd[11632]: connect from
unknown[180.123.163.212]
Oct 8 02:11:43 myserver postfix/smtpd[11632]: lost connection
On 10/6/20 4:23 PM, Wietse Venema wrote:
Demi M. Obenour:
On 10/6/20 12:46 PM, Wietse Venema wrote:
For me, 'not found' also includes the case that the user is not found
in the passwd file.
By "allow 'not found' users", do you mean that such users will
automatically be granted access, or that
I used to consider OpenSMTPD to be highly secure, until CVE-2020-8794
and CVE-2020-7247 came out. Both allow an attacker to execute
arbitrary shell commands as root. Even though both of these
attacks have been fixed, I am still not sure if it is possible for
a compromised unprivileged OpenSMTPD
On Thu, 8 Oct 2020 at 04:03, li...@lazygranch.com wrote:
>
> Is there something I should be doing to mitigate this problem?
>
> Oct 8 02:11:42 myserver postfix/smtpd[11630]: connect from
> unknown[180.123.163.212]
> Oct 8 02:11:43 myserver postfix/smtpd[11632]: connect from
> unknown[180.123.1
On 2020-10-07 15:03, Vieri Di Paola wrote:
On Wed, Oct 7, 2020 at 2:34 PM Tom Sommer wrote:
So SASL user "t...@example.com" would be able to send only from
"@example.com".
smtpd_sender_login_maps = pcre:/etc/postfix/login_maps.pcre
content of /etc/postfix/login_maps.pcre:
/^(.*)@your(own
26 matches
Mail list logo
