[pfx] Re: transport_maps : fatal: garbage after "]" in server description...

[Ralf Hildebrandt via Postfix-users]

> i am running Postfix 3.4.14 and try to set up mailrouting to multiple
> smtp hosts.
>  transport_maps = hash:/etc/postfix/mailertable
> 
> example.com  smtp:[mx1.foobar.com],smtp:[mx2.foobar.com]
> 
> However i get:
>  fatal: garbage after "]" in server description:
> [mx1.foobar.com],smtp:[mx2.foobar.com]
> 
> Whats the correct syntax? I cant find a hint in the docs :-/

example.com   smtp:[mx1.foobar.com],[mx2.foobar.com]

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] transport_maps : fatal: garbage after "]" in server description...

[Ml Ml via Postfix-users]

Hello List,

i am running Postfix 3.4.14 and try to set up mailrouting to multiple
smtp hosts.
 transport_maps = hash:/etc/postfix/mailertable

example.com  smtp:[mx1.foobar.com],smtp:[mx2.foobar.com]

However i get:
 fatal: garbage after "]" in server description:
[mx1.foobar.com],smtp:[mx2.foobar.com]

Whats the correct syntax? I cant find a hint in the docs :-/

Thanks,
Michael
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: transport_maps with address extension (user+ext@domain)

[Jan-Martin Raemer]

Hi,

On Thu, May 19, 2022 at 04:38:33PM +0200, Bastian Blank wrote:
> Maybe try to set "recipient_delimiter"?  Without delimiter, none will be
> used.

thanks, that was the problem.

Best regards,
Jan-Martin

-- 
Dr. Jan-Martin Rämer
Systemtechnik
Zentrum für Hochschul-IT Rheinland-Pfalz
Moselweißer Straße 4, 56073 Koblenz
Telefon +49(0)261 9528-906
rae...@zit-rlp.de


smime.p7s
Description: S/MIME cryptographic signature

Re: transport_maps with address extension (user+ext@domain)

[Bastian Blank]

On Thu, May 19, 2022 at 01:06:09PM +0200, Jan-Martin Raemer wrote:
> Config:
> main.cf:

Maybe try to set "recipient_delimiter"?  Without delimiter, none will be
used.

Bastian

-- 
We have phasers, I vote we blast 'em!
-- Bailey, "The Corbomite Maneuver", stardate 1514.2

Re: transport_maps with address extension (user+ext@domain)

[Jan-Martin Raemer]

Hi,

On Thu, May 19, 2022 at 08:32:34AM -0400, Wietse Venema wrote:
> Wietse Venema:
> > Jan-Martin Raemer:
> > > As I'm using a normal hash table, I assumed that user+$anything@domain
> > > would match user@domain (unless there is a specific entry for
> > > user+$anything@domain). Did I miss some option or mis-read the manual?
> > 
> > Yes, you failed to report how to reproduce the problem.
> 
> Scrap that :-)

> there is no way that user+ext2@example can't match user@example.
> People would have noticed that 25 years ago.

I thought so, therefore I assume that there is some error on my part.

> postmap -s name-of-table
user+ext@domain.example smtp:[nondefault-relay.domain]:25
user@domain.example smtp:[nondefault-relay.domain]:25

I tested with on host test-sender (using the test server as relayhost;
postfix on test server restarted after setting the config/transport map):
echo 'test' | mail -s'test' user+ext@domain;echo 'test' | mail -s'test' 
user+test@domain

From the log:
May 19 15:30:15 vmdeploy-test-01 postfix/smtp[241007]: C46EBED8: 
to=, relay=none, delay=0.01, delays=0.01/0/0/0, 
dsn=4.4.1, status=deferred (connect to 
nondefault-relay.domain[2001:db8::1000]:25: Permission denied)
May 19 15:30:15 vmdeploy-test-01 postfix/error[241013]: CB1F3EDA: 
to=, relay=none, delay=0.01, delays=0/0/0/0, 
dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 
default-relay.domain[2001:db8::1]:25: Permission denied)
i.e. only the explicitly defined user works.

I also tried (only user+test) with 'trivial-rewrite -v' in master.cf:
May 19 15:31:26 vmdeploy-test-01 postfix/trivial-rewrite[241345]: maps_find: 
transport_maps: user+test@domain.example: not found
May 19 15:31:26 vmdeploy-test-01 postfix/trivial-rewrite[241345]: maps_find: 
transport_maps: domain.example: not found
May 19 15:31:26 vmdeploy-test-01 postfix/trivial-rewrite[241345]: maps_find: 
transport_maps: .example: not found
This looks as if a lookup of user@domain.example is not even tried.

Attachments:
- the config (from a new test VM, net removed from mynetworks;
  *_host_lookup added as I put the dummy relays in /etc/hosts))
- the full log (only host addresses replaced)

I also tried with the debian packages from buster and stretch, in case
there is something broken with their build.

Thanks for your help so far, I'm really out of ideas what might be
wrong...

Best regards,
Jan-Martin

-- 
Dr. Jan-Martin Rämer
Systemtechnik
Zentrum für Hochschul-IT Rheinland-Pfalz
Moselweißer Straße 4, 56073 Koblenz
Telefon +49(0)261 9528-906
rae...@zit-rlp.de
queue_directory = /var/spool/postfix


 
command_directory = /usr/sbin   


 
myorigin = $mydomain


 
myhostname = test.relay
mydomain = relay


  
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 [2001:db8::/64] 
[2a03:63c0:1001:a801::/64]
relay_domains = 


 
relayhost =  default-relay.domain   


 
smtpd_relay_restrictions = permit_mynetworks, reject


   

Re: transport_maps with address extension (user+ext@domain)

[Viktor Dukhovni]

On Thu, May 19, 2022 at 01:06:09PM +0200, Jan-Martin Raemer wrote:

> /etc/postfix/transport:
> user@domain smtp:[nondefault-relay.domain]:25
> user+ext@domain smtp:[nondefault-relay.domain]:25

Unsolicited advice, avoid per-user transport mappings, instead use
virtual(5) rewriting to map special users to special domains.  Route
these domains to appropriate relays.  This keeps the transport table
small and simple.  If the receiving relay needs to see the original
address, a suitable reverse rewrite can be added via smtp_generic_maps.

-- 
Viktor.

Re: transport_maps with address extension (user+ext@domain)

[Wietse Venema]

Wietse Venema:
> Jan-Martin Raemer:
> > As I'm using a normal hash table, I assumed that user+$anything@domain
> > would match user@domain (unless there is a specific entry for
> > user+$anything@domain). Did I miss some option or mis-read the manual?
> 
> Yes, you failed to report how to reproduce the problem.

Scrap that :-)

You may want to dump the table with

postmap -s name-of-table

and repeat your expeciments after "postfix reload".

The search order is

complete addreess 
address without extension

Thus, given a map with

user+ext1@example   result1
user@exampleresult3

there is no way that user+ext2@example can't match user@example.
People would have noticed that 25 years ago.

Wietse

Re: transport_maps with address extension (user+ext@domain)

[Wietse Venema]

Jan-Martin Raemer:
> As I'm using a normal hash table, I assumed that user+$anything@domain
> would match user@domain (unless there is a specific entry for
> user+$anything@domain). Did I miss some option or mis-read the manual?

Yes, you failed to report how to reproduce the problem.

- With postmap (postmap does not know when or how something is used
  as an email address)

- with Postfix daemons (these know when and how something is used
  as an email address).

Wietse

transport_maps with address extension (user+ext@domain)

[Jan-Martin Raemer]

Hi,

I'm trying to route mail to a non-default relay by recepient, i.e. mail
should be relayed via default-relay.domain for all recepients except
user@domain, which should be routet via nondefault-relay.domain. This
works for user@domain and user+ext@domain (c.f. config below), but not
for user+other_ext@domain. man 5 transport claims

TABLE SEARCH ORDER
With  lookups  from  indexed files such as DB or DBM, or from networked
tables such as NIS, LDAP or SQL, patterns are tried  in the  order  as
listed below:
user+extension@domain transport:nexthop
[...]
user@domain transport:nexthop
[...]

As I'm using a normal hash table, I assumed that user+$anything@domain
would match user@domain (unless there is a specific entry for
user+$anything@domain). Did I miss some option or mis-read the manual?

Config:
main.cf:
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
myorigin = $mydomain
myhostname = test.domain
mydomain = domain
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 [2001:db8::/64]
relay_domains =
relayhost =  default-relay.domain
smtpd_relay_restrictions = permit_mynetworks, reject
transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport:
user@domain smtp:[nondefault-relay.domain]:25
user+ext@domain smtp:[nondefault-relay.domain]:25

Test results:
mail to user@domain -> relay via nondefault-relay.domain
mail to user+ext@domain -> relay via nondefault-relay.domain
mail to user+other_ext@domain -> relay via default-relay.domain

Version: 3.5.6 (package from Debian bullseye)

Best regards,
Jan-Martin

-- 
Dr. Jan-Martin Rämer
Systemtechnik
Zentrum für Hochschul-IT Rheinland-Pfalz
Moselweißer Straße 4, 56073 Koblenz
Telefon +49(0)261 9528-906
rae...@zit-rlp.de


smime.p7s
Description: S/MIME cryptographic signature

Re: randmap getting precedence in transport_maps?

[Wietse Venema]

Nicolas JEAN:

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> Em 25/02/2022 11:39, Wietse Venema escreveu:
> > Nicolas JEAN:
> >> Tested: adding above randmap also 'supersedes' a local_transport_map
> >> containing the domain-matching "my.domain virtual:"...
> >>
> >> I don't understand how "my.domain :" and "my.domain virtual:" can have
> >> different results, isn't it only the left part that matches incoming
> >> emails' addresses? How would having ':' or 'virtual:' on the right side
> >> change the matching?
> > I suspect that you have garbage in your maps, such  as non-ASCII
> > whitespace. Examine with
> >
> >  LANG=C grep '[^[:print:]]' /etc/postfix/local_transport_map | od -cb
> >
> >  postmap -s hash:/etc/postfix/local_transport_map | \
> > LANG=C grep '[^[:print:]]' | od -cb
> >
> > Have fun.
> 
> Thanks for the tip. Spotting irregular characters isn't my strength, 
> couldn't figure out the issue.
> 
> I moved to using the randmap in sender_dependent_default_transport_maps, 
> instead of transport_map.
> Which by definition can't collide with local domains (mydestination, 
> virtual_mailbox_domains).
> 
> This also removes the need to have a "local_transport_map", which 
> duplicated the info from virtual_mailbox_domains.

Congratulations. 

Yes, sender_dependent_default_transport_maps=randmap:{...}
will eliminate routing mistakes for local domains.

I was thinking of adding default_transport_maps, i.e. lookup by
destination instead of sender, for destinations that use the default
transport.

This idea generalizes to other address classes, with
{default,relay,local,virtual_mailbox}_transport_maps. I find it
hard to come up with compelling use cases other than those that
involve randmap (i.e. load balancing or load migration}. But maybe
that is sufficient.

Wietse

Re: randmap getting precedence in transport_maps?

[Nicolas JEAN]

Em 25/02/2022 11:39, Wietse Venema escreveu:

Nicolas JEAN:

Tested: adding above randmap also 'supersedes' a local_transport_map
containing the domain-matching "my.domain virtual:"...

I don't understand how "my.domain :" and "my.domain virtual:" can have
different results, isn't it only the left part that matches incoming
emails' addresses? How would having ':' or 'virtual:' on the right side
change the matching?

I suspect that you have garbage in your maps, such  as non-ASCII
whitespace. Examine with

 LANG=C grep '[^[:print:]]' /etc/postfix/local_transport_map | od -cb

 postmap -s hash:/etc/postfix/local_transport_map | \
LANG=C grep '[^[:print:]]' | od -cb

Have fun.


Thanks for the tip. Spotting irregular characters isn't my strength, 
couldn't figure out the issue.


I moved to using the randmap in sender_dependent_default_transport_maps, 
instead of transport_map.
Which by definition can't collide with local domains (mydestination, 
virtual_mailbox_domains).


This also removes the need to have a "local_transport_map", which 
duplicated the info from virtual_mailbox_domains.


Nico



OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: randmap getting precedence in transport_maps?

[Wietse Venema]

Nicolas JEAN:
-- Start of PGP signed section.
> Em 24/02/2022 17:14, Wietse Venema escreveu:
> > Nicolas JEAN:
> >> Having "my.domain :" or "my.domain lmtp:unix:private/dovecot-lmtp"
> >> doesn't modify default behaviour (set by virtual_transport =
> >> lmtp:unix:private/dovecot-lmtp), and yields such a log line:
> >>   to=, relay=my.domain[private/dovecot-lmtp] ...
> >> dsn=2.0.0, status=sent
> > Note that you would get the exact same email delivery result with
> > a map that does not match your domain.
> >
> > How would you tell the difference between a map that returns ":"
> > for your domain and a map that does not match your domain?
> >
> > Not by looking at the mailog file.
> 
> Understood, good point.
> 
> >> But having "my.domain virtual:"; for instance, changes the log line to:
> >>   to=, relay=virtual ... dsn=2.0.0, status=sent
> >>
> >> So the incoming email's domain /is/ matched against local_transport_map
> >> and the transport described there is used.
> > This is a DIFFERENT map that matches your domain.
> >> transport_maps = hash:/etc/postfix/local_transport_map
> >> randmap:{smtp:[relay1.com]:587, smtp:[relay2.com]:587}
> 
> Tested: adding above randmap also 'supersedes' a local_transport_map 
> containing the domain-matching "my.domain virtual:"...
> 
> I don't understand how "my.domain :" and "my.domain virtual:" can have 
> different results, isn't it only the left part that matches incoming 
> emails' addresses? How would having ':' or 'virtual:' on the right side 
> change the matching?

I suspect that you have garbage in your maps, such  as non-ASCII
whitespace. Examine with

LANG=C grep '[^[:print:]]' /etc/postfix/local_transport_map | od -cb

postmap -s hash:/etc/postfix/local_transport_map | \
LANG=C grep '[^[:print:]]' | od -cb

Have fun.

Wietse

Re: randmap getting precedence in transport_maps?

[Nicolas JEAN]

Em 24/02/2022 17:14, Wietse Venema escreveu:

Nicolas JEAN:

Having "my.domain :" or "my.domain lmtp:unix:private/dovecot-lmtp"
doesn't modify default behaviour (set by virtual_transport =
lmtp:unix:private/dovecot-lmtp), and yields such a log line:
  to=, relay=my.domain[private/dovecot-lmtp] ...
dsn=2.0.0, status=sent

Note that you would get the exact same email delivery result with
a map that does not match your domain.

How would you tell the difference between a map that returns ":"
for your domain and a map that does not match your domain?

Not by looking at the mailog file.


Understood, good point.


But having "my.domain virtual:"; for instance, changes the log line to:
  to=, relay=virtual ... dsn=2.0.0, status=sent

So the incoming email's domain /is/ matched against local_transport_map
and the transport described there is used.

This is a DIFFERENT map that matches your domain.

transport_maps = hash:/etc/postfix/local_transport_map
randmap:{smtp:[relay1.com]:587, smtp:[relay2.com]:587}


Tested: adding above randmap also 'supersedes' a local_transport_map 
containing the domain-matching "my.domain virtual:"...


I don't understand how "my.domain :" and "my.domain virtual:" can have 
different results, isn't it only the left part that matches incoming 
emails' addresses? How would having ':' or 'virtual:' on the right side 
change the matching?




OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: randmap getting precedence in transport_maps?

[Wietse Venema]

Nicolas JEAN:
> ### Tests without randmap ###
> 
> transport_maps = hash:/etc/postfix/local_transport_map
> 
> Having "my.domain :" or "my.domain lmtp:unix:private/dovecot-lmtp" 
> doesn't modify default behaviour (set by virtual_transport = 
> lmtp:unix:private/dovecot-lmtp), and yields such a log line:

>  to=, relay=my.domain[private/dovecot-lmtp] ... 
> dsn=2.0.0, status=sent

Note that you would get the exact same email delivery result with
a map that does not match your domain.

How would you tell the difference between a map that returns ":"
for your domain and a map that does not match your domain?

Not by looking at the mailog file.

> But having "my.domain virtual:"; for instance, changes the log line to:
> 
>  to=, relay=virtual ... dsn=2.0.0, status=sent
> 
> So the incoming email's domain /is/ matched against local_transport_map 
> and the transport described there is used.

This is a DIFFERENT map that matches your domain.

> ### Test with randmap ###
> 
> transport_maps = hash:/etc/postfix/local_transport_map 
> randmap:{smtp:[relay1.com]:587, smtp:[relay2.com]:587}
> 
> Adding randmap after local_transport_map (unchanged "my.domain :" line) 

We know based on the above test that THIS UNCHANGED MAP either
returns ":" for your domain or it does not match your domain.

And now we know the difference:

> results in all incoming email being relayed to one of the randmap relays.

Conclusion: the map does not match your local domain, and therefore
Postfix queries the next map, which is the randmap.

Wietse

Re: randmap getting precedence in transport_maps?

[Nicolas JEAN]

Em 24/02/2022 14:03, Wietse Venema escreveu:

Nicolas JEAN:

Feb 24 15:18:38 my.domain postfix/smtp[4628]: B08949E76C:
to=, relay=relay2.com[2.2.2.2]:587, delay=0.76,
delays=0.04/0.01/0.38/0.33, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
as 29A7484FC6)

If I'm correct, thecontact@my.domain  wasn't modified by any alias (as
shown by 'to=<'). But this final email address still doesn't match
against the "my.domain :" entry in /etc/postfix/local_transport_map, for
some reason.

Well there is your problem.
Instead of arguing what should be in the file, look at what is
actually in there.

 postmap -s /etc/postfix/local_transport_map


The database file seems correct also when looking with postmap -s.
I ran some more tests.

### Tests without randmap ###

transport_maps = hash:/etc/postfix/local_transport_map

Having "my.domain :" or "my.domain lmtp:unix:private/dovecot-lmtp" 
doesn't modify default behaviour (set by virtual_transport = 
lmtp:unix:private/dovecot-lmtp), and yields such a log line:


    to=, relay=my.domain[private/dovecot-lmtp] ... 
dsn=2.0.0, status=sent


But having "my.domain virtual:"; for instance, changes the log line to:

    to=, relay=virtual ... dsn=2.0.0, status=sent

So the incoming email's domain /is/ matched against local_transport_map 
and the transport described there is used.


### Test with randmap ###

transport_maps = hash:/etc/postfix/local_transport_map 
randmap:{smtp:[relay1.com]:587, smtp:[relay2.com]:587}


Adding randmap after local_transport_map (unchanged "my.domain :" line) 
results in all incoming email being relayed to one of the randmap relays.


Nico



OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: randmap getting precedence in transport_maps?

[Wietse Venema]

Nicolas JEAN:
> Feb 24 15:18:38 my.domain postfix/smtp[4628]: B08949E76C: 
> to=, relay=relay2.com[2.2.2.2]:587, delay=0.76, 
> delays=0.04/0.01/0.38/0.33, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued 
> as 29A7484FC6)
> 
> If I'm correct, the contact@my.domain wasn't modified by any alias (as 
> shown by 'to=<'). But this final email address still doesn't match 
> against the "my.domain :" entry in /etc/postfix/local_transport_map, for 
> some reason.

Well there is your problem.

> And so the email gets relayed to relay2.com from the randmap.
> 
> I'm running short of ideas as to what I'm doing wrong, so any idea is 
> welcome.

Instead of arguing what should be in the file, look at what is
actually in there.

postmap -s /etc/postfix/local_transport_map

If the above is not conclusive, look for "invisible" text with:

postmap -s /etc/postfix/local_transport_map | od -cb

Wietse

Re: randmap getting precedence in transport_maps?

[Nicolas JEAN]

Hi Wietse,
Thanks for your quick answer!

Wietse Venema:

/etc/postfix/local_transport_map

 my.domain ?? :
 .my.domain ? :

(where myhostname = myorigin = virtual_mailbox_domains = my.domain)

Did notice any warnings from Postfix with "do not list domain XXX
in both YYY and ZZZ"?


Not with this configuration. Some time ago I did, but the "do not list" 
warning message was about not including /mydestination/ in 
/virtual_mailbox_domains/ if I remember correctly-- very useful by the way.



   * How do I make sure that incoming mail for locally-managed domains is
 delivered locally, not relayed?

With ":" lookup results in a transport map before the randmap.

The transport map must return ":" for the recipient domain AFTER
canonical and virtual alias mapping. As documented, canonical and
virtual alias mapping happen before transport map lookup.

Have you verified that the recipient domain after canonical and
virtual alias mapping matches the transport map? Does the lookup
return ":"? Postfix logs the recipient domain as "to-".


In this case there should be no canonical or virtual alias for the 
recipient email address. It's a plain mailbox defined in the 
virtual_mailbox_maps file as "contact@my.domain my.domain/contact/".


Here is the complete log output of the smtp session:

Feb 24 15:18:37 my.domain postfix/smtpd[4622]: B08949E76C: 
client=unknown[7.7.7.7]
Feb 24 15:18:37 my.domain postfix/cleanup[4627]: B08949E76C: 
message-id=<9bc3be89-b254-08b4-c00f-3afc30101...@external.com>
Feb 24 15:18:37 my.domain postfix/qmgr[4621]: B08949E76C: 
from=, size=2764, nrcpt=1 (queue active)
Feb 24 15:18:37 my.domain postfix/smtpd[4622]: disconnect from 
unknown[7.7.7.7] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
Feb 24 15:18:38 my.domain postfix/smtp[4628]: Untrusted TLS connection 
established to relay2.com[2.2.2.2]:587: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 
server-signature RSA-PSS (2048 bits) server-digest SHA256
Feb 24 15:18:38 my.domain postfix/smtp[4628]: B08949E76C: 
to=, relay=relay2.com[2.2.2.2]:587, delay=0.76, 
delays=0.04/0.01/0.38/0.33, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued 
as 29A7484FC6)

Feb 24 15:18:38 my.domain postfix/qmgr[4621]: B08949E76C: removed

If I'm correct, the contact@my.domain wasn't modified by any alias (as 
shown by 'to=<'). But this final email address still doesn't match 
against the "my.domain :" entry in /etc/postfix/local_transport_map, for 
some reason.

And so the email gets relayed to relay2.com from the randmap.

I'm running short of ideas as to what I'm doing wrong, so any idea is 
welcome.


Nico



OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: randmap getting precedence in transport_maps?

[Wietse Venema]

Nicolas JEAN:

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> Hi everyone,
> 
> I'm trying to implement load balancing thanks to /transport_maps/ and 
> /randmap/ as described in postfix 3.0 release notes[1].
> 
> /etc/postfix/local_transport_map
> 
> my.domain ?? :
> .my.domain ? :
>
> (where myhostname = myorigin = virtual_mailbox_domains = my.domain)

Did notice any warnings from Postfix with "do not list domain XXX
in both YYY and ZZZ"?

> *Questions*:
> 
>   * How do I make sure that incoming mail for locally-managed domains is
> delivered locally, not relayed?

With ":" lookup results in a transport map before the randmap.

The transport map must return ":" for the recipient domain AFTER
canonical and virtual alias mapping. As documented, canonical and
virtual alias mapping happen before transport map lookup.

Have you verified that the recipient domain after canonical and
virtual alias mapping matches the transport map? Does the lookup
return ":"? Postfix logs the recipient domain as "to-".

Wietse

randmap getting precedence in transport_maps?

[Nicolas JEAN]

Hi everyone,

I'm trying to implement load balancing thanks to /transport_maps/ and 
/randmap/ as described in postfix 3.0 release notes[1].


/etc/postfix/local_transport_map

   my.domain    :
   .my.domain   :

(where myhostname = myorigin = virtual_mailbox_domains = my.domain)

Then I have in main.cf: transport_maps = 
hash:/etc/postfix/local_transport_map randmap:{smtp:[relay1.com]:587 
smtp:[relay2.com]:587}


(with /etc/postfix/local_transport_map being postmap'ed, and postfix 
reloaded)


*What I expected*: incoming mail for my.domain to be delivered locally 
(virtual), outgoing mail to be balance-relayed through relay1 and relay2.


*What I get*: incoming and outgoing mail are being balance-relayed 
through relay1 and relay2.


*Questions*:

 * How do I make sure that incoming mail for locally-managed domains is
   delivered locally, not relayed?
 * Could it have something to do with local delivery being 'virtual'
   and not 'local'?

Thank you very much in advance,
Nico

P.S.: I'm running postfix 3.5.6. Also, I believe this question[2] is 
showing the same issue.


[1] 
http://postfix.cs.utah.edu/source/official/postfix-3.0.0-RC1.RELEASE_NOTES


[2] 
https://stackoverflow.com/questions/62561912/how-to-configure-postfix-with-transport-maps-and-randmap




OpenPGP_0x23459069119D37B6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: About "transport_maps" : when this paraméter is set smtp does not deliver mail localy

[Claude]

I solved my problem.

We are using the Postfix "directory routing" functionality  .

The problem was on the Ldap request filter.  I adjusted it.


So the discussion thread on this problem can be closed.


Bests Regards.

--

   Claude Chéret

Le 07/10/2021 à 19:36, Claude a écrit :

Tank you for the clarification.


Here I give you more informations about the configuration.

The smtp server :

- act as a local delivery server for the local domain (we are using 
virtual mailbox owned by vmail:vmail account in /mnt/virtual),


- act as a relay server for some other domains.

Maildrop is configured to run under vmail account in the master.cf file.

When I unconfigure transport_maps,  maildrop run as vmail and it can 
write the message in the user's mailbox .


When I configure the transport_maps, maildrop run as root  for the 
local delyvery, so it can't write into the user's mailbox and delivery 
fail.



Le 07/10/2021 à 15:31, Matus UHLAR - fantomas a écrit :

On 07.10.21 14:26, Claude wrote:
Subject: Re: About "transport_maps" : when this paraméter is set 
smtp does

not deliver mail localy

On the "transport" man page I can see this information:

...
In  order  to  deliver internal mail directly, while using a mail relay
for all other mail, specify a null entry for internal destinations  (do
not change the delivery transport or the nexthop information) and spec-
ify a wildcard for all other destinations.


deliver directly does not mean locally.

deliver directly means deliver to remote server that is MX host, 
instead of

delivering via relay_host or other host(t) in transport_maps.

in order to deliver mail locally, the destination domain must be 
treated as

local domain. You can't do that via transport_maps.

Re: About "transport_maps" : when this paraméter is set smtp does not deliver mail localy

[Claude]

Tank you for the clarification.


Here I give you more informations about the configuration.

The smtp server :

- act as a local delivery server for the local domain (we are using 
virtual mailbox owned by vmail:vmail account in /mnt/virtual),


- act as a relay server for some other domains.

Maildrop is configured to run under vmail account in the master.cf file.

When I unconfigure transport_maps,  maildrop run as vmail and it can 
write the message in the user's mailbox .


When I configure the transport_maps, maildrop run as root  for the local 
delyvery, so it can't write into the user's mailbox and delivery fail.



Le 07/10/2021 à 15:31, Matus UHLAR - fantomas a écrit :

On 07.10.21 14:26, Claude wrote:
Subject: Re: About "transport_maps" : when this paraméter is set smtp 
does

not deliver mail localy

On the "transport" man page I can see this information:

...
In  order  to  deliver internal mail directly, while using a mail relay
for all other mail, specify a null entry for internal destinations  (do
not change the delivery transport or the nexthop information) and spec-
ify a wildcard for all other destinations.


deliver directly does not mean locally.

deliver directly means deliver to remote server that is MX host, 
instead of

delivering via relay_host or other host(t) in transport_maps.

in order to deliver mail locally, the destination domain must be 
treated as

local domain. You can't do that via transport_maps.

Re: About "transport_maps" : when this paraméter is set smtp does not deliver mail localy

[Matus UHLAR - fantomas]

On 07.10.21 14:26, Claude wrote:

Subject: Re: About "transport_maps" : when this paraméter is set smtp does
not deliver mail localy

On the "transport" man page I can see this information:

...
In  order  to  deliver internal mail directly, while using a mail relay
for all other mail, specify a null entry for internal destinations  (do
not change the delivery transport or the nexthop information) and spec-
ify a wildcard for all other destinations.


deliver directly does not mean locally.

deliver directly means deliver to remote server that is MX host, instead of
delivering via relay_host or other host(t) in transport_maps.

in order to deliver mail locally, the destination domain must be treated as
local domain. You can't do that via transport_maps.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Where do you want to go to die?" [Microsoft]

Re: About "transport_maps" : when this paraméter is set smtp does not deliver mail localy

[Bill Cole]

On 2021-10-07 at 08:26:41 UTC-0400 (Thu, 7 Oct 2021 14:26:41 +0200)
Claude 
is rumored to have said:


On the "transport" man page I can see this information:

...
In  order  to  deliver internal mail directly, while using a mail 
relay
for all other mail, specify a null entry for internal destinations  
(do
not change the delivery transport or the nexthop information) and 
spec-

ify a wildcard for all other destinations.

*my.domain :*
*.my.domain :*
** smtp :outbound-relay.my.domain 
*...



Do you mean the correct synthax is:

*my.domain*
*.my.domain*
** smtp :outbound-relay.my.domain*


Your attempt to markup that text is a hindrance to clear communication. 
Using actual *plain* text is essential when communicating plain text 
config details. I have no idea what, if any, difference between those 
two you are attempting to ask about.



Your original message said:

b) I try with a custom 'tranport_maps" parameter like this:

 * transport_map = hash:/etc/postfix/transport

 with the "transport" file like this:

 my-domain.fr  :
 .my-domain.fr :
 * : another-mail-server.fr


The last of the three lines has a bare ':' which definitely should not 
be there. If all lines include a bare ':' then the whole file does 
nothing. I cannot judge whether that alone would fix your problem, as it 
seems that you have not settled on a consistent replacement of your 
domain(s?)  with other names and have only included a small subset of 
your configuration rather than the output of 'postconf -nf' and 
'postconf -Mf' which would provide all of the relevant details.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: About "transport_maps" : when this paraméter is set smtp does not deliver mail localy

[Claude]

On the "transport" man page I can see this information:

...
In  order  to  deliver internal mail directly, while using a mail relay
for all other mail, specify a null entry for internal destinations  (do
not change the delivery transport or the nexthop information) and spec-
ify a wildcard for all other destinations.

*my.domain :*
*.my.domain :*
** smtp :outbound-relay.my.domain *...


Do you mean the correct synthax is:

*my.domain*
*.my.domain*
** smtp :outbound-relay.my.domain*

Rgds.
Claude Chéret


Le 06/10/2021 à 19:44, Bill Cole a écrit :

