domain. Your case is different
however because:
default_transport
sender_dependent_default_transport_maps
relay_transport
are specifically intended to take "relayhost" into account,
allowing users to separately specify the transport and
nexthop:
relayhost = ...
default_transport = smtp
--
Viktor.
On 2019-09-23 22:04, Viktor Dukhovni wrote:
As documented in transport(5), when a transport table entry does not
specify an explicit nexthop, it uses the extant (default) nexthop
for the recipient. In your case that's specified via "relayhost".
Of course! Thank you very much!
--
Jesper Dybda
> On Sep 23, 2019, at 3:48 PM, Jesper Dybdal wrote:
>
> I have tried the following:
>
>> relayhost = [smarthost.arrowmail.co.uk]:587
>> sender_dependent_default_transport_maps =
>> cdb:/etc/postfix/sender_default_transport
>>
>> # cat /etc/
@nuser:~# postconf -n | egrep "relay|transport" |grep -v restrictions
relayhost = [smarthost.arrowmail.co.uk]:587
sender_dependent_default_transport_maps =
cdb:/etc/postfix/sender_default_transport
root@nuser:~# cat /etc/postfix/sender_default_transport
jd-dir...@dybdal.dk smtp
W
vis to be
>>> DKIM signed then forwarded back to postfix for the final delivery.
>>>
>>> Lately, I wanted to have mails sent from `registrat...@asmodee.net` to
>>> be relayed by our ESP, so I added the following
>>> sender_dependent_default_transport_map
the final delivery.
>>
>> Lately, I wanted to have mails sent from `registrat...@asmodee.net` to
>> be relayed by our ESP, so I added the following
>> sender_dependent_default_transport_maps:
>>
>> /etc/postfix/sender_transport_maps:
>> asmodee.net sendgrid
to postfix for the final delivery.
>>
>> Lately, I wanted to have mails sent from `registrat...@asmodee.net` to
>> be relayed by our ESP, so I added the following
>> sender_dependent_default_transport_maps:
>>
>> /etc/postfix/sender_transport_maps:
>> asmodee.net
sent from `registrat...@asmodee.net` to
> be relayed by our ESP, so I added the following
> sender_dependent_default_transport_maps:
>
> /etc/postfix/sender_transport_maps:
> asmodee.net sendgrid:[smtp.sendgrid.net]:587
> * DUNNO
>
> Unfortunately this is not applied.
sen
our ESP, so I added the following
sender_dependent_default_transport_maps:
/etc/postfix/sender_transport_maps:
asmodee.net sendgrid:[smtp.sendgrid.net]:587
* DUNNO
Unfortunately this is not applied.
Here are the important bits of my config:
master.cf:
...
# incoming from Amavis DKIM signature
wie...@porcupine.org (Wietse Venema) writes:
> Eric Abrahamsen:
>> postfix/qmgr[25734]: 9BFA02B82C5: from=, size=796,
>> nrcpt=1 (queue active)
>> postfix/pr-out/smtp[25807]: 9BFA02B82C5:
>> to=,
>> relay=verifier.port25.com[38.95.177.125]:25, delay=1.2,
>> delays=0.88/0.02/0.24/0.09, dsn=2.6.0,
Eric Abrahamsen:
> postfix/qmgr[25734]: 9BFA02B82C5: from=, size=796,
> nrcpt=1 (queue active)
> postfix/pr-out/smtp[25807]: 9BFA02B82C5: to=,
> relay=verifier.port25.com[38.95.177.125]:25, delay=1.2,
> delays=0.88/0.02/0.24/0.09, dsn=2.6.0, status=sent (250 2.6.0 message
> received)
> postfix/
wie...@porcupine.org (Wietse Venema) writes:
> Wietse Venema:
>> Eric Abrahamsen:
>> > pr-out unix - - n - - smtp
>> >-o smtp_bind_address=184.106.81.119
>> >-o myhostname=mail.paper-republic.org
>> >-o smtp_helo_name=mail.paper-republic.org
>> >-o sy
Wietse Venema:
> Eric Abrahamsen:
> > pr-out unix - - n - - smtp
> >-o smtp_bind_address=184.106.81.119
> >-o myhostname=mail.paper-republic.org
> >-o smtp_helo_name=mail.paper-republic.org
> >-o syslog_name=paper-republic.org
>
> For this, and for th
Eric Abrahamsen:
> pr-out unix - - n - - smtp
>-o smtp_bind_address=184.106.81.119
>-o myhostname=mail.paper-republic.org
>-o smtp_helo_name=mail.paper-republic.org
>-o syslog_name=paper-republic.org
For this, and for the other transport, make the log
at before.
>>
>> This installation serves two domains, one of which is the one I'm using
>> to send this message. The other is supposed to be switched to a
>> different outgoing IP/host using
>> sender_dependent_default_transport_maps. This has been working just fine
domains, one of which is the one I'm using
> to send this message. The other is supposed to be switched to a
> different outgoing IP/host using
> sender_dependent_default_transport_maps. This has been working just fine
> for many months.
>
> Since the server upgrade, all messag
ng
to send this message. The other is supposed to be switched to a
different outgoing IP/host using
sender_dependent_default_transport_maps. This has been working just fine
for many months.
Since the server upgrade, all messages sent by the other domain show as
being sent by the IP for ericabrahamsen.net,
On Mon, Jun 20, 2016 at 6:02 PM, Wietse Venema wrote:
> I have opted to use the recipient as the "sender context" for sender
> address resolving, if the recipient is available. This means that
> the sender will "exist" when the recipient is allowed to send mail
> to it.
That's clever, and seems t
Russell Yanofsky:
> Thanks for taking a look at the patch. I attached an updated version
> that uses vstring primitives and adds the missing free.
>
> On Thu, Jun 16, 2016 at 7:42 PM, Wietse Venema wrote:
> > One complication is that the smtpd_resolve_addr cache is not only
> > used for validatin
Thanks for taking a look at the patch. I attached an updated version
that uses vstring primitives and adds the missing free.
On Thu, Jun 16, 2016 at 7:42 PM, Wietse Venema wrote:
> One complication is that the smtpd_resolve_addr cache is not only
> used for validating recipients, but also for val
Russell Yanofsky:
> The attached patch fixes the problem for me. It changes the relevant
> smtpd_resolve_addr() call in smtpd_check.c to use the message sender.
One complication is that the smtpd_resolve_addr cache is not only
used for validating recipients, but also for validating senders.
See ch
The attached patch fixes the problem for me. It changes the relevant
smtpd_resolve_addr() call in smtpd_check.c to use the message sender.
diff --git a/src/smtpd/smtpd_check.c b/src/smtpd/smtpd_check.c
index 74e42d7..2d8c6b7 100644
--- a/src/smtpd/smtpd_check.c
+++ b/src/smtpd/smtpd_check.c
@@ -510
Could anyone confirm whether this seems like a real bug before I spend
time trying to work around or fix it? To summarize, my configuration
is:
default_transport = error:External delivery disabled
sender_dependent_default_transport_maps = inline:{
@yanofsky.org=smtp:[smtp-relay.gmail.com]:587
ndling of sender_dependent_default_transport_maps
> within smtpd when default_transport is set to error:...
>
> I'm configuring postfix as follows using default_transport and
> sender_dependent_default_transport_maps to reject all external
> outgoing mail, unless the envelope sender com
Hi,
I think there is a bug in handling of sender_dependent_default_transport_maps
within smtpd when default_transport is set to error:...
I'm configuring postfix as follows using default_transport and
sender_dependent_default_transport_maps to reject all external
outgoing mail, unles
Thanks.
On 22/07/15 18:49, Wietse Venema wrote:
Edgaras Luko?evi?ius:
All this is done to put users into our own "classes" (eg. spammers vs.
non-spammers). Because there are clean and dirty IP pools and if we see
that user *may be* abusing email (or any other) system we want to put
them to "dir
On 22/07/15 18:05, Viktor Dukhovni wrote:
On Wed, Jul 22, 2015 at 05:55:04PM +0300, Edgaras Luko?evi?ius wrote:
All this is done to put users into our own "classes" (eg. spammers vs.
non-spammers).
If your autheneticated submission user is spamming, suspend their
ability to send outbound ema
Edgaras Luko?evi?ius:
> All this is done to put users into our own "classes" (eg. spammers vs.
> non-spammers). Because there are clean and dirty IP pools and if we see
> that user *may be* abusing email (or any other) system we want to put
> them to "dirty" pool for some time. While this works
On Wed, Jul 22, 2015 at 05:55:04PM +0300, Edgaras Luko?evi?ius wrote:
> All this is done to put users into our own "classes" (eg. spammers vs.
> non-spammers).
If your autheneticated submission user is spamming, suspend their
ability to send outbound email.
> Because there are clean and dirty IP
ecipient: alias1@mydomain
after unpacking:
sender: send...@hotmail.com
recipient: recipie...@gmail.com
Obviously, sender_dependent_default_transport_maps won't work here.
It works exactly as documented, by selecting the transport based
on the sender.
velope sender.
This requires that the aliases in question be local aliases(5).
> Now If I receive email from send...@hotmail.com to alias alias1@mydomain and
> forward it to recipie...@gmail.com
> sender: send...@hotmail.com
> recipient: alias1@mydomain
>
> after unpacking:
> se
- - smtp
-o syslog_name=outbound2
-o smtp_helo_name=reverse.do.main
-o smtp_bind_address=Y.Y.Y.Y
For "ordinary" users I just use sender_dependent_default_transport_maps
with SQL query that binds sender -> transport, for example:
user1@domain1 ->
On Fri, Feb 13, 2015 at 04:56:49PM +0100, Robert Dahlem wrote:
> >> /etc/postfix/sender_dependent_transport:
> >>
> >> @example.tld smtp_example:
> >
> > Set the relayhost above (smtp_example:[example_server1])
>
> That works now, thank you!
>
Hi Viktor,
On 13.02.2015 16:49, Viktor Dukhovni wrote:
>> I got this domain example.tld for which I need to relay all mail FROM
>> this domain through a specific mail server. For this I tried to deploy
>> sender_dependent_default_transport_maps.
>
> The "relayhost&
On Fri, Feb 13, 2015 at 04:39:20PM +0100, Robert Dahlem wrote:
> I got this domain example.tld for which I need to relay all mail FROM
> this domain through a specific mail server. For this I tried to deploy
> sender_dependent_default_transport_maps.
The "relayhost" parameter
Hi,
I got this domain example.tld for which I need to relay all mail FROM
this domain through a specific mail server. For this I tried to deploy
sender_dependent_default_transport_maps.
main.cf:
default_transport = smtp
mydomain = example.info
relay_domains =
$myhostname
Wietse Venema porcupine.org> writes:
>
> Fabio Sangiovanni:
> sender_dependent_default_transport_maps supports different syntax
> than transport_maps.
>
> Both support the form "name:" and "name" (both mean the same thing).
> That's where the
y to specify a
> null nexthop in sender_dependent_default_transport_maps,
> while the documentation states clearly that it's
> not supported.
sender_dependent_default_transport_maps supports different syntax
than transport_maps.
Both support the form "name:" and "name" (both me
Fabio Sangiovanni nweb.it> writes:
> Is someone willing to clarify this a little?
Sorry if I quote myself, but what about this?
Is it to be considered an error in the docs?
I'm referring to the possibility to specify a
null nexthop in sender_dependent_default_transport_maps
Wietse Venema porcupine.org> writes:
>
> Fabio Sangiovanni:
> > Hi all,
> >
> > from the docs of sender_dependent_default_transport_maps:
> > "Note: this overrides default_transport, not transport_maps, and
> > therefore the expected syntax is that
Fabio Sangiovanni:
> Hi all,
>
> from the docs of sender_dependent_default_transport_maps:
> "Note: this overrides default_transport, not transport_maps, and
> therefore the expected syntax is that of default_transport, not the
> syntax of transport_maps. Specifically, th
Hi all,
from the docs of sender_dependent_default_transport_maps:
"Note: this overrides default_transport, not transport_maps, and
therefore the expected syntax is that of default_transport, not the
syntax of transport_maps. Specifically, this does not support the
transport_maps synta
On Wed, Oct 24, 2012 at 02:39:04PM -0700, Robert Minsk wrote:
> In my main.cf I have
>
> sender_dependent_default_transport_maps = tcp:localhost:6002
>
> and in my master.cf I have:
> 10025 inet n - n - - smtpd
> -o syslog_name=postfix/10025
> -o content_filter=scan
In my main.cf I have
sender_dependent_default_transport_maps = tcp:localhost:6002
and in my master.cf I have:
10025 inet n - n - - smtpd
-o syslog_name=postfix/10025
-o content_filter=scan:[127.0.0.1]:11125
-o receive_override_options=no_address_mappings
Le 07/08/2012 18:14, Viktor Dukhovni a écrit :
On Tue, Aug 07, 2012 at 05:51:43PM +0200, zorg wrote:
Reading the manual, it explain that
sender_dependent_default_transport_maps override default_transport
Which selects the delivery agent and nexthop for *external* recipients
based on the
On Tue, Aug 07, 2012 at 05:51:43PM +0200, zorg wrote:
> Reading the manual, it explain that
> sender_dependent_default_transport_maps override default_transport
Which selects the delivery agent and nexthop for *external* recipients
based on the sender. This is NOT an access control mec
Hello
let me explains
Reading the manual, it explain that
sender_dependent_default_transport_maps override default_transport
first I want to white-list sender address allow to sender mail to other
domain
so fisrt I did that
in main.cf
default_transport = error:error message
tp_bind_address=$bar_smtp_bind_address
...
main.cf:
indexed = ${default_database_type}:${config_directory}/
sender_dependent_default_transport_maps = ${indexed}def-xprt
...
foo_smtp_bind_address = 192.0.2.1
bar_smtp_bind_address = 192.0.2.2
.
ress
bar_smtp unix - - - - - smtp
-o smtp_bind_address=$bar_smtp_bind_address
...
main.cf:
indexed = ${default_database_type}:${config_directory}/
sender_dependent_default_transport_maps = ${indexed}def-xprt
...
foo_sm
o go through
1.1.1.1, and all mail sent from a sender address of *@example2.com
to go through 1.1.1.2."
What does "go through" mean?
My understanding is sender_dependent_default_transport_maps is what
I want here based on my research prior to emailing this list, but I
could be wr
om
to go through 1.1.1.2."
What does "go through" mean?
My understanding is sender_dependent_default_transport_maps is what
I want here based on my research prior to emailing this list, but I
could be wrong. I don't feel like I need an O'Reily book to achieve
this...
Th
h 1.1.1.2."
What does "go through" mean?
> My understanding is sender_dependent_default_transport_maps is what
> I want here based on my research prior to emailing this list, but I
> could be wrong. I don't feel like I need an O'Reily book to achieve
> this...
ender address of *@example2.com to go through
1.1.1.2."
My understanding is sender_dependent_default_transport_maps is what I
want here based on my research prior to emailing this list, but I could
be wrong. I don't feel like I need an O'Reily book to achieve this...
On 7/30/2
On Mon, Jul 30, 2012 at 09:57:10PM -0500, Russell Jones wrote:
> Thanks Viktor. I feel like I am closer, just not quite there yet. I
> am now getting the following error:
> mail for 1.1.1.1 loops back to myself
>
> main.cf:
> sender_dependent_default_transport_maps =
>
Thanks Viktor. I feel like I am closer, just not quite there yet. I am
now getting the following error:
mail for 1.1.1.1 loops back to myself
main.cf:
sender_dependent_default_transport_maps =
hash:/etc/postfix/sender_dependent_default_transport_maps
master.cf:
1.1.1.1:smtp inetn
ix
this one by using the correct syntax, as documented at:
http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
http://www.postfix.org/postconf.5.html#default_transport
http://www.postfix.org/transport.5.html
> Btw I believe I have thunderbird set to send in plain text now to
> this mailing list.
Thanks.
--
Viktor.
Hi Viktor,
I have been following (or attempting to follow) these two sites I found
that showed how to set this up. They both show domain then transport:
http://www.ericmichaelstone.com/?p=5359
http://www.zoobey.com/index.php/resources/all-articles-list/210-postfix-outbound-mail-router-by-domai
On Sun, Jul 29, 2012 at 08:26:24PM -0500, Russell Jones wrote:
[ No HTML posts, please! ]
> /@domain2\.com$/ 1.1.1.2:smtp:
Why do you believe this is the correct syntax? The transport(5)
documentation specifies:
transport:nexthop
not
nexthop:transport
--
Viktor.
Hi all,
I am having a very difficult time getting
sender_dependent_default_transport_maps to actually work as
described.
I have a simple postfix 2.9.3 server with 2 IP addresses. I want all
mail sent from a sender address of *@example1 to go through 1.1.1.1
, but now we have
a need for sender-dependent transport rules. We periodically creates
the sender_dependent_default_transport_maps, which appeared to work
perfectly, but then we discovered that the transport table overrides
sender-dependent transport - exactly as documented.
We have a requiremen
e
> > a need for sender-dependent transport rules. We periodically creates
> > the sender_dependent_default_transport_maps, which appeared to work
> > perfectly, but then we discovered that the transport table overrides
> > sender-dependent transport - exactly as documented.
>
pendent transport rules. We periodically creates
> the sender_dependent_default_transport_maps, which appeared to work
> perfectly, but then we discovered that the transport table overrides
> sender-dependent transport - exactly as documented.
>
> We have a requirement for sender-dep
s the
sender_dependent_default_transport_maps, which appeared to work
perfectly, but then we discovered that the transport table overrides
sender-dependent transport - exactly as documented.
We have a requirement for sender-dependent transport rules that override
everything else. I thought of setti
> These are not "keywords", they are transport names. Transports are
> defined in master.cf.
Ahh, so the names are conventional, configurable. Flexible
configurability is a theme with Postfix.
> The "smtp" transport is for other people's domains, the "relay"
> transport is for your domains that a
On Mon, Nov 29, 2010 at 03:07:43PM -0500, Stirling, Scott wrote:
> > > Thank you. With yours and Victor's input it sounds like I can do the
> > > first relay with the existing Postfix processes, configuring a
> > > sender_dependent relay to secondary instances of Postfix to handle
> > > candidates
> > Thank you. With yours and Victor's input it sounds like I can do the
> > first relay with the existing Postfix processes, configuring a
> > sender_dependent relay to secondary instances of Postfix to handle
> > candidates for custom routing from this Sender.
> >
> > Then in the secondary Postfi
On Mon, Nov 29, 2010 at 02:51:53PM -0500, Stirling, Scott wrote:
> Thank you. With yours and Victor's input it sounds like I can do the
> first relay with the existing Postfix processes, configuring a
> sender_dependent relay to secondary instances of Postfix to handle
> candidates for custom rout
> >>> What I have not found and am for which I am requesting help, if
> >>> anyone has a pointer or experience in this area, is the ability
> >>> to combine the sender_dependent configuration with a recipient
> >>> condition. Is there a straightforward way to configure this?
> >>> Or do I need to s
On Mon, Nov 29, 2010 at 01:22:31PM -0500, Stirling, Scott wrote:
> > This requires a second internal delivery hop.
> >
> > The first to separate out the recipients or senders that are candidates
> > for bypassing Postini into a separate queue, and the second to route
> > appropriate mail from that
Le 29/11/2010 19:22, Stirling, Scott a écrit :
What I have not found and am for which I am requesting help, if
anyone has a pointer or experience in this area, is the ability
to combine the sender_dependent configuration with a recipient
condition. Is there a straightforward way to configure this
> > What I have not found and am for which I am requesting help, if
> > anyone has a pointer or experience in this area, is the ability
> > to combine the sender_dependent configuration with a recipient
> > condition. Is there a straightforward way to configure this?
> > Or do I need to script a c
On Mon, Nov 29, 2010 at 11:40:13AM -0500, Stirling, Scott wrote:
> What I have not found and am for which I am requesting help, if anyone
> has a pointer or experience in this area, is the ability to combine the
> sender_dependent configuration with a recipient condition. Is there a
> straightforw
t archives and found the
sender_dependent_default_transport_maps option. I see how this could be
used to alter the relay based on the Sender. OK.
What I have not found and am for which I am requesting help, if anyone
has a pointer or experience in this area, is the ability to combine the
sender
I have set up sender dependent transport_maps different clients to use
different outgoing ips
>From the document at
http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
The transport_maps overrides sender_dependent_default_transport_maps
What I need to do
74 matches
Mail list logo
