ly could explain why.
> You can select a transport by destination domain, but not by destination MX.
> Probably what you need to do is to write an external program that interfaces
> with Postfix via "socketmap" or "tcp" type lookup table, checks the MX for
> th
Dnia 21.05.2024 o godz. 22:27:04 Henri Schomäcker via Postfix-users pisze:
>
> So what we need to do is to limit the sending rate to all MX servers
> under protection.outlook.com.
Postfix does not support this, Wietse probably could explain why.
You can select a transport by destinati
On 5/21/24 13:27, Henri Schomäcker via Postfix-users wrote:
So what we need to do is to limit the sending rate to all MX servers
under protection.outlook.com.
But it does not work with my configuration, all mails are still beeing
sent directly one after another, and I can't find out why.
So
Hi nw,
yes, it's an issue with protection.outlook.com Servers, but not with a
blacklist.
Ourcustomers are able to deliver about betweeen 700 and 1100 mails to
recipient addresses which domains MX is under protection.outlook.com.
And there seems to also be a configuration option for an
This is most likely the issue of outlook, not yours.
AFAIK outlook has the policy of IP blacklist. Maybe your IP happens to
hit it.
regards.
After a few hundred mails to different addresses who's domains use a
protection.outlook.com MX, the receiving servers respond with "...451
4.7.500
slowersmtp in main.cf and master.cf.
Then I thought I could use...
smtpd_recipient_restrictions =
check_recipient_mx_access pcre:/etc/postfix/mx_transport_filter
And in mx_transport_filter I could filter by outlook.com and all other
to choose the assigned smtp-transport.
But when I test it with...
On Wed, 13 Mar 2024 at 17:00, Viktor Dukhovni via Postfix-users
wrote:
>
> http://www.postfix.org/SMTPD_POLICY_README.html
>
Thank you Victor.
"The policy server replies with any action that is allowed in a
Postfix SMTPD access(5) table."
is exactly what I needed.
> Or deferring, with
the
> behaviours that I currently have statically defined in a transport map.
> These are:
>
> (condition1) customtransport:
Unclear how this avoids active queue congestion.
> (condition2) smtp:[othernode]
Or this. If a much larger queue size limit and much larger deli
ant to be able to generate, on a per message basis, the
behaviours that I currently have statically defined in a transport map.
These are:
(condition1) customtransport:
(condition2) smtp:[othernode]
Is this possible with either mechanism? What would the specific responses
be?
There is a
On Wed, Nov 08, 2023 at 12:41:55PM +0100, Norbert Schmidt via Postfix-users
wrote:
> Am I right, at the current moment this cannot be done within Postfix but
> would have to be done in the DNS system, right?
Your local resolver (e.g. unbound) could "assume ownership" of
er option would be to use the DNS resolver (Bind, unbound, etc)
> >>> support to manipulate zone lookups.
> >> But the OP wants a dedicated transport (for concurrency control and
> >> scheduling), not a change of destination IP, though in a multi-stage
.
But the OP wants a dedicated transport (for concurrency control and
scheduling), not a change of destination IP, though in a multi-stage MTA
setup that IP could point at a dedicated Postfix instance.
I know that, but it was not obvious to me that the OP needs to
support high volume.
Actually, I do
Viktor Dukhovni via Postfix-users:
> On Tue, Nov 07, 2023 at 08:14:04AM -0500, Wietse Venema via Postfix-users
> wrote:
>
> > Another option would be to use the DNS resolver (Bind, unbound, etc)
> > support to manipulate zone lookups.
>
> But the OP wants a dedicated
>> Another option would be to use the DNS resolver (Bind, unbound, etc)
>> support to manipulate zone lookups.
>
> But the OP wants a dedicated transport (for concurrency control and
> scheduling), not a change of destination IP, though in a multi-stage MTA
> s
On Tue, Nov 07, 2023 at 08:14:04AM -0500, Wietse Venema via Postfix-users wrote:
> Another option would be to use the DNS resolver (Bind, unbound, etc)
> support to manipulate zone lookups.
But the OP wants a dedicated transport (for concurrency control and
scheduling), not a
am looking for a way to send mail to domains that have such a mx record
> through a different transport (for instance through the mailjet service) but
> send all other mail the "normal" way.
>
> As I do not know in advance that a domain is using a M$-MX host, I cannot
> put all
through a different transport (for instance through the mailjet service) but
send all other mail the "normal" way.
As I do not know in advance that a domain is using a M$-MX host, I cannot
put all these domains into the transport table by hand.
I tried to use a regular expression &q
Hello,
You will find bellow parts of my script that create a virtual alias map from on
premise AD. You’ll have to work on transforming the output yourself
(/usr/local/bin/get_exchg_aliases.awk in my script).
And you’ll have to tune AD_FILTRE to suit your needs.
On Thu, Oct 26, 2023 at 07:46:40PM -0400, Joey J via Postfix-users wrote:
> My only concern is if there is as an example a recipient that has literally
> 2K email addresses with LDAP/AD, which associates with how much inbound
> mail wont that slow down delivery a good amount, and potentially
My only concern is if there is as an example a recipient that has literally
2K email addresses with LDAP/AD, which associates with how much inbound
mail wont that slow down delivery a good amount, and potentially create a
lot of overhead?
On Thu, Oct 26, 2023 at 7:42 PM Viktor Dukhovni via
On Thu, Oct 26, 2023 at 07:11:23PM -0400, Joey J via Postfix-users wrote:
> To confirm, I'm creating the list of valid emails to accept and then
> forward and if not in that list reject.
No, my advice is to replace the "list" with live LDAP queries to AD,
on demand during each SMTP transaction.
for a recipient. Postfix maintains a cache
> > for positive and negative reject_unverified_recipient results.
>
> Why not just query AD via LDAP? Use the below as a basis for a
> "virtual_alias_maps" tables (not transport!):
>
> main.cf:
> ldap = prox
not familiar with AD, but on the Postfix side can use
> reject_unverified_recipient to query a destination server if it
> would accept mail for a recipient. Postfix maintains a cache
> for positive and negative reject_unverified_recipient results.
Why not just query AD via LDAP? Use the below as a basis f
Thanks for the response Wietse, I have tried this but many servers won't
correctly allow the verification (its turned off) we have even added rules
to allow our IP's get the verification, but we end up delivering the
message only to then have it rejected which defeats the purpose.
Based on the
Joey J via Postfix-users:
> Hello All,
>
> I'm trying to see if someone has a good app to connect to an exchange or
> O365 server either via LDAP or AD to grab all of the legitimate email
> accounts, forwarding accounts and Groups in order to build a
> transport_recipients file this way reject
Hello All,
I'm trying to see if someone has a good app to connect to an exchange or
O365 server either via LDAP or AD to grab all of the legitimate email
accounts, forwarding accounts and Groups in order to build a
transport_recipients file this way reject all invalid email prior to
forwarding it
On 12.10.23 00:56, wesley--- via Postfix-users wrote:
How can I setup username based transport?
for incoming messages, such as use...@foo.com will be delivered to host a.
use...@foo.com will be delivered to host b.
transport_maps support username@domain notation:
http://www.postfix.org
Hello,
How can I setup username based transport?
for incoming messages, such as use...@foo.com will be delivered to host a.
use...@foo.com will be delivered to host b.
Thanks.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe
On Thu, Oct 12, 2023 at 02:02:55AM +0200, Daniel Ryšlink via Postfix-users
wrote:
> It's generally very useful to set up a specific transport for "sensitive"
> domains like gmail.com with specific policy (throttling outgoing message
> rate, etc).
>
> However, since mor
Hello,
It's generally very useful to set up a specific transport for
"sensitive" domains like gmail.com with specific policy (throttling
outgoing message rate, etc).
However, since more and more hosted domains use mail services for their
domains, it would be useful to be able
this topic and/or similar questions asked by others in
> other forums.
Unfortunately, some documentation had not been updated after new
features were added. ADDRESS_REWRITING_README was lagging behind
postconf(5) which did not help.
I added a new table that summarizes all the features that can
Matus UHLAR - fantomas via Postfix-users
writes:
> (...)
> for envelope from, simple access map should be enough:
> http://www.postfix.org/access.5.html
>
> and use DISCARD
Ok. Thanks for the heads-up, Matus!
Sincerely, Byung-Hee
--
^고맙습니다 _地平天成_ 감사합니다_^))//
uot;welcome to the internet," it's often
a good idea to disambiguate demonstrated points of confusion and/or
counteract easily found internet misinformation about the project, directly
in the project docs.
> @
In your original response you were probably narrowly thinking about a
specific tr
transport) or (...)
Go with easy way. See header_checks. `man 5 header_checks` ;;;
This [1] is real server conf files from my mail server.
[1] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-0919
for envelope from, simple access map should be enough:
http://www.postfix.org/access.5
Andrew Athan via Postfix-users writes:
> (...)
> My goal is to silently discard all inbound mail from a certain
> domain. Or actually, I may wish to redirect all of that mail either to
> a flat file (similar to the proposed blackhole transport) or (...)
Go with easy way. See header_
On Sat, Apr 22, 2023 at 07:58:25PM -0700, Andrew Athan wrote:
> If I understand it well enough I'll write and submit a doc PR.
This is unlikely to be productive.
> If I put all this together what I think I'm hearing is that transport_map
> overrides everything
The transport(5)
is included,
whereas the docs at transport(5) contradict that implication, leaving users
having to battle with google disinformation.
On Sat, Apr 22, 2023 at 6:45 PM Viktor Dukhovni via Postfix-users <
postfix-users@postfix.org> wrote:
> On Sat, Apr 22, 2023 at 05:56:12PM -0700,
I hope the message quoting/formatting in my response works as expected. If
not let me know and I will rely less on gmail's formatter.
>
> "This information is overruled with... the transport(5) table."
>
> In other words, "transport_maps", a logical dictionary
On Sat, Apr 22, 2023 at 05:56:12PM -0700, Andrew Athan via Postfix-users wrote:
> "This information is overruled with... the transport(5) table."
In other words, "transport_maps", a logical dictionary built from
a list of component tables (some of whic
I have read and re-read the documentation regarding transport(5) here:
https://www.postfix.org/transport.5.html
First, the docs for things like say "sender_dependent_relayhost_maps" say:
"This information is overruled with... the transport(5) table."
but what the heck is &qu
liquid cooled:
> Thanks for the quick response,
>
> 2) $ postconf -n | grep ldap
> transport_maps = hash:/etc/postfix/lookup/transport, ldap:/etc/postfix/
> mailtransport.cf
In that case, Postfix will always want to look up user@domain,
domain, and parent domains, because that i
sport_maps = hash:/etc/postfix/lookup/transport, ldap:/etc/postfix/
> mailtransport.cf
>
> 1) by "those domains" you are talking about the sender domains? Because
> these domains are unknown to my mailsystem as these are mails from external
> mailservers.
> If you m
Thanks for the quick response,
2) $ postconf -n | grep ldap
transport_maps = hash:/etc/postfix/lookup/transport, ldap:/etc/postfix/
mailtransport.cf
1) by "those domains" you are talking about the sender domains? Because
these domains are unknown to my mailsystem as these are mails fro
liquid cooled:
> Hello,
>
> I found out that my postfix does a lot of useless (LDAP) requests (in my
> opinion) when transport maps are enabled and in place.
> I use transport maps to map incoming mails to different destination hosts,
> based on destination mail address.
Hello,
I found out that my postfix does a lot of useless (LDAP) requests (in my
opinion) when transport maps are enabled and in place.
I use transport maps to map incoming mails to different destination hosts,
based on destination mail address.
So there should be no lookup at all for sender
W dniu 24.01.2023 o 13:03, Wietse Venema pisze:
natan:
W dniu 24.01.2023 o?12:05, Wietse Venema pisze:
natan:
Hi
For test i runnig gallera claster + haproxy
haproxy:
.
listen galera-test
bind 10.10.10.10:3307
balance leastconn
mode tcp
option tcplog
option tcpka
option httpchk
server
natan:
> W dniu 24.01.2023 o?12:05, Wietse Venema pisze:
> > natan:
> >> Hi
> >> For test i runnig gallera claster + haproxy
> >>
> >> haproxy:
> >> .
> >> listen galera-test
> >> bind 10.10.10.10:3307
> >> balance leastconn
> >> mode tcp
> >> option tcplog
> >> option tcpka
> >> option
W dniu 24.01.2023 o 12:05, Wietse Venema pisze:
natan:
Hi
For test i runnig gallera claster + haproxy
haproxy:
.
listen galera-test
bind 10.10.10.10:3307
balance leastconn
mode tcp
option tcplog
option tcpka
option httpchk
server sql1 10.10.10.11:3306 check port 9200 inter 12000 rise 2
natan:
> Hi
> For test i runnig gallera claster + haproxy
>
> haproxy:
> .
> listen galera-test
> bind 10.10.10.10:3307
> balance leastconn
> mode tcp
> option tcplog
> option tcpka
> option httpchk
>
> server sql1 10.10.10.11:3306 check port 9200 inter 12000 rise 2 fall 2
> server sql2
me times all works fine
And I would like to eliminate it and I dont have idea where i must find
"problem"
I use everywhere proxy:mysql:/etc/postfix/mysql_maps.
W dniu 20.01.2023 o 18:43, Wietse Venema pisze:
natan:
W dniu 20.01.2023 o?15:04, Wietse Venema pisze:
natan:
Hi
I t
tls_server_sni_maps = hash:/etc/postfix/vmail_ssl.map
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual
*# Transport (*/etc/postfix/transport*)
*
"domainname" relay:[oldhost IP] (i try smtp:[] too)
domainname is the domain i refer.
Thanks
If the do
305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHA
> CHA20_POLY1305_SHA256
> tls_preempt_cipherlist = yes
> tls_random_source = dev:/dev/urandom
> tls_server_sni_maps = hash:/etc/postfix/vmail_ssl.ma
natan:
> W dniu 20.01.2023 o?15:04, Wietse Venema pisze:
> > natan:
> >> Hi
> >> I try to run "backup" transport maps like:
> >>
> >> smtpd_sender_login_maps =
> >> #first-main database
> >> proxy:mysql:/etc/postfix/
W dniu 20.01.2023 o 15:04, Wietse Venema pisze:
natan:
Hi
I try to run "backup" transport maps like:
smtpd_sender_login_maps =
#first-main database
proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf
#second-backup
proxy:mysql:/etc/postfix/mysql_sender_login_maps-backu
/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual
*# Transport (*/etc/postfix/transport*)
*
"domainname" relay:[oldhost IP] (i try smtp:[] too)
domainname is the domain i refer.
Thanks
Il 17/01/2023 03:02, raf ha scritto:
On Fri, Jan 13, 2023 at 02:25:06PM +01
natan:
> Hi
> I try to run "backup" transport maps like:
>
> smtpd_sender_login_maps =
> #first-main database
> proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf
> #second-backup
> proxy:mysql:/etc/postfix/mysql_sender_login_maps-backup.cf
>
Hi
I try to run "backup" transport maps like:
smtpd_sender_login_maps =
#first-main database
proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf
#second-backup
proxy:mysql:/etc/postfix/mysql_sender_login_maps-backup.cf
Both databases are the same because they are synchroniz
Sean Hennessey:
> Is there a way to see the transport that queued mail is using?
>
> I just created a new transport and pointed a domain to it. The
> server also had mail for that domain queued up under the old
> transport.
>
> Is there any way I can find out what transp
Is there a way to see the transport that queued mail is using?
I just created a new transport and pointed a domain to it. The server also had
mail for that domain queued up under the old transport.
Is there any way I can find out what transport the mail is using?
I didn't see transport
same new soerver i've other virtual domain.
>
> I want that , for a few days, if one user of other domain hosted on the same
> new server send an email to the new migrate domain it will be relayed to the
> orld server and not locally delivered.
>
> I try with transport without
On Fri, Jan 13, 2023 at 05:36:16AM +, Sean Hennessey wrote:
> I was using the sender_dependent_default_transport_maps to pick off
> what I thought was going to be the interesting from domain. The good
> news is that this mail is coming from customer applications. It's not
> coming from
domain hosted on the
same new server send an email to the new migrate domain it will be
relayed to the orld server and not locally delivered.
I try with transport without success.
Can someone plese help me?
Thanks
--
Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.
Le
Sean Hennessey:
> I was using the sender_dependent_default_transport_maps to pick
> off what I thought was going to be the interesting from domain.
> The good news is that this mail is coming from customer applications.
> It's not coming from regular user mail clients. So I can guarantee
> there
.
From: owner-postfix-us...@postfix.org on
behalf of Viktor Dukhovni
Sent: Thursday, January 12, 2023 11:48 PM
To: postfix-users@postfix.org
Subject: Re: make transport decisions based on headers not envelope
On Fri, Jan 13, 2023 at 03:22:41AM +, Sean Hennessey wrote
).
- ...
So, provided the accepted recipients are *NEVER EVER* local or any other
address class, you'd want to use a milter to prepend a header that
indicates the exit transport, and then use milter_header_checks to
specify a "FILTER" action that forces all recipients to that transport
I'm back to the experts for some question. I'm trying to help dig some folks
out of hole. Is there anyway possible to make a decision on where to send mail
based on a friendly from header instead of the envelope from?
I just got done building up a multi-instance postfix set up that was supposed
Viktor Dukhovni:
> On Thu, Jun 16, 2022 at 07:35:20PM -0400, Wietse Venema wrote:
>
> > Bob Proulx:
> > > Is there a transport mapping equivalent to match against the MX host
> > > instead of against the the recipient address? That's really what is
>
Viktor Dukhovni wrote:
> Transport resolutiont that does remote DNS lookups will be a prohibitive
> performance bottleneck on systems delivering a steady non-trivial stream
> of mail. The queue manager is not multi-threaded, and each recipient
> domain can/will incur some delay.
Yes.
On Thu, Jun 16, 2022 at 07:35:20PM -0400, Wietse Venema wrote:
> Bob Proulx:
> > Is there a transport mapping equivalent to match against the MX host
> > instead of against the the recipient address? That's really what is
> > desired here. I didn't think such
Bob Proulx:
> Is there a transport mapping equivalent to match against the MX host
> instead of against the the recipient address? That's really what is
> desired here. I didn't think such a feature existed yet.
it would require a Postfix lookup table that returns MX hosts for
g list too. But when people have a domain it is
most likely to have only one subscriber address there.
Is there a transport mapping equivalent to match against the MX host
instead of against the the recipient address? That's really what is
desired here. I didn't think such a feature existed yet.
Bob
these settings go in main.cf:
>
> gmail_destination_concurrency_limit = 2
> gmail_destination_rate_delay = 1s
> gmail_destination_recipient_limit = 2
Moved those to main.cf.
> > In transport:
> >
> > gmail.com gmail:
>
> Sure, but the trailing &qu
Dnia 15.06.2022 o godz. 22:00:45 Bob Proulx pisze:
> It is interesting that mail to domains hosted at google that are not
> @gmail.com but other named domains delivered okay. Google accepted
> the exact same message to them fine.
It can be that some domains that are actually hosting their email
e settings go in main.cf:
gmail_destination_concurrency_limit = 2
gmail_destination_rate_delay = 1s
gmail_destination_recipient_limit = 2
> In transport:
>
> gmail.com gmail:
Sure, but the trailing ":" is unnecessary.
> Second is that I have three messages still in the mail queue that list
y fine documentation. But did I get it right?
In master.cf:
gmail unix - - y - - smtp
-o gmail_destination_concurrency_limit=2
-o gmail_destination_rate_delay=1s
-o gmail_destination_recipient_limit=2
In transport:
gmail.com gmail:
First... Is this reasonable? Yes it i
On Sat, May 28, 2022 at 03:09:40PM +0200, Joachim Lindenberg wrote:
> I don´t get why defining a different transport per domain should be
> easier than defining a tls policy per domain, and my configuration is
> mostly automated anyway.
Not *per-domain*, per TLS security level. Al
Hello Victor,
I don´t get why defining a different transport per domain should be easier than
defining a tls policy per domain, and my configuration is mostly automated
anyway. The automated part becomes a challenge right now with a combination of
dead mx plus insecure mx only - and the issue
Dear Joachim,
"Joachim Lindenberg" writes:
> Couldn´t run the python script due to postfix in docker, but can run
> postfix-finger domain - but this tells me what I already knew and
> wrote in my first mail. The certificate is not trusted and thus verify
> as default does not work, and it
Viktor Dukhovni writes:
> (... thanks ...)
> Yes. But in your case (with an overly strict default policy, requiring
> may exceptions) it would be more appropriate to define a dedicated
> transport for opportunistic unauthenticated TLS:
>
> # Or "dane" instead of
On Fri, May 27, 2022 at 09:21:23AM +0200, Joachim Lindenberg wrote:
> I added a transport map (or “route” as mailcow-dockerized calls it)
> that points to the alive MX
What was the exact form of the transport entry? Presumably, something
like:
example.com smtp:[mx1.example.com]
at all.
Does it?
Best Regards, Joachim
-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org <> Im Auftrag von Byung-Hee HWANG
Gesendet: Friday, 27 May 2022 14:11
An: postfix-users@postfix.org
Betreff: Re: AW: transport map with TLS policies?
Hellow Joachim,
"Joachim
Hellow Joachim,
"Joachim Lindenberg" writes:
> Hello Byung-Hee,
> I do have all of the following in my TLS policy:
> domainmay
> mx.domain may
> [mx.domain]:25may
> and it doesn´t work for me.
Well you could check that your server is 'good' or 'not
HWANG
Gesendet: Friday, 27 May 2022 11:01
An: postfix-users@postfix.org
Betreff: Re: transport map with TLS policies?
Hellow Joachim,
"Joachim Lindenberg" writes:
> I wanted to send a mail to a domain yesterday, that was using dead MX
> records and one the one MX that was
Hellow Joachim,
"Joachim Lindenberg" writes:
> I wanted to send a mail to a domain yesterday, that was using dead MX records
> and one
> the one MX that was alive, was presenting an untrusted certificate (my server
> uses verify
> by default). I added a transport m
I wanted to send a mail to a domain yesterday, that was using dead MX records
and one the one MX that was alive, was presenting an untrusted certificate (my
server uses verify by default). I added a transport map (or “route” as
mailcow-dockerized calls it) that points to the alive MX plus a TLS
Alex:
> Hi,
>
> Is it possible to specify multiple relay hosts in a transport map for load
> balancing/fault tolerance?
>
> example.com smtp:server1.com
> example.com smtp:server2.com
You can't have two entries with the same key.
As of a few years you can s
Hi,
Is it possible to specify multiple relay hosts in a transport map for load
balancing/fault tolerance?
example.com smtp:server1.com
example.com smtp:server2.com
I have a relay server set up as an MX for example.com. After mail is
processed, I'd like to forward it on to either
On 2022-01-27 23:14, Alex wrote:
btw, off-topic, but is anyone using fuglu in place of amavisd, which
seems kind of dead now?
so lets be offtopic, i do use fuglu in prequeue setup with postfix
more info in maillist or on fuglu https://gitlab.com/fumail/fuglu
Alex wrote:
Hi,
I have postfix-3.5.10 configured as a multi-instance along with
amavisd for spam filtering. Amavis is limited in its ability to create
different filtering policies for individual domains,
Unless a lot of functionality has been dropped since I last took a dive
in the Amavis
t instances is that routing of messages into content filters
> uses normal transport resolution machinery without relying on
> "content_filter" overrides.
FILTER_README needs updating. It is stuck in the past, before proper
multi-instance support was implemented
Wietse
ilters
uses normal transport resolution machinery without relying on
"content_filter" overrides.
> Amavis is limited in its ability to create different filtering
> policies for individual domains, so I wanted to be able to have
> amavisd run on one port for one domain and another
be to use transport_maps?
Maybe something like:
/etc/postfix-117/transport
domain1 relay:[127.0.0.1]:10024
domain2 relay:[127.0.0.1]:10025
Ideas/direction would be greatly appreciated.
btw, off-topic, but is anyone using fuglu in place of amavisd, which
seems kind of dead now?
Thanks,
Alex
from unknown[192.0.2.1];
from= to= proto=ESMTP
helo=: smtp-safe:
If smtp-sec (smtp-safe) is an SMTP client, it will try to connect
to port 25 using the recipient domain (testdomain.net) as the
destination, because by definition FILTER overrides transport maps.
If testdomain.net is a local
If smtp-sec (smtp-safe) is an SMTP client, it will try to connect
to port 25 using the recipient domain (testdomain.net) as the
destination, because by definition FILTER overrides transport maps.
If testdomain.net is a local destination, then you have a mail
delivery loop.
Wietse
be possible
since Postfix 2.7 with this entry to change the transport but not the
nexthop:
"... To override the recipient's transport but not the next-hop
destination, specify an empty filter destination ..."
I use postfix 3.5.6-1+b1 (Debian 11).
My postfix has a transport table f
On 8/5/2021 12:56 PM, Gomes, Rich wrote:
Anywhere else to look?
The logs.
-- Noel Jones
On Thu, Aug 05, 2021 at 05:56:54PM +, Gomes, Rich wrote:
> I can work with the linux team to have it tested and upgraded since I do not
> control the OS portion of the servers.
> I did postmap the transport file to no avail.
>
> Here is the results of postfix -n:
>
Thanks Noel
I can work with the linux team to have it tested and upgraded since I do not
control the OS portion of the servers.
I did postmap the transport file to no avail.
Here is the results of postfix -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_min_user
On 8/5/2021 12:07 PM, Gomes, Rich wrote:
Good day
I have a newly built postfix server which is ignoring it's transport file and
is querying DNS for MX records instead.
I have googled the issue but only come up with "how to use transport file"
articles.
The /etc/postfix directory
Good day
I have a newly built postfix server which is ignoring it's transport file and
is querying DNS for MX records instead.
I have googled the issue but only come up with "how to use transport file"
articles.
The /etc/postfix directory was copied from our Production relay and
1 - 100 of 1404 matches
Mail list logo