On 2021-10-06 at 13:24:15 UTC-0400 (Wed, 6 Oct 2021 13:24:15 -0400)
Viktor Dukhovni 
is rumored to have said:

On 6 Oct 2021, at 1:07 pm, Bill Cole 
 wrote:


That is surprising because the format is all wrong. Those 
freestanding ':' should make everything there useless.  See the man 
page for transport(5). A hash map has exactly 2 tokens per line, 
whitespace delimited, with the second being of the format 
'transport:nexthop' where 'transport' has an entry in master.cf.


Actually, no.  The free-standing ":" is a documented option needed to
avoid falling into the wildcard "*" case.


Clarifying:

All three lines do nothing because every line has a freestanding ':' 
making the whole table useless.

Re: About "transport_maps" : when this paraméter is set smtp does not deliver mail localy

[Bill Cole]

On 2021-10-06 at 13:24:15 UTC-0400 (Wed, 6 Oct 2021 13:24:15 -0400)
Viktor Dukhovni 
is rumored to have said:

On 6 Oct 2021, at 1:07 pm, Bill Cole 
 wrote:


That is surprising because the format is all wrong. Those 
freestanding ':' should make everything there useless.  See the man 
page for transport(5). A hash map has exactly 2 tokens per line, 
whitespace delimited, with the second being of the format 
'transport:nexthop' where 'transport' has an entry in master.cf.


Actually, no.  The free-standing ":" is a documented option needed to
avoid falling into the wildcard "*" case.


Clarifying:

All three lines do nothing because every line has a freestanding ':' 
making the whole table useless.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: About "transport_maps" : when this paraméter is set smtp does not deliver mail localy

[Viktor Dukhovni]

> On 6 Oct 2021, at 1:07 pm, Bill Cole 
>  wrote:
> 
> That is surprising because the format is all wrong. Those freestanding ':' 
> should make everything there useless.  See the man page for transport(5). A 
> hash map has exactly 2 tokens per line, whitespace delimited, with the second 
> being of the format 'transport:nexthop' where 'transport' has an entry in 
> master.cf.

Actually, no.  The free-standing ":" is a documented option needed to
avoid falling into the wildcard "*" case.

-- 
Viktor.

Re: About "transport_maps" : when this paraméter is set smtp does not deliver mail localy

[Bill Cole]

On 2021-10-06 at 11:48:45 UTC-0400 (Wed, 6 Oct 2021 17:48:45 +0200)
Claude 
is rumored to have said:


The problem:

On the postfix-2.10.X mail server , the server does not deliver localy 
the mail for the localy hosted recipient  accounts but try to resend 
the mail to the "mailHost" (taken from Ldap).


So postfix-2.10.x detect a loop and drop the message.

The message in aillog looks like: postfix/bounce: bounce_append_proto: 
. act=failed  why=mail  for my-server.mydomain.fr loops 
back to myself


If you want to deliver mail to my-server.mydomain.fr recipients locally, 
my-server.mydomain.fr MUST be in either mydestination ("local" domains 
with system users,) virtual_alias_domains, or virtual_mailbox_domains. 
See Postfix's ADDRESS_CLASS_README for more information.



What I tested:

a) I have removed the "transport_maps" parameter fom the "main.cf" 
configuration file , and restart the postfix server:


 * so the mail delivery for the local account works fine

b) I try with a custom 'tranport_maps" parameter like this:

 * transport_map = hash:/etc/postfix/transport

   with the "transport" file like this:

   my-domain.fr  :
   .my-domain.fr :
   * : another-mail-server.fr

   then "postmap transport" to generate the .db file.

 * result : the mail delivery for the local account works fine


That is surprising because the format is all wrong. Those freestanding 
':' should make everything there useless.  See the man page for 
transport(5). A hash map has exactly 2 tokens per line, whitespace 
delimited, with the second being of the format 'transport:nexthop' where 
'transport' has an entry in master.cf.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

About "transport_maps" : when this paraméter is set smtp does not deliver mail localy

[Claude]

Hi,

I need some help to solve a configuration issue on postfix-2.10.x.


The context:

I am migration from postfix-2.9.x to postfix-2.10.x while preserving 
configuration files.


On our configuration, we are using the "transport_maps" parameter to get 
one information in our Ldap server: the targeted "mailHost" for the 
recipient of  the mail.


The mail server is delivering mail localy if the recipient account is 
hosted localy , but forward the mail to another mail server if not.


On the postfix-2.9.x all work fine


The problem:

On the postfix-2.10.X mail server , the server does not deliver localy 
the mail for the localy hosted recipient  accounts but try to resend the 
mail to the "mailHost" (taken from Ldap).


So postfix-2.10.x detect a loop and drop the message.

The message in aillog looks like: postfix/bounce: bounce_append_proto: 
. act=failed  why=mail  for my-server.mydomain.fr loops back 
to myself



What I tested:

a) I have removed the "transport_maps" parameter fom the "main.cf" 
configuration file , and restart the postfix server:


 * so the mail delivery for the local account works fine

b) I try with a custom 'tranport_maps" parameter like this:

 * transport_map = hash:/etc/postfix/transport

   with the "transport" file like this:

   my-domain.fr  :
   .my-domain.fr :
   * : another-mail-server.fr

   then "postmap transport" to generate the .db file.

 * result : the mail delivery for the local account works fine

c) ) I try to add an entry on the original "transport_maps" we need on 
our configuration:


 * transport_map =
   
ldap:/etc/postfix/my-conf-file1,ldap:/etc/postfix/my-conf-file2,hash:/etc/postfix/transport

   with the "transport" file like this:

   my-domain.fr  :
   .my-domain.fr :
   * : another-mail-server.fr

   then "postmap transport" to generate the .db file.

 * result: the postfix server start but with an error and it does not
   work at all
 o and listening is closed on port 25


Do you have any advice to correct this problem ?

Bests regards.

Claude Chéret

Re: Overriding transport_maps with sender_dependent

[Matt Corallo]

On 8/12/21 14:41, Gerard E. Seibert wrote:

Have you made any attempt to get your IP 'whitelisted' with Microsoft?



Several attempts. If you know of a decent contact I can pursue it further, but even after fighting with their usual 
ticket people and getting "mitigation" turned on for the sending IP things are still insta-spam-boxed. The MailOps list 
is filled with people in similar boats, and at least a few have given up and just relay to Microsoft as well.


Matt

Re: Overriding transport_maps with sender_dependent

[Gerard E. Seibert]

On Thu, 12 Aug 2021 11:56:36 -0400, Matt Corallo stated:
>On 8/12/21 09:37, Wietse Venema wrote:
>> Matt Corallo:  
>>> I tried variations of this but never could get it to work - as far
>>> as I could tell the nexthop is fully resolved by the time we get to
>>> the smtp daemon, so there aren't any relevant settings to override
>>> or otherwise set the default on the nexthop there.  
>> 
>> In the FILTER command you specify transport AND nexthop. There is
>> nothing to be resolved BEFORE the SMTP client.  
>
>Ah, thanks. Sadly I'm not sure this solves the immediate issue either
>as it seems to override local domain delivery as well. i.e. it results
>in any of the source addresses which would need proxying to external
>domains being proxied to local domains as well.
>
>For context, this doesn't feel like a crazy setup - some users have
>external addresses they want to be able to send mail as, which we
>(obviously) need to relay via their external providers' smtp with
>authentication. For local-domain mails, there are some providers
>(*cough* Microsoft *cough*) which treat all mail from low-volume IPs
>as spam, no matter what best-practices you comply with, so we want to
>relay anything to Microsoft domains out via a third-party provider.
>
>Its currently working with a second postfix instance and a simple
>socketmap program in transport_maps to lookup if a domain's MX is
>*.outlook.com.
>
>Matt

Have you made any attempt to get your IP 'whitelisted' with Microsoft?

-- 
Gerard

Re: Overriding transport_maps with sender_dependent

[Matt Corallo]

On 8/12/21 09:37, Wietse Venema wrote:

Matt Corallo:

I tried variations of this but never could get it to work - as far as I could 
tell the nexthop is fully resolved by the
time we get to the smtp daemon, so there aren't any relevant settings to 
override or otherwise set the default on the
nexthop there.


In the FILTER command you specify transport AND nexthop. There is
nothing to be resolved BEFORE the SMTP client.


Ah, thanks. Sadly I'm not sure this solves the immediate issue either as it seems to override local domain delivery as 
well. i.e. it results in any of the source addresses which would need proxying to external domains being proxied to 
local domains as well.


For context, this doesn't feel like a crazy setup - some users have external addresses they want to be able to send mail 
as, which we (obviously) need to relay via their external providers' smtp with authentication. For local-domain mails, 
there are some providers (*cough* Microsoft *cough*) which treat all mail from low-volume IPs as spam, no matter what 
best-practices you comply with, so we want to relay anything to Microsoft domains out via a third-party provider.


Its currently working with a second postfix instance and a simple socketmap program in transport_maps to lookup if a 
domain's MX is *.outlook.com.


Matt

Re: Overriding transport_maps with sender_dependent

[Wietse Venema]

Matt Corallo:
> I tried variations of this but never could get it to work - as far as I could 
> tell the nexthop is fully resolved by the 
> time we get to the smtp daemon, so there aren't any relevant settings to 
> override or otherwise set the default on the 
> nexthop there.

In the FILTER command you specify transport AND nexthop. There is
nothing to be resolved BEFORE the SMTP client.

Wietse

> Thanks,
> Matt
> 
> On 8/11/21 17:37, Wietse Venema wrote:
> > Matt Corallo:
> >>
> >>
> >> On 8/11/21 16:52, Wietse Venema wrote:
> >>   > If the sender address can override the routing, even if the recipient
> >>   > would otherwise be delivered locally, then that would be a recipe
> >>   > for mailer loops with the potential for mail explosions. This is
> >>   > why we have sender_dependent overrides for default transports and
> >>   > relay hosts, and avoid such stability problems.
> >>
> >> Ah! Understood, indeed, the setup I've had to fall back to has some risk 
> >> of routing loops, though with some care to
> >> hopefully ensure it can't ever actually be hit. I guess the only solution 
> >> is multi-key lookups, which would be nice, but
> >> understood that its likely very nontrivial to add :).
> > 
> > Would this do the job:
> > 
> > /etc/postfix/main.cf:
> >  smtpd_sender_restrictions = hash:/etc/postfix/sender_access
> > 
> > /etc/postfix/sender_access
> >  example.com  filter smtp-example-com:relay-for-example-com
> > ...
> > 
> > /etc/postfix/master.cf:
> >  smtp-example-com   ..   ..   ..   ..   ..   .. smtp
> >  ...
> > 
> > It avoids the need for another instance. Postfix should break a
> > mailer loop that delivers to itself.
> > 
> >  Wietse
> > 
> 

Re: Overriding transport_maps with sender_dependent

[Matt Corallo]

I tried variations of this but never could get it to work - as far as I could tell the nexthop is fully resolved by the 
time we get to the smtp daemon, so there aren't any relevant settings to override or otherwise set the default on the 
nexthop there.


Thanks,
Matt

On 8/11/21 17:37, Wietse Venema wrote:

Matt Corallo:



On 8/11/21 16:52, Wietse Venema wrote:
  > If the sender address can override the routing, even if the recipient
  > would otherwise be delivered locally, then that would be a recipe
  > for mailer loops with the potential for mail explosions. This is
  > why we have sender_dependent overrides for default transports and
  > relay hosts, and avoid such stability problems.

Ah! Understood, indeed, the setup I've had to fall back to has some risk of 
routing loops, though with some care to
hopefully ensure it can't ever actually be hit. I guess the only solution is 
multi-key lookups, which would be nice, but
understood that its likely very nontrivial to add :).


Would this do the job:

/etc/postfix/main.cf:
 smtpd_sender_restrictions = hash:/etc/postfix/sender_access

/etc/postfix/sender_access
 example.com  filter smtp-example-com:relay-for-example-com
...

/etc/postfix/master.cf:
 smtp-example-com   ..   ..   ..   ..   ..   .. smtp
 ...

It avoids the need for another instance. Postfix should break a
mailer loop that delivers to itself.

 Wietse

Re: Overriding transport_maps with sender_dependent

[Wietse Venema]

Matt Corallo:
> 
> 
> On 8/11/21 16:52, Wietse Venema wrote:
>  > If the sender address can override the routing, even if the recipient
>  > would otherwise be delivered locally, then that would be a recipe
>  > for mailer loops with the potential for mail explosions. This is
>  > why we have sender_dependent overrides for default transports and
>  > relay hosts, and avoid such stability problems.
> 
> Ah! Understood, indeed, the setup I've had to fall back to has some risk of 
> routing loops, though with some care to 
> hopefully ensure it can't ever actually be hit. I guess the only solution is 
> multi-key lookups, which would be nice, but 
> understood that its likely very nontrivial to add :).

Would this do the job:

/etc/postfix/main.cf:
smtpd_sender_restrictions = hash:/etc/postfix/sender_access

/etc/postfix/sender_access
example.com  filter smtp-example-com:relay-for-example-com
...

/etc/postfix/master.cf:
smtp-example-com   ..   ..   ..   ..   ..   .. smtp
...

It avoids the need for another instance. Postfix should break a
mailer loop that delivers to itself.

Wietse

Re: Overriding transport_maps with sender_dependent

[Matt Corallo]

On 8/11/21 16:52, Wietse Venema wrote:
> If the sender address can override the routing, even if the recipient
> would otherwise be delivered locally, then that would be a recipe
> for mailer loops with the potential for mail explosions. This is
> why we have sender_dependent overrides for default transports and
> relay hosts, and avoid such stability problems.

Ah! Understood, indeed, the setup I've had to fall back to has some risk of routing loops, though with some care to 
hopefully ensure it can't ever actually be hit. I guess the only solution is multi-key lookups, which would be nice, but 
understood that its likely very nontrivial to add :).


On 8/11/21 16:49, post...@ptld.com wrote:

I might be off course, but wouldn't a milter cover those requirements?


I would love to find that it is, but its not my understanding that a milter can set the smtp nexthop without modifying 
the mail itself.


Thanks,
Matt

Re: Overriding transport_maps with sender_dependent

[Wietse Venema]

Matt Corallo:
> 
> 
> On 8/11/21 13:54, Viktor Dukhovni wrote:
> >> On 11 Aug 2021, at 11:00 am, Matt Corallo  wrote:
> >>
> >> Hmm, well I suppose consider this a feature request for 
> >> sender_dependent_relay_transport_maps or sender_dependent_transport_maps :)
> > 
> > No such feature fits into a single-key lookup design.
> > 
> > You're looking to exempt specific sender (domains) from the recipient-based
> > nexthop of specific recipient domains.  This is a multi-key transport
> > decision, and supporting this requires a radically different design.
> > 
> > So the feature request is extremely unlikely to be actionable.
> 
> Correct me if I'm wrong, but it should still be possible to have
> a sender-dependent lookup that happens before transport_maps or
> relay_transport_maps? Indeed, I understand that no multi-key lookup
> can occur, but the decision could be made first by an optional
> sender lookup, then by the recipient lookup, then the default, no?

If the sender address can override the routing, even if the recipient
would otherwise be delivered locally, then that would be a recipe
for mailer loops with the potential for mail explosions. This is
why we have sender_dependent overrides for default transports and
relay hosts, and avoid such stability problems.

Wietse

> In any case, I'll likely go with a second instance of postfix for now, but 
> its a lot of additional complexity.
> 
> Matt
> 

Re: Overriding transport_maps with sender_dependent

[postfix]

On 08-11-2021 4:41 pm, Matt Corallo wrote:

Correct me if I'm wrong, but it should still be possible to have a
sender-dependent lookup that happens before transport_maps or
relay_transport_maps? Indeed, I understand that no multi-key lookup
can occur, but the decision could be made first by an optional sender
lookup, then by the recipient lookup, then the default, no?

In any case, I'll likely go with a second instance of postfix for now,
but its a lot of additional complexity.



I might be off course, but wouldn't a milter cover those requirements?

Re: Overriding transport_maps with sender_dependent

[Matt Corallo]

On 8/11/21 13:54, Viktor Dukhovni wrote:

On 11 Aug 2021, at 11:00 am, Matt Corallo  wrote:

Hmm, well I suppose consider this a feature request for 
sender_dependent_relay_transport_maps or sender_dependent_transport_maps :)


No such feature fits into a single-key lookup design.

You're looking to exempt specific sender (domains) from the recipient-based
nexthop of specific recipient domains.  This is a multi-key transport
decision, and supporting this requires a radically different design.

So the feature request is extremely unlikely to be actionable.


Correct me if I'm wrong, but it should still be possible to have a sender-dependent lookup that happens before 
transport_maps or relay_transport_maps? Indeed, I understand that no multi-key lookup can occur, but the decision could 
be made first by an optional sender lookup, then by the recipient lookup, then the default, no?


In any case, I'll likely go with a second instance of postfix for now, but its 
a lot of additional complexity.

Matt

Re: Overriding transport_maps with sender_dependent

[Wietse Venema]

Viktor Dukhovni:
> > On 11 Aug 2021, at 11:00 am, Matt Corallo  wrote:
> > 
> > Hmm, well I suppose consider this a feature request for 
> > sender_dependent_relay_transport_maps or sender_dependent_transport_maps :)
> 
> No such feature fits into a single-key lookup design.
> 
> You're looking to exempt specific sender (domains) from the recipient-based
> nexthop of specific recipient domains.  This is a multi-key transport
> decision, and supporting this requires a radically different design.
> 
> So the feature request is extremely unlikely to be actionable.

We solved a multi-criteria decision problem with check_policy_service
in Postfix access maps, where a policy server can make a ruling
based on multiple attributes. Whet helped here was that many smtpd
processes make policy requests in parallel, so that individual
response latencies do not add up.

Routing decisions are different - they are requested by a single
queue manager process, so that individual response latencies will
add up unless that part of the scheduler is also parallized (just
the handling of delivery requests is parallelized). But then who
would implement the server that makes routing decisions?

Maybe time to revive the vintage-1997 ideas for a configurable
trivial-rewrite service. I abandoned that because it started
to look like sendmail.cf.

Wietse

Re: Overriding transport_maps with sender_dependent

[Viktor Dukhovni]

> On 11 Aug 2021, at 11:00 am, Matt Corallo  wrote:
> 
> Hmm, well I suppose consider this a feature request for 
> sender_dependent_relay_transport_maps or sender_dependent_transport_maps :)

No such feature fits into a single-key lookup design.

You're looking to exempt specific sender (domains) from the recipient-based
nexthop of specific recipient domains.  This is a multi-key transport
decision, and supporting this requires a radically different design.

So the feature request is extremely unlikely to be actionable.

-- 
Viktor.

Re: Overriding transport_maps with sender_dependent

[Matt Corallo]

Hmm, well I suppose consider this a feature request for 
sender_dependent_relay_transport_maps or sender_dependent_transport_maps :)

Matt

> On Aug 10, 2021, at 23:01, Viktor Dukhovni  wrote:
> 
> On Tue, Aug 10, 2021 at 10:34:52PM -0400, Matt Corallo wrote:
> 
>> I have a need to map some destination domains to a specific smtp
>> nexthop, but need to override that nexthop on a sender_dependent
>> basis. I've tried a few things and all with no luck:
> 
> Sorry, that's not directly possible.  Sender-dependent transport
> selection overrides only the *default* transport.  Anything else would
> require looking at both the sender and recipient at the same time, and
> Postfix does not presently have support for multi-key tables.
> 
>> Am I missing something or is there some way to do a custom rewrite
>> engine?
> 
> It may be possible to rewrite the recipients in question to replace the
> domain part with the desired nexthop, so that the default transport
> would take care of delivery to the correct nexthop, and this case,
> sender-dependent overrides can kick in.  You might then need to reverse
> the rewrites via smtp_generic_maps.
> 
> Another option is a multi-instance pipeline, in which the recipient
> determines the downstream Postfix instance, and then in some special
> downstream instances the nexthop in question is the default transport,
> and again sender-based overrides can take place.
> 
>> On Tue, Aug 10, 2021 at 10:43:46PM -0400, Matt Corallo wrote:
>> Oh, and if its possible, is it also possible to specify the original
>> domains as "any domain with an MX of $REGEX" instead of only "any
>> recipient domain of $REGEX"?
> 
> No, the queue manager has no access to MX host lookups which happen
> during delivery, not transport selection.
> 
> -- 
>  Viktor.

Re: Overriding transport_maps with sender_dependent

[Viktor Dukhovni]

On Tue, Aug 10, 2021 at 10:34:52PM -0400, Matt Corallo wrote:

> I have a need to map some destination domains to a specific smtp
> nexthop, but need to override that nexthop on a sender_dependent
> basis. I've tried a few things and all with no luck:

Sorry, that's not directly possible.  Sender-dependent transport
selection overrides only the *default* transport.  Anything else would
require looking at both the sender and recipient at the same time, and
Postfix does not presently have support for multi-key tables.

> Am I missing something or is there some way to do a custom rewrite
> engine?

It may be possible to rewrite the recipients in question to replace the
domain part with the desired nexthop, so that the default transport
would take care of delivery to the correct nexthop, and this case,
sender-dependent overrides can kick in.  You might then need to reverse
the rewrites via smtp_generic_maps.

Another option is a multi-instance pipeline, in which the recipient
determines the downstream Postfix instance, and then in some special
downstream instances the nexthop in question is the default transport,
and again sender-based overrides can take place.

On Tue, Aug 10, 2021 at 10:43:46PM -0400, Matt Corallo wrote:

> Oh, and if its possible, is it also possible to specify the original
> domains as "any domain with an MX of $REGEX" instead of only "any
> recipient domain of $REGEX"?

No, the queue manager has no access to MX host lookups which happen
during delivery, not transport selection.

-- 
Viktor.

Re: Overriding transport_maps with sender_dependent

[Matt Corallo]

Oh, and if its possible, is it also possible to specify the original domains as "any domain with an MX of $REGEX" 
instead of only "any recipient domain of $REGEX"?


Thanks,
Matt

On 8/10/21 22:34, Matt Corallo wrote:
I have a need to map some destination domains to a specific smtp nexthop, but need to override that nexthop on a 
sender_dependent basis. I've tried a few things and all with no luck:


* transport_maps specifying the nexthop can't be overridden at all, it seems (and doesn't support sender_dependent 
matching),
* putting the specified destination domains in relay_domains (and stopping relay to them via smtpd_relay_restrictions) 
but there doesn't seem to be a way to override relay_transport on a sender_dependent way
* relayhost-based stuff doesn't seem to be an option as I don't want to change the delivery of mail that isn't either 
from one of the sender_dependent rules or to one of the specified domains.


Am I missing something or is there some way to do a custom rewrite engine?

Thanks,
Matt

Overriding transport_maps with sender_dependent

[Matt Corallo]

I have a need to map some destination domains to a specific smtp nexthop, but need to override that nexthop on a 
sender_dependent basis. I've tried a few things and all with no luck:


* transport_maps specifying the nexthop can't be overridden at all, it seems (and doesn't support sender_dependent 
matching),
* putting the specified destination domains in relay_domains (and stopping relay to them via smtpd_relay_restrictions) 
but there doesn't seem to be a way to override relay_transport on a sender_dependent way
* relayhost-based stuff doesn't seem to be an option as I don't want to change the delivery of mail that isn't either 
from one of the sender_dependent rules or to one of the specified domains.


Am I missing something or is there some way to do a custom rewrite engine?

Thanks,
Matt

Re: Newbie question about transport_maps failing

[David Favor]

Wietse Venema wrote:

David Favor:
[ Charset ISO-8859-1 converted... ]

Viktor Dukhovni wrote:

On Sat, May 29, 2021 at 11:30:51AM -0500, David Favor wrote:


# cat /etc/postfix/sender_dependant_default_transport
/.*@davidfavor.com/ :
/.*@fixdeliver.com/ :
/.*/ discard:

7) Sending message still allows random sending domains...

The transport table only selects a delivery channel, you've chosen
discard as the delivery channel for messages from unexpected domains.


# echo test | mailx -r some...@foo.com -s "Test Message - $(date)" 
da...@davidfavor.com

May 29 11:29:47 net17-david-favor-smtp postfix/qmgr[48007]: F25241BA2030: 
from=, size=430, nrcpt=1 (queue active)
May 29 11:29:47 net17-david-favor-smtp postfix/discard[48021]: F25241BA2030: 
to=,

 --

   relay=none, delay=0.01, delays=0.01/0/0/0, dsn=2.0.0, status=sent 
(davidfavor.com)

 --

The message was discarded (delivered nowhere, as requested).

Mention what to use in place "discard" to block disallowed sending domains,
then log a message with DNS != 2.0.0 as the reason code.


Use error: instead of discard:. 


Wietse


One solution that seems to work is to add the following main.cf entry...

   default_transport = error:541 Delivery policy failure, unauthorized sending 
domain specified

Re: Newbie question about transport_maps failing

[Wietse Venema]

David Favor:
[ Charset ISO-8859-1 converted... ]
> Viktor Dukhovni wrote:
> > On Sat, May 29, 2021 at 11:30:51AM -0500, David Favor wrote:
> > 
> >> # cat /etc/postfix/sender_dependant_default_transport
> >> /.*@davidfavor.com/ :
> >> /.*@fixdeliver.com/ :
> >> /.*/ discard:
> >>
> >> 7) Sending message still allows random sending domains...
> > 
> > The transport table only selects a delivery channel, you've chosen
> > discard as the delivery channel for messages from unexpected domains.
> > 
> >> # echo test | mailx -r some...@foo.com -s "Test Message - $(date)" 
> >> da...@davidfavor.com
> >>
> >> May 29 11:29:47 net17-david-favor-smtp postfix/qmgr[48007]: F25241BA2030: 
> >> from=, size=430, nrcpt=1 (queue active)
> >> May 29 11:29:47 net17-david-favor-smtp postfix/discard[48021]: 
> >> F25241BA2030: to=,
> >  --
> >>relay=none, delay=0.01, delays=0.01/0/0/0, dsn=2.0.0, status=sent 
> >> (davidfavor.com)
> >  --
> > 
> > The message was discarded (delivered nowhere, as requested).
> 
> Mention what to use in place "discard" to block disallowed sending domains,
> then log a message with DNS != 2.0.0 as the reason code.

Use error: instead of discard:. 

Wietse

Re: Newbie question about transport_maps failing

[David Favor]

Viktor Dukhovni wrote:

On Sat, May 29, 2021 at 11:30:51AM -0500, David Favor wrote:


# cat /etc/postfix/sender_dependant_default_transport
/.*@davidfavor.com/ :
/.*@fixdeliver.com/ :
/.*/ discard:

7) Sending message still allows random sending domains...


The transport table only selects a delivery channel, you've chosen
discard as the delivery channel for messages from unexpected domains.


# echo test | mailx -r some...@foo.com -s "Test Message - $(date)" 
da...@davidfavor.com

May 29 11:29:47 net17-david-favor-smtp postfix/qmgr[48007]: F25241BA2030: 
from=, size=430, nrcpt=1 (queue active)
May 29 11:29:47 net17-david-favor-smtp postfix/discard[48021]: F25241BA2030: 
to=,

 --

   relay=none, delay=0.01, delays=0.01/0/0/0, dsn=2.0.0, status=sent 
(davidfavor.com)

 --

The message was discarded (delivered nowhere, as requested).


Mention what to use in place "discard" to block disallowed sending domains,
then log a message with DNS != 2.0.0 as the reason code.

Thanks.

Re: Newbie question about transport_maps failing

[Viktor Dukhovni]

On Sat, May 29, 2021 at 11:30:51AM -0500, David Favor wrote:

> # cat /etc/postfix/sender_dependant_default_transport
> /.*@davidfavor.com/ :
> /.*@fixdeliver.com/ :
> /.*/ discard:
> 
> 7) Sending message still allows random sending domains...

The transport table only selects a delivery channel, you've chosen
discard as the delivery channel for messages from unexpected domains.

> # echo test | mailx -r some...@foo.com -s "Test Message - $(date)" 
> da...@davidfavor.com
> 
> May 29 11:29:47 net17-david-favor-smtp postfix/qmgr[48007]: F25241BA2030: 
> from=, size=430, nrcpt=1 (queue active)
> May 29 11:29:47 net17-david-favor-smtp postfix/discard[48021]: F25241BA2030: 
> to=,
 --
>relay=none, delay=0.01, delays=0.01/0/0/0, dsn=2.0.0, status=sent 
> (davidfavor.com)
 --

The message was discarded (delivered nowhere, as requested).

-- 
Viktor.

Re: Newbie question about transport_maps failing

[David Favor]

Wietse Venema wrote:

David Favor:
[ Charset ISO-8859-1 converted... ]

Wietse Venema wrote:

IL Ka:

If you want to choose transport based on sender, you probably want
"sender_dependent_default_transport_maps"



http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps


It seems that this option doesn't support wildcards.

Yes it does. Use a pcre: or regexp: table.



It says

The tables are searched by the envelope sender address and @domain.

That's used when you DON'T specify pcre, regexp, etc.

Wietse

Still fails, so I'm missing something.


Forgot to put pcre: in main.cf?


4) Compile generate hash file.

# postmap sender_dependant_default_transport


This is fundamental: pcre is not a hash file.

Wietse


1) main.cf entry

# grep ^sender_dependent_default_transport_maps /etc/postfix/main.cf
sender_dependent_default_transport_maps = 
pcre:/etc/postfix/sender_dependant_default_transport

2) Oddity... of seems to be working now + working... unexpectedly...

3) Send... swaks --silent --from f...@foo.com --to da...@davidfavor.com 
--server 127.0.0.1

4) Log entries...

May 29 11:48:16 net17-david-favor-smtp postfix/smtpd[48778]: connect from 
localhost[127.0.0.1]
May 29 11:48:16 net17-david-favor-smtp postfix/smtpd[48778]: C2FA51BA000C: 
client=localhost[127.0.0.1]
May 29 11:48:16 net17-david-favor-smtp postfix/cleanup[48781]: C2FA51BA000C: 
message-id=<20210529114816.048777@net17-david-favor-smtp>
May 29 11:48:16 net17-david-favor-smtp postfix/qmgr[48755]: C2FA51BA000C: 
from=, size=472, nrcpt=1 (queue active)
May 29 11:48:16 net17-david-favor-smtp postfix/smtpd[48778]: disconnect from 
localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
May 29 11:48:16 net17-david-favor-smtp postfix/discard[48782]: C2FA51BA000C: 
to=, relay=none, delay=0.01, delays=0.01/0/0/0, 
dsn=2.0.0, status=sent (davidfavor.com)
May 29 11:48:16 net17-david-favor-smtp postfix/qmgr[48755]: C2FA51BA000C: 
removed

5) In log entry, notice...

  dsn=2.0.0, status=sent (davidfavor.com)

   Not...

  dsn=2.0.0, status=sent (queued)

4) Looking - postqueue -q - queue does show empty.

And, looking at my MX logs... no message is received...

So this does... seem to work...

5) Last question...

How do effect my logging to surface this problem.

I'd have expected something like...

   dsn=5.1.0, status=bounced/discarded (Domain foo.com not allowed to send)

Or something like this...

Let me know how to setup logging to catch this type of problem.

Thanks!

Re: Newbie question about transport_maps failing

[Wietse Venema]

David Favor:
[ Charset ISO-8859-1 converted... ]
> Wietse Venema wrote:
> > IL Ka:
> >>>
>  If you want to choose transport based on sender, you probably want
>  "sender_dependent_default_transport_maps"
> 
> 
> >>> http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> >>>
> >> It seems that this option doesn't support wildcards.
> > 
> > Yes it does. Use a pcre: or regexp: table.
> > 
> > 
> >> It says
> >>> The tables are searched by the envelope sender address and @domain.
> > 
> > That's used when you DON'T specify pcre, regexp, etc.
> > 
> > Wietse
> 
> Still fails, so I'm missing something.

Forgot to put pcre: in main.cf?

> 4) Compile generate hash file.
> 
> # postmap sender_dependant_default_transport

This is fundamental: pcre is not a hash file.

Wietse

Re: Newbie question about transport_maps failing

[David Favor]

Wietse Venema wrote:

IL Ka:



If you want to choose transport based on sender, you probably want
"sender_dependent_default_transport_maps"



http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps


It seems that this option doesn't support wildcards.


Yes it does. Use a pcre: or regexp: table.



It says

The tables are searched by the envelope sender address and @domain.


That's used when you DON'T specify pcre, regexp, etc.

Wietse


Still fails, so I'm missing something.

Steps I've gone through.

1) Postfix version, out of standard Ubuntu PPA.

# postconf mail_version
mail_version = 3.4.13

2) Ensure pcre is available...

# postconf -m | grep -e pcre
pcre

3) Setup sender_dependant_default_transport file

# cat /etc/postfix/sender_dependant_default_transport
/.*@davidfavor.com/ :
/.*@fixdeliver.com/ :
/.*/ discard:

4) Compile generate hash file.

# postmap sender_dependant_default_transport

5) Ingest new config.

postfix reload

6) Lookups seem to be working...

# postmap -q da...@davidfavor.com pcre:sender_dependant_default_transport
:

# postmap -q f...@foo.com pcre:sender_dependant_default_transport
discard:

7) Sending message still allows random sending domains...

# echo test | mailx -r some...@foo.com -s "Test Message - $(date)" 
da...@davidfavor.com

May 29 11:29:47 net17-david-favor-smtp postfix/pickup[48008]: F25241BA2030: uid=0 
from=
May 29 11:29:47 net17-david-favor-smtp postfix/cleanup[48019]: F25241BA2030: 
message-id=<20210529162947.f25241ba2...@mta1.davidfavor.com>
May 29 11:29:47 net17-david-favor-smtp postfix/qmgr[48007]: F25241BA2030: 
from=, size=430, nrcpt=1 (queue active)
May 29 11:29:47 net17-david-favor-smtp postfix/discard[48021]: F25241BA2030: 
to=, relay=none, delay=0.01, delays=0.01/0/0/0, 
dsn=2.0.0, status=sent (davidfavor.com)
May 29 11:29:47 net17-david-favor-smtp postfix/qmgr[48007]: F25241BA2030: 
removed

Re: Newbie question about transport_maps failing

[Viktor Dukhovni]

On Fri, May 28, 2021 at 10:27:29AM -0500, David Favor wrote:

> My goal is to limit allowed sender domains, to ensure no
> mail config problem sends from a domain with no no SPF
> authorization for sending IP.

The transport table is surely the wrong place to do that.  Instead, use
access(5) to refuse mail from unsupported sender addresses.

For local submission (often out of scope if the MTA in question
has no local submission users, b/c it a dedicated server, or
an outbound instance in a multi-instance setup, ...), Postfix 3.6
adds local_login_sender_maps which can be used to restrict the
allowed domains for local submission:

local_login_sender_maps =
inline:{ { root = *}, { postfix = * } },
static:{ @davidfavor.com, @fixdeliver.com }

If local submission is in fact in scope for you, because you have
untrusted users logged into the MTA, you can upgrade to Postfix 3.6,
or use a multi-instance configuration with local submission going to
a null-client instance which relays to the MTA instance, which can
use access(5) to reject relaying with non-local sender addresses.

-- 
Viktor.

Re: Newbie question about transport_maps failing

[Wietse Venema]

IL Ka:
> >
> >
> > > If you want to choose transport based on sender, you probably want
> > > "sender_dependent_default_transport_maps"
> > >
> > >
> > http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> > >
> >
> >
> It seems that this option doesn't support wildcards.

Yes it does. Use a pcre: or regexp: table.


> It says
> >The tables are searched by the envelope sender address and @domain.

That's used when you DON'T specify pcre, regexp, etc.

Wietse

Re: Newbie question about transport_maps failing

[IL Ka]

>
>
> > If you want to choose transport based on sender, you probably want
> > "sender_dependent_default_transport_maps"
> >
> >
> http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> >
>
>
It seems that this option doesn't support wildcards.
It says
>The tables are searched by the envelope sender address and @domain.

So, I set "discard" as default transport, and did one exception with this
option.

main.cf:
sender_dependent_default_transport_maps = hash:/etc/postfix/map
default_transport=discard

map:
@example.orgsmtp

Sending mail from "example.org"
$ swaks --to u...@example.net --from r...@example.org -4 --server 127.0.0.1

Goes to SMTP:
postfix/smtp[4156]: 62D4D9F81D: to=, relay=none,
delay=0.04, delays=0.01/0.01/0.03/0, dsn=5.1.0, status=bounced (Domain
example.net does not accept mail (nullMX))

Sending mail from "example.net"
$ swaks --to u...@example.net --from r...@example.net -4 --server 127.0.0.1

Discard:
 postfix/discard[4162]: 2209D9F81D: to=, relay=none,
delay=0.01, delays=0.01/0/0/0, dsn=2.0.0, status=sent (example.net)

Re: Newbie question about transport_maps failing

[IL Ka]

On Fri, May 28, 2021 at 6:28 PM David Favor  wrote:

> My goal is to limit allowed sender domains, to ensure no
> mail config problem sends from a domain with no no SPF
> authorization for sending IP.
>

If you want to choose transport based on sender, you probably want
"sender_dependent_default_transport_maps"

http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps

Newbie question about transport_maps failing

[David Favor]

My goal is to limit allowed sender domains, to ensure no
mail config problem sends from a domain with no no SPF
authorization for sending IP.

What I've done...

1) Setup /etc/postfix/transport

# cat /etc/postfix/transport
davidfavor.com :
fixdeliver.com :
* discard:

# postmap /etc/postfix/transport

# postmap -s /etc/postfix/transport
*   discard:
davidfavor.com  :
fixdeliver.com  :

3) postfix reload

4) Send a test message...

echo test | mailx -r some...@foo.com -s "Test Message - $(date)" 
da...@davidfavor.com

5) inotifywait camped on /etc/postfix shows /etc/postfix/transport.db being 
read.

6) And... messages still delivers, rather than being blocked.

May 28 10:15:46 net17-david-favor-smtp postfix/qmgr[29555]: CE2801BA2030: 
from=, size=430, nrcpt=1 (queue active)
May 28 10:15:46 net17-david-favor-smtp postfix/smtp[29585]: CE2801BA2030: to=, relay=smtp.davidfavor.com[142.44.168.82]:25, delay=0.03, delays=0/0/0.02/0.01, dsn=2.0.0, 
status=sent (250 Queued)


7) Someone let me know how to fix this.

Thanks...

8) Dump of my entire config...

# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
inet_interfaces = all
inet_protocols = all
mailbox_size_limit = 0
mydestination = localhost, localhost.localdomain
myhostname = mta1.davidfavor.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = davidfavor.com
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_bind_address = 144.217.229.104
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
defer_unauth_destination
smtpd_tls_cert_file = /etc/letsencrypt/live/mta1.davidfavor.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mta1.davidfavor.com/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
transport_maps = hash:/etc/postfix/transport

Re: Where is the transport_maps resolved?

[Viktor Dukhovni]

On Tue, Mar 16, 2021 at 11:07:54AM +0100, Jens Hoffrichter wrote:

> We have a central, internal mail dispatching system, after all the
> content filtering etc. which processes inbound and outbound emails.

It seems that this is the system you're trying to configure.  Do you
have any influence on the configuration of the upstream systems?

> The challenge I have now is that all messages from applications (which
> are concentrated on a different class of servers before as well) to
> the backend mail servers  need to be delivered to a different port on
> the backend mail servers.

It is likely simplest to have the application traffic come in to a
different IP address or port and land in a different Postfix instance as
a result (as in MULTI_INSTANCE_README, not just a separate smtpd(8)
service).

> Mail from applications to external recipients need to be delivered to
> the regular smart host. All other mail to the backend mail servers
> needs to be delivered on the regular port.

This can be difficult to impossible to do correctly within a single
instance, because your routing decision is both origin (application vs.
regular sender) *and* destination (internal vs. external recipient)
dependent...

> Application to internal recipient -> app mail concentrator -> mail
> central -> backend with special port

If the applications are identifiable by an envelope sender address
(after it was perhaps mutated in cleanup) these can be preempted via

# default relayhost
relayhost = [backend]
# maps appsender -> [backend]:someport
sender_dependent_relayhost_maps = type:table ...

> Application to external recipient -> app mail concentrator -> mail
> central -> regular outbound smarthost

These can be exempted from the relayhost munging via:

default_transport = smtp:[backend]:25

an explicit nexthop on the default transport is not preempted
by "relayhost" settings (normal or sender-dependent).

> Any other mail to internal recipient -> mail central -> backend

These will use "relayhost" or "default_transport", which
amount to the same thing.

> My thought was now to add a special X-Header on the app mail
> concentrator, which changes the routing decision on the mail central.

Headers are not helpful here, instead if you can decorate the sender
addresses into a special subdomain for application senders, that'd be
more useful.

sen...@app.example.com

you could do that as a rewrite in cleanup(8) if the application traffic
comes into Postfix on a different port.

-- 
Viktor.

Re: Where is the transport_maps resolved?

[Jens Hoffrichter]

Hi Viktor!

On Mon, Mar 15, 2021 at 5:23 PM Viktor Dukhovni
 wrote:

> Transport lookups in smtpd(8) are just for recipient classification and
> validation, so that it can distinguish between local, virtual alias,
> virtual mailbox, relay recipients and the rest.  No actual routing
> happens in smtpd(8).
Thanks for clarifying this, it is how I suspected.

> > .. now where the transport_maps entry to the next hop is resolved?
> > Is that in the qmgr?
>
> Naturally, the queue manager is responsible for handling off message
> envelopes to the various delivery agents.  There's only one queue
> manager, which limits your choices to "content_filter", or custom
> rewriting in a dedicated per-smtpd(8) cleanup(8) service.

I'm conceptually still stuck a bit on this, but I'm probably just
missing a tiny piece so far - or something huge, that I cannot
implement the thing as I had planned.

We have a central, internal mail dispatching system, after all the
content filtering etc. which processes inbound and outbound emails.
The challenge I have now is that all messages from applications (which
are concentrated on a different class of servers before as well) to
the backend mail servers  need to be delivered to a different port on
the backend mail servers. Mail from applications to external
recipients need to be delivered to the regular smart host. All other
mail to the backend mail servers needs to be delivered on the regular
port.

So I have these three classes of routing:

Application to internal recipient -> app mail concentrator -> mail
central -> backend with special port
Application to external recipient -> app mail concentrator -> mail
central -> regular outbound smarthost
Any other mail to internal recipient -> mail central -> backend

My thought was now to add a special X-Header on the app mail
concentrator, which changes the routing decision on the mail central.
But if I add the header to all mails, and use a generic header_check
to set a FILTER action for that header, I am actually not routing the
external mails to the smarthost anymore, but also to the internal
backend, which obviously does not work.

>From what I understand, when I give it into the smtp transport, all
routing decision has already been made, so I cannot change the nexthop
with a header_check in the smtp transport anymore (even though I only
want to change the port - but I guess it is the same difference).

Can I somehow define something on a header that a different
transport_map is applied? I will make sure that that X-header is only
ever added on the inside, and is filtered on any ingress point into
our mail infrastructure.

Any help on this is appreciated!

Best regards,
Jens

Re: Where is the transport_maps resolved?

[Viktor Dukhovni]

On Mon, Mar 15, 2021 at 03:24:19PM +0100, Jens Hoffrichter wrote:

> I can see in the log file that the trivial rewrite resolves the next
> hop correctly from the extra transport map, and sends that back to the
> smtpd, but the information is ignored when it comes to the smtp
> process.

Transport lookups in smtpd(8) are just for recipient classification and
validation, so that it can distinguish between local, virtual alias,
virtual mailbox, relay recipients and the rest.  No actual routing
happens in smtpd(8).

> .. now where the transport_maps entry to the next hop is resolved?
> Is that in the qmgr?

Naturally, the queue manager is responsible for handling off message
envelopes to the various delivery agents.  There's only one queue
manager, which limits your choices to "content_filter", or custom
rewriting in a dedicated per-smtpd(8) cleanup(8) service.

While cleanup(8) can't directly select a custom transport, it
can alter the recipient domain in a manner than ends up selecting
a suitable transport.

-- 
Viktor.

Where is the transport_maps resolved?

[Jens Hoffrichter]

Hi!

I'm trying to implement a relatively esoteric use case right now,
where all the mails I sent to postfix on a specific smtp daemon
configured in the master.cf to a different nexthop than the regular
mail going through the services. But this should only occur for a list
of domains (my internal domains, which should be routed to a backend
mailbox server) - mail for external recipients should be routed
through the normal outbound mail service.

I tried to implement that by adding another smtpd service with a
different rewrite_service_name set, and started an additional
trivial-rewrite with the -o transport_maps set to a different hash
table, where I have put in my internal domains.

I can see in the log file that the trivial rewrite resolves the next
hop correctly from the extra transport map, and sends that back to the
smtpd, but the information is ignored when it comes to the smtp
process.

I suspect this is the wanted behavior, so I'm trying to figure out
right now where the transport_maps entry to the next hop is resolved?
Is that in the qmgr? It would make sense, as the routing information
could change, and the nexthop information from the smtpd could be
totally outdated by the time a delivery succeeds.

Relevant configuration and logs:

main.cf:

appmail_transport_maps = hash:/etc/postfix/extratransport

master.cf:

10.0.0.55:587   inetn   -   y   -   -   smtpd
   -o smtpd_banner=appmail
   -o syslog_name=smtpd_appmail
   -o rewrite_service_name=appmailtransports

appmailtransports   unix-   -   y   -   -
 trivial-rewrite -v
   -o transport_maps=$appmail_transport_maps

/etc/postfix/extratransport:

p-square.de smtp:[10.0.0.1]

Excerpt from mail.info for a test domain:

Mar 15 15:00:14 menchi postfix/trivial-rewrite[1125]:
match_list_match: p-square.de: no match
Mar 15 15:00:14 menchi postfix/trivial-rewrite[1125]: maps_find:
transport_maps: jens.hoffrich...@p-square.de: not found
Mar 15 15:00:14 menchi postfix/trivial-rewrite[1125]: maps_find:
transport_maps:
hash:/etc/postfix/extratransport(0,lock|no_regsub|fold_fix|utf8_request):
p-square.de = smtp:[10.0.0.1]
Mar 15 15:00:14 menchi postfix/trivial-rewrite[1125]: mail_addr_find:
jens.hoffrich...@p-square.de -> smtp:[10.0.0.1]
Mar 15 15:00:14 menchi postfix/trivial-rewrite[1125]: `b...@blupp.de'
-> `jens.hoffrich...@p-square.de' -> (`smtp' `[10.0.0.1]'
`jens.hoffrich...@p-square.de' `4096')
Mar 15 15:00:14 menchi smtpd_appmail/smtpd[1122]: C2695742C638:
client=emby.whaleisland.casa[10.0.0.12]
Mar 15 15:00:17 menchi postfix/cleanup[1126]: C2695742C638: message-id=<>
Mar 15 15:00:17 menchi postfix/qmgr[1109]: C2695742C638:
from=, size=206, nrcpt=1 (queue active)
Mar 15 15:00:47 menchi postfix/smtp[]: connect to
psquare-de0c.mail.protection.outlook.com[104.47.9.36]:25: Connection
timed out
Mar 15 15:01:17 menchi postfix/smtp[]: connect to
psquare-de0c.mail.protection.outlook.com[104.47.8.36]:25: Connection
timed out
Mar 15 15:01:17 menchi postfix/smtp[]: C2695742C638:
to=, relay=none, delay=71,
delays=10/0/60/0, dsn=4.4.1, status=deferred (connect to
psquare-de0c.mail.protection.outlook.com[104.47.8.36]:25: Connection
timed out)

This was just a quick and dirty test setup to confirm the things I was
seeing on a server with much less access than to the test box, so
nothing here is set in stone. But the experience here is the same as
on the other box.

Thanks for any insights into the process!

Jens

Re: transport_maps equivalent for virtual mailboxes

[Noel Jones]

The users you put in transport_maps don’t use virtual_transport, so there’s no 
conflict


  — Noel Jones

> On Sep 14, 2020, at 8:31 PM, Stephen Ingram  wrote:
> 
> 
>> On Mon, Sep 14, 2020 at 5:59 PM Noel Jones  wrote:
> 
>> On 9/14/2020 7:25 PM, Stephen Ingram wrote:
>> > 
>> > What I really want is a recipient based relayhost_map,
>> 
>> Yes, use transport_maps for that, with a recipient email address as 
>> the key.
> 
> But I thought you couldn't use transport_maps along with virtual_transport, 
> no?
> 
> Steve 

Re: transport_maps equivalent for virtual mailboxes

[Stephen Ingram]

On Mon, Sep 14, 2020 at 5:59 PM Noel Jones  wrote:

> On 9/14/2020 7:25 PM, Stephen Ingram wrote:
> >
> > What I really want is a recipient based relayhost_map,
>
> Yes, use transport_maps for that, with a recipient email address as
> the key.
>

But I thought you couldn't use transport_maps along with virtual_transport,
no?

Steve

Re: transport_maps equivalent for virtual mailboxes

[Noel Jones]

On 9/14/2020 7:25 PM, Stephen Ingram wrote:


What I really want is a recipient based relayhost_map,


Yes, use transport_maps for that, with a recipient email address as 
the key.





  -- Noel Jones

Re: transport_maps equivalent for virtual mailboxes

[Stephen Ingram]

On Mon, Sep 14, 2020 at 5:20 PM Noel Jones  wrote:

> On 9/14/2020 7:03 PM, Stephen Ingram wrote:
> > I'm using virtual mailboxes (virtual_mailbox_domains,
> > virtual_mailbox_maps, virtual_alias_maps) and now want to use
> > something like transport_maps so I can control where the mail is
> > relayed to based on the recipient domain. There appears to be no
> > equivalent when you are using virtual mailboxes, like
> > virtual_transport_maps. The documentation says that
> > virtual_transport is only a final destination type of setting so I'm
> > wondering if there is a different way to accomplish this.
> >
> > Steve
>
> You're wanting to relay some set of users to another system for
> final delivery?  Use transport_maps for that. The key in
> transport_maps can either be the domain, or an individual user address.
>
> If I have misunderstood your question, please give more details.
>
> What I really want is a recipient based relayhost_map, but I understand
that doesn't exist. Everything points to that you need to use a transport
map to push it on to the next destination. Does that make sense? Perhaps
I'm trying to do too much on one server and need to push the virtual
deliverables over to another server that can handle final delivery since
this is really an outgoing server.

Steve

Re: transport_maps equivalent for virtual mailboxes

[Noel Jones]

On 9/14/2020 7:03 PM, Stephen Ingram wrote:
I'm using virtual mailboxes (virtual_mailbox_domains, 
virtual_mailbox_maps, virtual_alias_maps) and now want to use 
something like transport_maps so I can control where the mail is 
relayed to based on the recipient domain. There appears to be no 
equivalent when you are using virtual mailboxes, like 
virtual_transport_maps. The documentation says that 
virtual_transport is only a final destination type of setting so I'm 
wondering if there is a different way to accomplish this.


Steve


You're wanting to relay some set of users to another system for 
final delivery?  Use transport_maps for that. The key in 
transport_maps can either be the domain, or an individual user address.


If I have misunderstood your question, please give more details.



  -- Noel Jones

transport_maps equivalent for virtual mailboxes

[Stephen Ingram]

I'm using virtual mailboxes (virtual_mailbox_domains, virtual_mailbox_maps,
virtual_alias_maps) and now want to use something like transport_maps so I
can control where the mail is relayed to based on the recipient domain.
There appears to be no equivalent when you are using virtual mailboxes,
like virtual_transport_maps. The documentation says that virtual_transport
is only a final destination type of setting so I'm wondering if there is a
different way to accomplish this.

Steve

Re: transport_maps not taking on

[Kai Schaetzl]

Noel Jones wrote on Thu, 8 Aug 2019 10:49:54 -0500:

> That looks like a policy service and not a milter.

Yeah, right. It's a dovecot authenticator I think.

> 
> Regardless, postfix accepts mail, running it through all configured 
> milters, restrictions, and policy services, then puts it in the 
> queue.  THEN it consults the transport table to see where to deliver 
> it.  (this is somewhat over-simplification, but should answer your 
> question)

Yeah, thanks! The milter is getting consulted every time.
I think it works now.

And I've found out about the mysterious holds. It was an old header_check 
file on that machine. It wasn't used until I copied over the uncommented 
header_check directive.

Thanks!

Kai

Re: transport_maps not taking on

[Noel Jones]

On 8/8/2019 10:41 AM, Kai Schaetzl wrote:

I have still one question, though.

I fear that forwarding the mail via transport may not consult the milter.
At the moment the remote Exchange is still not configured to accept the
domain. I'm still waiting for that to take place.
In the meantime, though, I would have expected that the course of action
is the following:
- postfix accepts the mail to this domain
- applies the restrictions
- once the mail has successfully passed the restrictions
- it delivers to the transport-specified destination

But in this case I should see a connection to and validation by the milter
before postfix tells me that the remote Exchange won't accept it.
And it doesn't do that.
Or does it first check if it would be able to deliver to the destination
before it applies the other restrictions?

The rspamd milter is set to get consulted at the end of

smtpd_recipient_restrictions =
..
..
check_policy_service inet:127.0.0.1:10024,
permit

and: smtpd_delay_reject = yes

Will this check the milter before the message is sent over to the
transport-specified nexthop?

Thanks for a clarification!

Kai





That looks like a policy service and not a milter.

Regardless, postfix accepts mail, running it through all configured 
milters, restrictions, and policy services, then puts it in the 
queue.  THEN it consults the transport table to see where to deliver 
it.  (this is somewhat over-simplification, but should answer your 
question)



  -- Noel Jones

Re: transport_maps not taking on

[Kai Schaetzl]

I have still one question, though.

I fear that forwarding the mail via transport may not consult the milter.
At the moment the remote Exchange is still not configured to accept the 
domain. I'm still waiting for that to take place.
In the meantime, though, I would have expected that the course of action 
is the following:
- postfix accepts the mail to this domain
- applies the restrictions
- once the mail has successfully passed the restrictions
- it delivers to the transport-specified destination

But in this case I should see a connection to and validation by the milter 
before postfix tells me that the remote Exchange won't accept it.
And it doesn't do that.
Or does it first check if it would be able to deliver to the destination 
before it applies the other restrictions?

The rspamd milter is set to get consulted at the end of

smtpd_recipient_restrictions = 
..
..
check_policy_service inet:127.0.0.1:10024,
permit

and: smtpd_delay_reject = yes

Will this check the milter before the message is sent over to the 
transport-specified nexthop?

Thanks for a clarification!

Kai

Re: transport_maps not taking on

[Kai Schaetzl]

I went back to my original config with virtual users and domains, with and 
without the milter. I left transport and mynetworks as they were. I have 
no idea why, but it's working now and I get a bounce from the remote 
server (= it's not yet accepting the mail). No more attempts to deliver 
locally or put on hold. I hope it remains that way.
Thanks for the help!

Kai

Re: transport_maps not taking on

[Kai Schaetzl]

Wietse Venema wrote on Wed, 7 Aug 2019 19:33:05 -0400 (EDT):

> Once a message enters in the hold queue IT WILL SIT THERE FOREVER
> unless something releases it from that queue.

Understood. Thanks! I should have known from the past (see below).

> 
> You need to figure out why messages are placed on the hold queue.
> One example is when a Milter returns a "quarantine" action. Another
> one is Mailscanner.

I used to use MailScanner until one or two years ago. Yeah, you actually 
configure Postfix to put all incoming messages in the hold queue, 
MailScanner scans it and puts it actively in the delivery queue.

rspamd doesn't put them to quarantine. If I requeue the message with -r it 
is put on hold again very soon. According to man postsuper the requeue 
does not subject it to the milter again. But I will take it out of the 
equation for now to be sure. It looks to me like I must have disabled any 
attempt to deliver to a transport at all.

Kai

Re: transport_maps not taking on

[Wietse Venema]

Kai Schaetzl:
> Noel Jones wrote on Wed, 7 Aug 2019 13:37:08 -0500:
> 
> > Postfix logs all delivery attempts.
> 
> I thought so, but ...
> In that case it just hangs in the queue and nothing happens after the 
> milter was consulted. I can see it getting logged in rspamd and then it 
> just sits in the hold queue. Rescheduling it makes no difference. It 
> doesn't even log it.

Once a message enters in the hold queue IT WILL SIT THERE FOREVER
unless something releases it from that queue.

You need to figure out why messages are placed on the hold queue.
One example is when a Milter returns a "quarantine" action. Another
one is Mailscanner.

Wietse

Re: transport_maps not taking on

[Kai Schaetzl]

Noel Jones wrote on Wed, 7 Aug 2019 13:37:08 -0500:

> Postfix logs all delivery attempts.

I thought so, but ...
In that case it just hangs in the queue and nothing happens after the 
milter was consulted. I can see it getting logged in rspamd and then it 
just sits in the hold queue. Rescheduling it makes no difference. It 
doesn't even log it.

Kai

Re: transport_maps not taking on

[Noel Jones]

On 8/7/2019 1:11 PM, Kai Schaetzl wrote:

Kai Schaetzl wrote on Wed, 07 Aug 2019 19:11:19 +0200:


Should I remove the domain from $mydestination ?


I did that now and postfix still accepts the mail.
However, it doesn't deliver it to the remote server.
It hangs in the queue.

It's possible that the remote side is not accepting that (testing) domain
yet, but I can't verify this at the moment.
Shouldn't postfix at least show some logging that it can't deliver the
mail at the moment? I've set to -vv logging but still don't get anything
other than that mail was accepted. Flushing the queue doesn't give any
hint in the log either.



Postfix logs all delivery attempts.

Turn off the -vv debug logging; everything you need is in the normal 
logging.


If you need more help, please see:
http://www.postfix.org/DEBUG_README.html#mail



  -- Noel Jones

Re: transport_maps not taking on

[Kai Schaetzl]

Kai Schaetzl wrote on Wed, 07 Aug 2019 19:11:19 +0200:

> Should I remove the domain from $mydestination ?

I did that now and postfix still accepts the mail.
However, it doesn't deliver it to the remote server.
It hangs in the queue.

It's possible that the remote side is not accepting that (testing) domain 
yet, but I can't verify this at the moment.
Shouldn't postfix at least show some logging that it can't deliver the 
mail at the moment? I've set to -vv logging but still don't get anything 
other than that mail was accepted. Flushing the queue doesn't give any 
hint in the log either.



Kai

Re: transport_maps not taking on

[Kai Schaetzl]

Thanks for the reply, but no.
I had to, indeed, remove the domain from $mydestination to not deliver 
locally, but it's still not working correctly.

Your map configuration lines may be wrong.
I think the only thing you need is this as a destination:

/^List@List\.TLD$/mailman3:
(no [127.0.0.1]:8024 after it)
And your service runs as a socket, not on port 8024.

Kai

Re: transport_maps not taking on

[Jay Gairson]

Kai:

I think this issue might be the same as the one that I'm encountering in my
post yesterday titled, "Postfix not using LMTP Transport in map".

Can you look at your logs and see if you're getting a similar message to
what I have below?

Host postfix/lmtp[22981]: C0EEEA8: to=http://postfix.1071664.n5.nabble.com/user/SendEmail.jtp?type=node=102395=0>>,
orig_to=<[hidden email]
<http://postfix.1071664.n5.nabble.com/user/SendEmail.jtp?type=node=102395=1>>,
relay=Host.TLD[private/dovecot-lmtp], delay=566, delays=566/0.04/0.01/0.01,
dsn=5.1.1, status=bounced (host Host.com[private/dovecot-lmtp] said: 550
5.1.1 <"mailman3:[127.0.0.1]:8024"@Host.TLD> User doesn't exist:
mailman3:[127.0.0.1]:[hidden email]
<http://postfix.1071664.n5.nabble.com/user/SendEmail.jtp?type=node=102395=2>
(in
reply to RCPT TO command))

Basically Postfix is reading the map, but applying it to the "To", but not
using the relay for it at all.  Instead it refers to the
private/dovecot-lmtp in my case as the relay.

Does this match the behavior you are seeing?





On Wed, Aug 7, 2019 at 10:11 AM Kai Schaetzl 
wrote:

> Postfix 3.1.0, set up with virtual domains and users in a database via
> virtual_ directives in main.cf
> rspamd set up as a milter
> -> everything works just fine.
>
> I have one server where the client wants to get mail delivered to his
> Exchange server remotely instead. He wants to have the mail floating
> through my postfix and use the spam marking by rspamd and then get it
> delivered to his Exchange.
>
> So I:
> - commented out all virtual_ lines
> - added the domain to $mydestination
> - added this to the transport map:
>   example.com   smtp:[IP]
>   (and compiled with postmap, of course, and)
>   (transport_maps = hash:/etc/mail/transport)
>
> Unfortunately, this doesn't work. It seems that the transport map is
> either not getting consulted or that line not getting used.
> The mail gets accepted but I get this error:
> Recipient address rejected: User unknown in local recipient table
> (or: if the user exists it gets delivered locally)
>
> I know I have done this in the past when I didn't use a virtual_ setup.
> What am I missing?
> Should I remove the domain from $mydestination ?
> What do I have to set additionally so that transport is getting consulted?
>
> Thanks a lot!
>
> Kai
>
>
>

transport_maps not taking on

[Kai Schaetzl]

Postfix 3.1.0, set up with virtual domains and users in a database via 
virtual_ directives in main.cf
rspamd set up as a milter
-> everything works just fine.

I have one server where the client wants to get mail delivered to his 
Exchange server remotely instead. He wants to have the mail floating 
through my postfix and use the spam marking by rspamd and then get it 
delivered to his Exchange.

So I:
- commented out all virtual_ lines
- added the domain to $mydestination
- added this to the transport map:
  example.com   smtp:[IP]
  (and compiled with postmap, of course, and)
  (transport_maps = hash:/etc/mail/transport)

Unfortunately, this doesn't work. It seems that the transport map is 
either not getting consulted or that line not getting used.
The mail gets accepted but I get this error:
Recipient address rejected: User unknown in local recipient table
(or: if the user exists it gets delivered locally)

I know I have done this in the past when I didn't use a virtual_ setup.
What am I missing?
Should I remove the domain from $mydestination ?
What do I have to set additionally so that transport is getting consulted?

Thanks a lot!

Kai

transport_maps for autoreply

[Andrew Wood]

Im trying to configure Postifx to pass mail to a custom Python script 
which performs an out of office autoreply function.


The server has virtual mailboxes only no local unix accounts.

I have set Postfix to send mail to the script if there is an entry in 
transport_maps. If a user sets up an autoreply for their mail box an 
appropriate entry is put in transport_maps


However it appears to be impossible using this method to then have the 
Python script re-submit the message using the sendmail command for 
delivery into the mailbox. There seems to be no way of over riding an 
entry in transport_maps for a message submitted from the command line.


Bearing in mind all user specific config is in a MySQL database what is 
the recommened way of achieving this?



Thanks

Andrew

Re: both virtual_transport and transport_maps

[jor . goncalves]

Thanks Noel for the reply so I deleted  virtual_mailbox_maps = 
hash:/etc/postfix/virtual

but only transport maps is trigered not virtual map.


Thanks.

- Mail original -
De: "Noel Jones" 
À: postfix-users@postfix.org
Envoyé: Vendredi 13 Juillet 2018 23:30:19
Objet: Re: both virtual_transport and transport_maps

On 7/13/2018 4:07 PM, jor.goncal...@free.fr wrote:
> Hi folks, excuse me for my noob question
> 
>  I have installed a system with recent postfix and courier-imap(maildrop).
> 
> I found how to use transport_maps for routing message with a request over 
> ldap to obtain a mailhost to route  some emails to corresponding mailbox.
> 
> The things I wanted now  is :
> 
> for specific users I wanted to send mail to another emails:
> 
>  for exemple for f...@test.net i wanted to send to f...@test3.net.
> 
> I think using virtual map can do the trick with a file like this:
> 
> 1 /etc/postfix/main.cf:
>  2 virtual_transport = maildrop
>  3 virtual_mailbox_domains = test.net test3.net
>  4 virtual_mailbox_maps = hash:/etc/postfix/virtual
>  5 virtual_alias_maps = hash:/etc/postfix/virtual
>  6 
>  7 /etc/postfix/virtual:
>  8  f...@test.net  f...@test3.net
>  9 
> postmap /etc/postfix/virtual
> /etc/init.d/postfix reload
> 
> 
> 
> The problem is that f...@test.net is in the Ldap Table and the mail to 
> f...@test.net goes to f...@test.net always instead of f...@test3.net.
> 
> Only transport map is done never virtual map.
> 
> There is a notion of priority with the maps?
> 
> Why? Can I mix in postfix transport map and virtual maps?
> 
> If not how can I do the trick?
> 
> 
> 
> Thanks a lot for helping 
> 



Don't use the same map for virtual_mailbox_maps and
virtual_alias_maps.

Re: both virtual_transport and transport_maps

[Noel Jones]

On 7/13/2018 4:07 PM, jor.goncal...@free.fr wrote:
> Hi folks, excuse me for my noob question
> 
>  I have installed a system with recent postfix and courier-imap(maildrop).
> 
> I found how to use transport_maps for routing message with a request over 
> ldap to obtain a mailhost to route  some emails to corresponding mailbox.
> 
> The things I wanted now  is :
> 
> for specific users I wanted to send mail to another emails:
> 
>  for exemple for f...@test.net i wanted to send to f...@test3.net.
> 
> I think using virtual map can do the trick with a file like this:
> 
> 1 /etc/postfix/main.cf:
>  2 virtual_transport = maildrop
>  3 virtual_mailbox_domains = test.net test3.net
>  4 virtual_mailbox_maps = hash:/etc/postfix/virtual
>  5 virtual_alias_maps = hash:/etc/postfix/virtual
>  6 
>  7 /etc/postfix/virtual:
>  8  f...@test.net  f...@test3.net
>  9 
> postmap /etc/postfix/virtual
> /etc/init.d/postfix reload
> 
> 
> 
> The problem is that f...@test.net is in the Ldap Table and the mail to 
> f...@test.net goes to f...@test.net always instead of f...@test3.net.
> 
> Only transport map is done never virtual map.
> 
> There is a notion of priority with the maps?
> 
> Why? Can I mix in postfix transport map and virtual maps?
> 
> If not how can I do the trick?
> 
> 
> 
> Thanks a lot for helping 
> 



Don't use the same map for virtual_mailbox_maps and
virtual_alias_maps.

both virtual_transport and transport_maps

[jor . goncalves]

Hi folks, excuse me for my noob question

 I have installed a system with recent postfix and courier-imap(maildrop).

I found how to use transport_maps for routing message with a request over ldap 
to obtain a mailhost to route  some emails to corresponding mailbox.

The things I wanted now  is :

for specific users I wanted to send mail to another emails:

 for exemple for f...@test.net i wanted to send to f...@test3.net.

I think using virtual map can do the trick with a file like this:

1 /etc/postfix/main.cf:
 2 virtual_transport = maildrop
 3 virtual_mailbox_domains = test.net test3.net
 4 virtual_mailbox_maps = hash:/etc/postfix/virtual
 5 virtual_alias_maps = hash:/etc/postfix/virtual
 6 
 7 /etc/postfix/virtual:
 8  f...@test.net  f...@test3.net
 9 
postmap /etc/postfix/virtual
/etc/init.d/postfix reload



The problem is that f...@test.net is in the Ldap Table and the mail to 
f...@test.net goes to f...@test.net always instead of f...@test3.net.

Only transport map is done never virtual map.

There is a notion of priority with the maps?

Why? Can I mix in postfix transport map and virtual maps?

If not how can I do the trick?



Thanks a lot for helping 

Re: transport_maps and lookups reason

[Viktor Dukhovni]

> On May 15, 2018, at 10:00 AM, Bokhan Artem <a...@eml.ru> wrote:
> 
> Can source email (mail from) lookup be disabled when using transport_maps? 
> Any ideas? As I understand transport_maps should rely on destination address 
> when sender depended transport maps are not used.

As Wietse suggested, it would be prudent to post your configuration.

If you have any "check_sender_access" restrictions, those will trigger
a transport lookup on the sender, since transport lookup actually
resolves a resipient to (transport, nexthop, address) with the address
suitably normalized.

-- 
Viktor.

Re: transport_maps and lookups reason

[Bokhan Artem]

Thank you.


2. "source@emal"


Can source email (mail from) lookup be disabled when using 
transport_maps? Any ideas? As I understand transport_maps should rely on 
destination address when sender depended transport maps are not used.



15.05.2018 20:48, Viktor Dukhovni пишет:

2. "source@emal"
3. "destination@email"
4. "destination@email"

Especially what directives cause lookups over "mail from" address and why 
destination address is called twice?

Postfix performs the lookups it needs to perform.  We document
the configuration interface.  The exact timing and multiplicity
of the underlying lookups is an internal detail.  Postfix is
modular and some lookups are made in more than once in separate
processes.

Re: transport_maps and lookups reason

[Viktor Dukhovni]

> On May 15, 2018, at 8:01 AM, Bokhan Artem  wrote:
> 
> When sending single email these lookups are made:
> 
> 1. "*"

This is typically cached, and not queried for each and every message.

> 2. "source@emal"
> 3. "destination@email"
> 4. "destination@email"
> 
> Especially what directives cause lookups over "mail from" address and why 
> destination address is called twice?

Postfix performs the lookups it needs to perform.  We document
the configuration interface.  The exact timing and multiplicity
of the underlying lookups is an internal detail.  Postfix is
modular and some lookups are made in more than once in separate
processes.

-- 
Viktor.

Re: transport_maps and lookups reason

[Wietse Venema]

Bokhan Artem:
> Hello.
> 
> I have 'transport_maps = mysql:/etc/postfix/transport.cf' in 
> configuration and want to understand the reason of every db lookup as I 
> have some actions in mysql server based on queries count. Please explain 
> them.
> 
> When sending single email these lookups are made:
> 
> 1. "*"
> 2. "source@emal"
> 3. "destination@email"
> 4. "destination@email"
> 
> Especially what directives cause lookups over "mail from" address and 
> why destination address is called twice?
> 
> I have single mysql inclusion in configuration.
> 
> postfix 3.3.0

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.

transport_maps and lookups reason

[Bokhan Artem]

Hello.

I have 'transport_maps = mysql:/etc/postfix/transport.cf' in 
configuration and want to understand the reason of every db lookup as I 
have some actions in mysql server based on queries count. Please explain 
them.


When sending single email these lookups are made:

1. "*"
2. "source@emal"
3. "destination@email"
4. "destination@email"

Especially what directives cause lookups over "mail from" address and 
why destination address is called twice?


I have single mysql inclusion in configuration.

postfix 3.3.0

Thanks.

Re: Bounce message with transport_maps

[Luis Miguel Flores dos Santos]

Hi, anyone can help me?


De: owner-postfix-us...@postfix.org <owner-postfix-us...@postfix.org> em nome 
de luistkd4 <miguel_flores_san...@hotmail.com>
Enviado: quarta-feira, 6 de dezembro de 2017 21:30:23
Para: postfix-users@postfix.org
Assunto: Re: Bounce message with transport_maps

>>and stop accepting mail via SMTP that has an unknown sender address
(it does not block unknown senders with the Postfix 'sendmail'
command).
I Just changed the original sender to post here

>> eh? why?
Because with only a mx record our clients can recieve message in domains
created in Exchange and Smartemail enviorement the domain can exist in two.

>> this problem happens often, when you accept a mail while you don't know
>> if
you can verify it.

In this case the e-mail account was disable in exchange (my example above
was wrong like you said the error is the message size) but in my
transport_maps exist the entry to relay message to exchange server, in this
case the most correct is remove the record in memcached, right??

>>in the "before queue" case you don't need to solve anything - the message
is
not accepted, so the bounce generation is not up to you.
But in the same case above the bounce occur because the message size, but
this e-mail was delivered to sender, why?



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: Bounce message with transport_maps

[luistkd4]

>>and stop accepting mail via SMTP that has an unknown sender address 
(it does not block unknown senders with the Postfix 'sendmail' 
command). 
I Just changed the original sender to post here

>> eh? why? 
Because with only a mx record our clients can recieve message in domains
created in Exchange and Smartemail enviorement the domain can exist in two.

>> this problem happens often, when you accept a mail while you don't know
>> if 
you can verify it. 

In this case the e-mail account was disable in exchange (my example above
was wrong like you said the error is the message size) but in my
transport_maps exist the entry to relay message to exchange server, in this
case the most correct is remove the record in memcached, right??

>>in the "before queue" case you don't need to solve anything - the message
is 
not accepted, so the bounce generation is not up to you. 
But in the same case above the bounce occur because the message size, but
this e-mail was delivered to sender, why?



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: Bounce message with transport_maps

[Luis Miguel Flores dos Santos]

>>and stop accepting mail via SMTP that has an unknown sender address
(it does not block unknown senders with the Postfix 'sendmail'
command).
I Just changed the original sender to post here

>> eh? why?
Because with only a mx record our clients can recieve message in domains 
created in Exchange and Smartemail enviorement the domain can exist in two.

>> this problem happens often, when you accept a mail while you don't know if
you can verify it.

In this case the e-mail account was disable in exchange (my example above was 
wrong like you said the error is the message size) but in my transport_maps 
exist the entry to relay message to exchange server, in this case the most 
correct is remove the record in memcached, right??

>>in the "before queue" case you don't need to solve anything - the message is
not accepted, so the bounce generation is not up to you.
But in the same case above the bounce occur because the message size, but this 
e-mail was delivered to sender, why?



De: owner-postfix-us...@postfix.org <owner-postfix-us...@postfix.org> em nome 
de Luis Miguel Flores dos Santos <miguel_flores_san...@hotmail.com>
Enviado: quarta-feira, 18 de outubro de 2017 19:07:30
Para: postfix-users@postfix.org
Assunto: Bounce message with transport_maps


Hi, I have a postfix using as a mail proxy. In our environment, I use 
transport_maps(memcache).
I create in memcache a wildcard * with status bounce 500 No such user here.
When the MTA(exchange) bounce the message it returns to the same postfix and it 
checks if the recipient exists, but it's a bounce message and the sender 
sometimes doesn't exist inside the environment.

MAILLOG:

[root@SERVER01 ~]# cat /var/log/maillog | grep 39B2E3E845
Oct 18 17:09:10 SERVER01 postfix/smtpd[18476]: 39B2E3E845: 
client=mx.MYDOMAIN.com[222.222.222.222]
Oct 18 17:09:10 SERVER01 postfix/cleanup[41577]: 39B2E3E845: 
message-id=<cy4pr1601mb13365592c194b551dc564d2ac5...@cy4pr1601mb1336.namprd16.prod.outlook.com>
Oct 18 17:30:07 SERVER01 postfix/qmgr[35700]: 39B2E3E845: 
from=<miguel_flores_san...@hotmail.com>, size=44864113, nrcpt=1 (queue active)
Oct 18 17:30:07 SERVER01 postfix/smtp[43114]: 39B2E3E845: 
to=<mig...@mydomain.com>, relay=EXCHANGE[111.111.111.111]:2525, delay=1257, 
delays=1257/0.01/0.01/0, dsn=5.3.4, status=bounced (message size 44864113 
exceeds size limit 36700160 of server EXCHANGE[111.111.111.111]
Oct 18 17:30:07 SERVER01 postfix/bounce[43115]: 39B2E3E845: sender non-delivery 
notification: 5F5013E85A
Oct 18 17:30:07 SERVER01 postfix/qmgr[35700]: 39B2E3E845: removed


[root@SERVER01 ~]# cat /var/log/maillog | grep 5F5013E85A
Oct 18 17:30:07 SERVER01 postfix/cleanup[41577]: 5F5013E85A: 
message-id=<20171018193007.5f5013e...@server01.spo2.umbler.com>
Oct 18 17:30:07 SERVER01 postfix/bounce[43115]: 39B2E3E845: sender non-delivery 
notification: 5F5013E85A
Oct 18 17:30:07 SERVER01 postfix/qmgr[35700]: 5F5013E85A: from=<>, size=7622, 
nrcpt=1 (queue active)
Oct 18 17:30:07 SERVER01 postfix/error[43116]: 5F5013E85A: 
to=<miguel_flores_san...@hotmail.com>, relay=none, delay=0.03, 
delays=0/0.02/0/0, dsn=5.0.0, status=bounced (No Such User Here)
Oct 18 17:30:07 SERVER01 postfix/qmgr[35700]: 5F5013E85A: removed



Existe a way to postfix use another transport method to send bounce messages? 
or I can do it only with "before queue"?


Thanks

Re: Bounce message with transport_maps

[Matus UHLAR - fantomas]

On 18.10.17 21:07, Luis Miguel Flores dos Santos wrote:

Hi, I have a postfix using as a mail proxy. In our environment, I use
transport_maps(memcache).
I create in memcache a wildcard * with status bounce 500 No such user here.


eh? why?


When the MTA(exchange) bounce the message it returns to the same postfix
and it checks if the recipient exists, but it's a bounce message and the
sender sometimes doesn't exist inside the environment.


this problem happens often, when you accept a mail while you don't know if
you can verify it.

you probably need to set up recipient verification so you don't accept mail
for unknown recipients. look at
http://www.postfix.org/ADDRESS_VERIFICATION_README.html


Oct 18 17:30:07 SERVER01 postfix/smtp[43114]: 39B2E3E845:
to=<mig...@mydomain.com>, relay=EXCHANGE[111.111.111.111]:2525,
delay=1257, delays=1257/0.01/0.01/0, dsn=5.3.4, status=bounced (message
size 44864113 exceeds size limit 36700160 of server
EXCHANGE[111.111.111.111]


This is rejected because of message size, not unknown user.  You should
configure the same message_size_limit as your exchange server has.


[root@SERVER01 ~]# cat /var/log/maillog | grep 5F5013E85A
Oct 18 17:30:07 SERVER01 postfix/cleanup[41577]: 5F5013E85A: 
message-id=<20171018193007.5f5013e...@server01.spo2.umbler.com>
Oct 18 17:30:07 SERVER01 postfix/bounce[43115]: 39B2E3E845: sender non-delivery 
notification: 5F5013E85A
Oct 18 17:30:07 SERVER01 postfix/qmgr[35700]: 5F5013E85A: from=<>, size=7622, 
nrcpt=1 (queue active)
Oct 18 17:30:07 SERVER01 postfix/error[43116]: 5F5013E85A: 
to=<miguel_flores_san...@hotmail.com>, relay=none, delay=0.03, 
delays=0/0.02/0/0, dsn=5.0.0, status=bounced (No Such User Here)
Oct 18 17:30:07 SERVER01 postfix/qmgr[35700]: 5F5013E85A: removed

Existe a way to postfix use another transport method to send bounce messages? or I can do 
it only with "before queue"?


in the "before queue" case you don't need to solve anything - the message is
not accepted, so the bounce generation is not up to you.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of. 

Re: Bounce message with transport_maps

[Wietse Venema]

Luis Miguel Flores dos Santos:
> Existe a way to postfix use another transport method to send bounce
> messages? or I can do it only with "before queue"?

No, but you could set

/etc/postfix/main.cf:
smtpd_reject_unlisted_sender = yes

and stop accepting mail via SMTP that has an unknown sender address
(it does not block unknown senders with the Postfix 'sendmail'
command).

Wietse

Bounce message with transport_maps

[Luis Miguel Flores dos Santos]

Hi, I have a postfix using as a mail proxy. In our environment, I use 
transport_maps(memcache).
I create in memcache a wildcard * with status bounce 500 No such user here.
When the MTA(exchange) bounce the message it returns to the same postfix and it 
checks if the recipient exists, but it's a bounce message and the sender 
sometimes doesn't exist inside the environment.

MAILLOG:

[root@SERVER01 ~]# cat /var/log/maillog | grep 39B2E3E845
Oct 18 17:09:10 SERVER01 postfix/smtpd[18476]: 39B2E3E845: 
client=mx.MYDOMAIN.com[222.222.222.222]
Oct 18 17:09:10 SERVER01 postfix/cleanup[41577]: 39B2E3E845: 
message-id=<cy4pr1601mb13365592c194b551dc564d2ac5...@cy4pr1601mb1336.namprd16.prod.outlook.com>
Oct 18 17:30:07 SERVER01 postfix/qmgr[35700]: 39B2E3E845: 
from=<miguel_flores_san...@hotmail.com>, size=44864113, nrcpt=1 (queue active)
Oct 18 17:30:07 SERVER01 postfix/smtp[43114]: 39B2E3E845: 
to=<mig...@mydomain.com>, relay=EXCHANGE[111.111.111.111]:2525, delay=1257, 
delays=1257/0.01/0.01/0, dsn=5.3.4, status=bounced (message size 44864113 
exceeds size limit 36700160 of server EXCHANGE[111.111.111.111]
Oct 18 17:30:07 SERVER01 postfix/bounce[43115]: 39B2E3E845: sender non-delivery 
notification: 5F5013E85A
Oct 18 17:30:07 SERVER01 postfix/qmgr[35700]: 39B2E3E845: removed


[root@SERVER01 ~]# cat /var/log/maillog | grep 5F5013E85A
Oct 18 17:30:07 SERVER01 postfix/cleanup[41577]: 5F5013E85A: 
message-id=<20171018193007.5f5013e...@server01.spo2.umbler.com>
Oct 18 17:30:07 SERVER01 postfix/bounce[43115]: 39B2E3E845: sender non-delivery 
notification: 5F5013E85A
Oct 18 17:30:07 SERVER01 postfix/qmgr[35700]: 5F5013E85A: from=<>, size=7622, 
nrcpt=1 (queue active)
Oct 18 17:30:07 SERVER01 postfix/error[43116]: 5F5013E85A: 
to=<miguel_flores_san...@hotmail.com>, relay=none, delay=0.03, 
delays=0/0.02/0/0, dsn=5.0.0, status=bounced (No Such User Here)
Oct 18 17:30:07 SERVER01 postfix/qmgr[35700]: 5F5013E85A: removed



Existe a way to postfix use another transport method to send bounce messages? 
or I can do it only with "before queue"?


Thanks

Re: transport_maps

[Viktor Dukhovni]

> On May 4, 2017, at 8:31 AM, volodymyr.lytvyne...@ukrsotsbank.com wrote:
> 
> transport_maps = pipemap:{
>   inline:{unicredit.ua=x, ukrsotsbank.com=x},
>   randmap:{smtp:[mx1.ukrsotsbank.com], smtp:[mx2.ukrsotsbank.com]}
>}
> 
> How can I add another domain to the another randmap destinations ?

The transport_maps parameter takes a list of tables, so you could append
another pipemap to the list that handles the additional domain that uses
a different list of smtp nexthop values.  However, I think this is a fairly
clumsy way of doing MX load-balancing.  Instead I would:

  * Run a local DNS resolver on the MTA listening for requests on the loopback
address (127.0.0.1) and configured with an local data for the
"localhost" TLD (https://tools.ietf.org/html/rfc2606#section-2)

  * Configure /etc/resolv.conf to use only the local (127.0.0.1) resolver.

  * Configure the resolver (BIND syntax) to serve:

unicredit.ua.localhost. IN MX 0 mx1.ukrsotsbank.com.
unicredit.ua.localhost. IN MX 0 mx2.ukrsotsbank.com.
;
ukrsotsbank.com.localhost. IN MX 0 mx1.ukrsotsbank.com.
ukrsotsbank.com.localhost. IN MX 0 mx2.ukrsotsbank.com.
;
# More domains with arbitrary custom MX hosts

  * Configure a regular file-based transport table as follows:

  transport:
# RHS values without [] around an smtp nexthop do MX lookups
unicredit.uasmtp:unicredit.ua.localhost
ukrsotsbank.com smtp:ukrsotsbank.com.localhost
...

Don't forget to postmap the table after it changes and set:

main.cf:
indexed = ${default_database_type}:${config_directory}/
transport_maps = ${indexed}transport

-- 
Viktor.

transport_maps

[volodymyr.lytvyne...@ukrsotsbank.com]

Hi.  I have next transport_maps in main.cf:
/etc/postfix/main.cf:
transport_maps = pipemap:{
inline:{unicredit.ua=x, ukrsotsbank.com=x},
randmap:{smtp:[mx1.ukrsotsbank.com], smtp:[mx2.ukrsotsbank.com]}
}

How can I add another domain to the another randmap destinations ?


Best regards,
Vladimir Litvinenko

SSO Delivery Technical Support Specialist "IT Innovations Ukraine" Ltd.

Re: sender based routing and transport_maps

[Wietse Venema]

Andrea Cappelli:
> What I want to accomplish is the following
> 
> 1) if sender is @domain1.com relay via smtp:[relay.domain1.com]
> 
> 2) otherwise round robin delivery from one of my IP via smtp (services
> configured in master.cf with differente ehlo and bound to different IP)
> (found on stack overflow, but now I can't retrieve the post)

Then don't use transport_maps.

Wietser

> I tried as follows
> 
> sender_dependent_default_transport_maps = hash:/etc/postfix/sender_relay,
> mysql:/etc/postfix/transport_roundrobin.cf

With Postfix 3.x, try:

sender_dependent_default_transport_maps =
hash:/etc/postfix/sender_relay
randmap:{one,two,three}

where one, two and three are transport:host (or transport:) that
should be used for non-matching senders.

sender_dependent_reelayhost_maps are an alternative, sinmce you
don't really need to override the transport, only the relayhost.

Wietse

Re: sender based routing and transport_maps

[Andrea Cappelli]

Il 21 ago 2016 1:20 AM, "Wietse Venema" <wie...@porcupine.org> ha scritto:
> $ man 5 postconf | less '+/sender_dependent_default_transport_maps'
> ...
> This information is overruled with the transport(5) table.
> ...
>
> transport_maps has precedence over sender_dependent_default_transport_maps
> because transport_maps also has precedence over default_transport.
>

Thanks you Wietse for the clarification

> If you use sender-dependent routing, you can't use transport_maps.
> You can still use default_transport, relay_transport, local_transport
> and virtual_transport, for routing domains.

What I want to accomplish is the following

1) if sender is @domain1.com relay via smtp:[relay.domain1.com]

2) otherwise round robin delivery from one of my IP via smtp (services
configured in master.cf with differente ehlo and bound to different IP)
(found on stack overflow, but now I can't retrieve the post)

I tried as follows

sender_dependent_default_transport_maps = hash:/etc/postfix/sender_relay,
mysql:/etc/postfix/transport_roundrobin.cf

sender_relay

@domain1.comsmtp:[relay.domain1.com]:587 # (tried with and without
leading smtp)

transport_roundrobin.cf

query = SELECT transport from transport_roundrobin ORDER BY RAND() LIMIT 1

transport_roundrobin is a mysql table with a single column containing
service name as defined in master.cf (out1, out2, out3)

I think that when the sender is f...@domain1.com the hashmap should apply
and thus no query to mysql had to be performed, but the query is always
performed and the th delivery is chosen from the one's defined inside the
table

If I remove the mysql part (sender_dependent_default_transport_maps =
hash:/etc/postfix/sender_relay) mail from u...@domain1.com get relayed
correctly, other mail go to default smtp

Is my goal achievable and I'm worng at the configuration?

It's a bad idea?

Thanks
Andrea

Re: sender based routing and transport_maps

[Wietse Venema]

Andrea Cappelli:
> 2016-08-20 23:40 GMT+02:00 Andrea Cappelli <a.cappe...@gmail.com>:
> 
> > Hi All,
> > I have a postfix 2.9.6 setup on Ubuntu 12.04 which serve a bounch of local
> > mailbox and act as mail gateway with a tcp transport
> >
> > I want to use some external authenticated MTA based on sendere domain, so
> 
> Ok, I think I found my problem, my TCP service is called each time and
> always return a nexthop, so the sender based mechanism in postfix is never
> in action
> 
> Can someone please exaplain the order of lookup in transport(5)

$ man 5 postconf | less '+/sender_dependent_default_transport_maps'
...
This information is overruled with the transport(5) table.
...

transport_maps has precedence over sender_dependent_default_transport_maps
because transport_maps also has precedence over default_transport.

If you use sender-dependent routing, you can't use transport_maps.
You can still use default_transport, relay_transport, local_transport
and virtual_transport, for routing domains.

Wietse

Re: sender based routing and transport_maps

[Andrea Cappelli]

2016-08-20 23:40 GMT+02:00 Andrea Cappelli <a.cappe...@gmail.com>:

> Hi All,
> I have a postfix 2.9.6 setup on Ubuntu 12.04 which serve a bounch of local
> mailbox and act as mail gateway with a tcp transport
>
> I want to use some external authenticated MTA based on sendere domain, so
>

Ok, I think I found my problem, my TCP service is called each time and
always return a nexthop, so the sender based mechanism in postfix is never
in action

Can someone please exaplain the order of lookup in transport(5)

>From which I understood local_transport, virtual_transport and
relay_transport are checked (if the domain is configured in the appropriate
table or in mydestination for local), if no match is found the
default_transport apply

The lookup is done for the sender and for the recipient, right?

At which point lookups in transport_maps are applied?

Thank you

-- 
Andrea Cappelli

sender based routing and transport_maps

[Andrea Cappelli]

Hi All,
I have a postfix 2.9.6 setup on Ubuntu 12.04 which serve a bounch of local
mailbox and act as mail gateway with a tcp transport

I want to use some external authenticated MTA based on sendere domain, so

1) domain1.com goes to MTA1
2) domain2 goes to MTA2
3) any other domain goes to tcp transport

for TCP transport I used transport_maps but this way the sender based
mechanism didn't work (works weel without transport_maps)

I read http://www.postfix.org/transport.5.html but I didn't understand when
transport_maps enter in action , I suppose before default_transport and for
target domains that didn't match local_transport, virtual_transport and
relay_transport; it's that true?

In which order these transport are evaluated?

Can someone point me to some example or hint?

Following the output of postconf -n


alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 2h
bounce_template_file = /etc/postfix/bounce.cf
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = amavis:[127.0.0.1]:10024
dovecot_destination_recipient_limit = 1
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
mailman_destination_recipient_limit = 1
maximal_queue_lifetime = 2d
message_size_limit = 36700160
myhostname = sierra.cgnlab.net
mynetworks = 127.0.0.0/8 [::1]/128
myorigin = $myhostname
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
readme_directory = no
receive_override_options = no_address_mappings
recipient_delimiter = +
relay_domains = proxy:mysql:/etc/postfix/virtual/relay_domains.cf
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_relay
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
smtp_sasl_security_options =
smtp_sender_dependent_authentication = yes
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_error_sleep_time = 60
smtpd_hard_error_limit = 10
smtpd_recipient_restrictions = permit_mynetworks,
reject_non_fqdn_recipient, permit_sasl_authenticated,
reject_unlisted_recipient, reject_unknown_recipient_domain,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/dovecot-auth
smtpd_sasl_type = dovecot
smtpd_soft_error_limit = 60
smtpd_tls_cert_file = /etc/ssl/private/mail.asidev.com.chain.crt
smtpd_tls_key_file = /etc/ssl/private/mail.asidev.com.key
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = proxy:mysql:/etc/postfix/virtual/transport.cf
tcp:[127.0.0.1]:2527
virtual_alias_maps = proxy:mysql:/etc/postfix/virtual/forwarding.cf,
proxy:mysql:/etc/postfix/virtual/mailbox.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/vmail
virtual_mailbox_domains = proxy:mysql:/etc/postfix/virtual/domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/virtual/forwarding.cf,
proxy:mysql:/etc/postfix/virtual/mailbox.cf
virtual_transport = dovecot
virtual_uid_maps = static:5000

Thank you

-- 
Andrea Cappelli