Re: Transport maps - lookups happen for recipient but also for sender (which is not necessary)

[Wietse Venema]

liquid cooled:
> Thanks for the quick response,
> 
> 2) $ postconf -n | grep ldap
> transport_maps = hash:/etc/postfix/lookup/transport, ldap:/etc/postfix/
> mailtransport.cf

In that case, Postfix will always want to look up user@domain,
domain, and parent domains, because that is how transport maps are
intended to be used.

BTW ldap (and sql) tables have high lookup latencies, best to avoid
those, or configure them as a Postfix memcache backend.

> The thing is I do not have my local domains defined anywhere... basically
> if I point an MX to this mailserver and create an LDAP entry containing a
> valid mail address I will be able to receive mail for that domain.
> Maybe this is the problem here?

To configure Postfix for receiving email, please see
https://www.postfx.org/ADDRESS_CLASS_README.html

For basic UNIX-style system accounts:
https://www.postfix.org/BASIC_CONFIGURATION_README.html

Wietse

Re: Transport maps - lookups happen for recipient but also for sender (which is not necessary)

[liquid cooled]

I got it now found the "domain" setting in
https://www.postfix.org/ldap_table.5.html

Thanks you very much Wietse! And thanks for your time!

Am Fr., 3. März 2023 um 15:44 Uhr schrieb liquid cooled :

> Thanks for the quick response,
>
> 2) $ postconf -n | grep ldap
> transport_maps = hash:/etc/postfix/lookup/transport, ldap:/etc/postfix/
> mailtransport.cf
>
> 1) by "those domains" you are talking about the sender domains? Because
> these domains are unknown to my mailsystem as these are mails from external
> mailservers.
> If you mean my own local domains do you think i should add to the ldap
> query something like this? "query_filter =
> (&(|(mail=%s)(mailalternateaddress=%s)(domain=%d))"
> The thing is I do not have my local domains defined anywhere... basically
> if I point an MX to this mailserver and create an LDAP entry containing a
> valid mail address I will be able to receive mail for that domain.
> Maybe this is the problem here?
>
> Am Fr., 3. März 2023 um 14:04 Uhr schrieb Wietse Venema <
> wie...@porcupine.org>:
>
>> liquid cooled:
>> >  Hello,
>> >
>> > I found out that my postfix does a lot of useless (LDAP) requests (in my
>> > opinion) when transport maps are enabled and in place.
>> > I use transport maps to map incoming mails to different destination
>> hosts,
>> > based on destination mail address.
>> > So there should be no lookup at all for sender address or local or
>> domain
>> > part.
>>
>> 1) Add a "domain = " setting to look up only complete email
>> addresses in those domains.
>>
>> 2) You forgot to show parameter settings (output from the command
>> "postconf -n | grep ldap") that shows WHAT Postfix is using the
>> table for.
>>
>> Wietse
>>
>

Re: Transport maps - lookups happen for recipient but also for sender (which is not necessary)

[liquid cooled]

Thanks for the quick response,

2) $ postconf -n | grep ldap
transport_maps = hash:/etc/postfix/lookup/transport, ldap:/etc/postfix/
mailtransport.cf

1) by "those domains" you are talking about the sender domains? Because
these domains are unknown to my mailsystem as these are mails from external
mailservers.
If you mean my own local domains do you think i should add to the ldap
query something like this? "query_filter =
(&(|(mail=%s)(mailalternateaddress=%s)(domain=%d))"
The thing is I do not have my local domains defined anywhere... basically
if I point an MX to this mailserver and create an LDAP entry containing a
valid mail address I will be able to receive mail for that domain.
Maybe this is the problem here?

Am Fr., 3. März 2023 um 14:04 Uhr schrieb Wietse Venema <
wie...@porcupine.org>:

> liquid cooled:
> >  Hello,
> >
> > I found out that my postfix does a lot of useless (LDAP) requests (in my
> > opinion) when transport maps are enabled and in place.
> > I use transport maps to map incoming mails to different destination
> hosts,
> > based on destination mail address.
> > So there should be no lookup at all for sender address or local or domain
> > part.
>
> 1) Add a "domain = " setting to look up only complete email
> addresses in those domains.
>
> 2) You forgot to show parameter settings (output from the command
> "postconf -n | grep ldap") that shows WHAT Postfix is using the
> table for.
>
> Wietse
>

Re: Transport maps - lookups happen for recipient but also for sender (which is not necessary)

[Wietse Venema]

liquid cooled:
>  Hello,
> 
> I found out that my postfix does a lot of useless (LDAP) requests (in my
> opinion) when transport maps are enabled and in place.
> I use transport maps to map incoming mails to different destination hosts,
> based on destination mail address.
> So there should be no lookup at all for sender address or local or domain
> part.

1) Add a "domain = " setting to look up only complete email
addresses in those domains.

2) You forgot to show parameter settings (output from the command
"postconf -n | grep ldap") that shows WHAT Postfix is using the
table for.

Wietse

Re: Transport maps

[David Koski]

Hello Viktor,

Indeed, your are right again.  I had '%d' in a complex query, changed it 
to '%s' and extracted the substring for the domain.  That did it!  There 
are three select statements in a UNION with the others referencing '%s' 
already.  Too bad there wasn't a switch to make it so '%d' does not 
ignore the whole query on keys like jo...@example.com.


Regards,
David Koski
dko...@sutinen.com

On 3/18/21 5:44 PM, Viktor Dukhovni wrote:

On Thu, Mar 18, 2021 at 05:17:58PM -0700, David Koski wrote:


Postfix is only mapping email addresses and not FQDNs.  Mapping works
for u...@mydomain.com but not 
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmydomain.com&c=E,1,1ufclNlqUwmXD2VK-YrvNGm5q9-QZfGaDfYeiXewkcnlYLErUpSVnoD1mlQN9g_-f3MNe9oMTTYPvxgjvkpOoUHWsL5OtRxhOWh0FgOU1wA,&typo=1,
 
.https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmydomain.com&c=E,1,eCFYsEaku7fqVeX1R6e9MnlMMC9eHyvOeK3CWcrqTZxNRzEeb4vu6Hpkcoh_NYq4pFSoSZizgoThehS24tqBQQ6pQrTPGeVBCAI8YB6vWPEn1w,,&typo=1
 or @mydomain.com.

# postmap -q localhost 
mysql:/etc/postfix/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmysql_transport_maps.cf&c=E,1,qvgEVzjJgncA7i6QmGsTvdQVZ4CnpydYP4R4YizA1FTBDJgQNdvd5cfWxvYzsG_bAYJqyNywwRmVi8tIeIJ-Ves1-YLNATWgy-fcYFwcoPZVDaY,&typo=1

# postmap -q list2@localhost 
mysql:/etc/postfix/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmysql_transport_maps.cf&c=E,1,hC7iKQadbai4p80je8keLWfcmjyGR1yZ9NMG_C7vbRYHyLhq3gpa0q8IycNvJMPCKyzcHdv27eEQ3tNdXkLRPYtnT6uMhxl9SZ_E_dEVTMYpnvKz&typo=1
mailman:

Your definition of the MySQL table in 
"/etc/postfix/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fmysql_transport_maps.cf&c=E,1,tk4mCXXxVaoFdFzBBz-FPo6vlUpgW_OUENX4vC6CeH2U6aUov5sJaG0mFRuliQkYNcA51GVqfirrbedg12b55MinLgrKqz1REXGMjqqXaT3G8w,,&typo=1";
is such that only user@domain keys are matched.

Re: Transport maps

[Viktor Dukhovni]

On Thu, Mar 18, 2021 at 05:17:58PM -0700, David Koski wrote:

> Postfix is only mapping email addresses and not FQDNs.  Mapping works 
> for u...@mydomain.com but not mydomain.com, .mydomain.com or @mydomain.com.
> 
> # postmap -q localhost mysql:/etc/postfix/mysql_transport_maps.cf
>
> # postmap -q list2@localhost mysql:/etc/postfix/mysql_transport_maps.cf
> mailman:

Your definition of the MySQL table in "/etc/postfix/mysql_transport_maps.cf"
is such that only user@domain keys are matched.

-- 
Viktor.

Re: transport maps lookup order

[Wietse Venema]

Lists Nethead:
> 
> postfix-3.2.2
> 
> Case in question:
> 
> transport_maps = hash:/usr/local/etc/postfix/transport,  
> ldap:/usr/local/etc/postfix/ldap-transport.cf
> 
> I had the (possibly erroneous) belief that Postfix searches the tables  
> in the order given in main.cf and that the domain part is sufficient.
> What we wanted to accomplish is, in the hash table which is the first  
> entry above
> 
> example.com   smtp:[a.host.somwhere]

It searches both tables for u...@example.com (email address) in the
order given in main.cf, then it searches both tables for example.com
(domain only) in the order given in main.cf.

> So the question is, how can we set up the transport maps in a hash  
> file so that all mail for users in the example.com domain gets sent to  
> smtp:[a.host.somwhere] instead of the default entry which is below in  
> the hash file.

Here is a trick to make the u...@example.com match the first table:

transport_maps = 
pcre:/usr/local/etc/postfix/transport.pcre
ldap:/usr/local/etc/postfix/ldap-transport.cf

/usr/local/etc/postfix/transport.pcre
/@example\.com$/ smtp:[a.host.somwhere]

With this, Postfix will not send the 'domain only' queries to the
PCRE table, but it would still send them to the LDAP table.

Wietse

Re: Transport Maps Clarification/Debugging

[Wietse Venema]

Adam Tauno Williams:
> I have a Postfix server which receives mail for EXAMPLE.COM  
> (bogasified); for for specific addresses I need to send that mail to  
> another SMTP server.  So transform_maps!
> 
> I have "transport_maps = hash://map-path" and If I "postmap -q  
> u...@example.com hash://map-path" it returns "smtp:[other.smtp.server]".
> 
> However when I send a message through the server ... it is still  
> delivered using the local transport.
> 
> I have cranked up the debugging level for the host I am sending the  
> test from.  I see in the log:
> 
> ...
> postfix/smtpd[22474]: rewrite_clnt: local: a...@example.com-> a...@example.com

First, adam != USER

Second, rewrite_clnt calls a service that does not use transport_maps.
Only resolve_clnt does that.

Wietse

Re: Transport maps and rate limiting

[Wietse Venema]

Alex Regan:
> Hi,
> 
> I have a fedora20 server with postfix-2.10.5 I'm trying to configure 
> rate limiting for outbound mail to google, yahoo, etc, in hopes of not 
> only building a better reputation with these systems, but also to 
> prevent my outbound pipe from being saturated.
> 
> I've configured a few of the rate_delay parameters according to the 
> instructions here:
> 
> http://steam.io/2013/04/01/postfix-rate-limiting/
> 
> It includes building two new transports in master.cf
> 
> polite unix - - n - - smtp
> turtle unix - - n - - smtp
> 
> And in /etc/postfix/transport
> 
> gmail.com polite:
> yahoo.com turtle:
> hotmail.com polite:
> 
> In main.cf I've configured:
> 
> transport_maps = hash:/etc/postfix/transport
> polite_destination_concurrency_limit = 10
> polite_destination_rate_delay = 0
> polite_destination_recipient_limit = 5
> turtle_destination_concurrency_limit = 5
> turtle_destination_rate_delay = 3s
> turtle_destination_recipient_limit = 2

As documented,

1) A non-zero rate delay forces a concurrency of 1.  If
you want to trickle email, sending it in parallel makes little
sense.
http://www.postfix.org/postconf.5.html#default_destination_rate_delay

2) If you change the destination_recipient_limit to 1, then you
will regret it (the rate changes from per-domain into per-recipient
which you probably do not want).
http://www.postfix.org/postconf.5.html#default_destination_rate_delay

> I believe the problem is that messages not destined for gmail, yahoo, or 
> hotmail no longer have a path, correct?

As documented in the transports(5) manpage this table is optional.
http://www.postfix.org/transports.5.html

If nothing matches the table, Postfix uses the "default_transport"
setting.  http://www.postfix.org/postconf.5.html#default_transport

> Feb 14 19:26:31 mail01 postfix/trivial-rewrite[16804]: warning: 
> transport_maps lookup failure

You have an error in the file. Did you run the command "postmap
hash:/etc/postfix/transport"?

Wietse

Re: Transport maps in MySQL

[Noel Jones]

On 3/7/2013 2:17 PM, Alfredo Saldanha wrote:
>> The transport table is a critical table used by pretty much every
>>part of postfix (by way of the trivial_rewrite service).  If the
>>mysql database is unavailable, no mail will flow.  If the lookups
>>are slow, all postfix performance will suffer.
> 
> In case of mysql connection drop, Postfix doesn't use the last
> transport information ?
> And another stuffs that use MySQL, like virtual aliases, users, etc.
> the message will be rejected ?


If the transport table is unavailable, no mail will flow -- incoming
mail will be deferred, mail in the queue will be temp-failed.  There
is no cache[1].

The transport table is particularly performance sensitive because
it's used by the single-threaded trivial_rewrite service, which is
referenced by every part of postfix.  For a
high-volume/high-performance server, it is recommended that
transport tables use a local hash:, or better, cdb: file.  This
doesn't mean you can't use mysql, but it will require some care to
insure availability and performance.

As a general rule, when postfix references ANY table (not just
mysql), if that table is unavailable an error will be issued and
mail will be deferred until the table is again working.  But not all
tables are used by all postfix functions, and not all tables have
the same impact on performance as transport.


[1] there is a 1-element result cache to prevent postfix from
looking up the same key repeatedly.  This will not prevent table
errors, nor is it intended to.




  -- Noel Jones

Re: Transport maps in MySQL

[Alfredo Saldanha]

Sorry, this was my email client.

Thank you for answers.

- Mensagem original - 
De: "Reindl Harald"  
Para: postfix-users@postfix.org 
Enviadas: Quinta-feira, 7 de Março de 2013 17:22:36 
Assunto: Re: Transport maps in MySQL 

DO NOT POST HTML-MESSAGES 

Am 07.03.2013 21:17, schrieb Alfredo Saldanha: 
> In line... 
> On 3/7/2013 1:37 PM, Alfredo Saldanha wrote: 
>>> Hi people, 
>>> 
>>> Simple question: 
>>> 
>>> Is safe use mysql to get the transport maps information? if the 
>>> connection with database drops ? is there cache? 
>>> 
>>> BR, 
>>> 
>>> Junix 
>>> 
> 
>> The transport table is a critical table used by pretty much every 
>>part of postfix (by way of the trivial_rewrite service). If the 
>>mysql database is unavailable, no mail will flow. If the lookups 
>>are slow, all postfix performance will suffer. 
> 
> In case of mysql connection drop, Postfix doesn't use the last transport 
> information ? 
> And another stuffs that use MySQL, like virtual aliases, users, etc. the 
> message will be rejected ? 
> 
>>While it is certainly possible to successfully use mysql with 
>>transport, it will require some care and feeding -- especially for a 
>>high-volume server. 
> 
> OK. 
> 
>>Transport tables don't usually change frequently, and it's better to 
>>keep that information in a local hash: or cdb: table for both 
>>performance and availability. If you want to keep everything in 
>>mysql, consider creating a process to periodically dump the data to 
>>a local hash: or cdb: table. 

in short: if you use mysql for your config your mysqld MUST NOT 
be unreachable, ever at all, if your setup is OK this will never 
happen - i am saying this after 5 years dbmail where ANYTHING 
is in a innodb-database, not only postfix-config 

never ever shutdown mysql alone, make sure you always stop any 
mail-service before, make sure any mailservice is stopped before 
mysqld at reboot/shutdown, make sure your mysqld is high available 
with replication and you are fine

Re: Transport maps in MySQL

[Reindl Harald]

DO NOT POST HTML-MESSAGES

Am 07.03.2013 21:17, schrieb Alfredo Saldanha:
> In line...
> On 3/7/2013 1:37 PM, Alfredo Saldanha wrote:
>>> Hi people,
>>>
>>> Simple question:
>>>
>>> Is safe use mysql to get the transport maps information? if the
>>> connection with database drops ? is there cache?
>>>
>>> BR,
>>>
>>> Junix
>>> 
> 
>> The transport table is a critical table used by pretty much every
>>part of postfix (by way of the trivial_rewrite service).  If the
>>mysql database is unavailable, no mail will flow.  If the lookups
>>are slow, all postfix performance will suffer.
> 
> In case of mysql connection drop, Postfix doesn't use the last transport 
> information ?
> And another stuffs that use MySQL, like virtual aliases, users, etc. the 
> message will be rejected ?
> 
>>While it is certainly possible to successfully use mysql with
>>transport, it will require some care and feeding -- especially for a
>>high-volume server.
> 
> OK.
> 
>>Transport tables don't usually change frequently, and it's better to
>>keep that information in a local hash: or cdb: table for both
>>performance and availability.  If you want to keep everything in
>>mysql, consider creating a process to periodically dump the data to
>>a local hash: or cdb: table.

in short: if you use mysql for your config your mysqld MUST NOT
be unreachable, ever at all, if your setup is OK this will never
happen - i am saying this after 5 years dbmail where ANYTHING
is in a innodb-database, not only postfix-config

never ever shutdown mysql alone, make sure you always stop any
mail-service before, make sure any mailservice is stopped before
mysqld at reboot/shutdown, make sure your mysqld is high available
with replication and you are fine



signature.asc
Description: OpenPGP digital signature

Re: Transport maps in MySQL

[Alfredo Saldanha]

In line... 

De: "Noel Jones"  
Para: postfix-users@postfix.org 
Enviadas: Quinta-feira, 7 de Março de 2013 17:01:45 
Assunto: Re: Transport maps in MySQL 

On 3/7/2013 1:37 PM, Alfredo Saldanha wrote: 
>> Hi people, 
>> 
>> Simple question: 
>> 
>> Is safe use mysql to get the transport maps information? if the 
>> connection with database drops ? is there cache? 
>> 
>> BR, 
>> 
>> Junix 
>> 

> The transport table is a critical table used by pretty much every 
>part of postfix (by way of the trivial_rewrite service). If the 
>mysql database is unavailable, no mail will flow. If the lookups 
>are slow, all postfix performance will suffer. 

In case of mysql connection drop, Postfix doesn't use the last transport 
information ? 
And another stuffs that use MySQL, like virtual aliases, users, etc. the 
message will be rejected ? 

>While it is certainly possible to successfully use mysql with 
>transport, it will require some care and feeding -- especially for a 
>high-volume server. 

OK. 

>Transport tables don't usually change frequently, and it's better to 
>keep that information in a local hash: or cdb: table for both 
>performance and availability. If you want to keep everything in 
>mysql, consider creating a process to periodically dump the data to 
>a local hash: or cdb: table. 

Thank you Noel. 

-- Noel Jones 

Re: Transport maps in MySQL

[Reindl Harald]

Am 07.03.2013 21:01, schrieb Noel Jones:
> On 3/7/2013 1:37 PM, Alfredo Saldanha wrote:
>> Hi people,
>>
>> Simple question:
>>
>> Is safe use mysql to get the transport maps information? if the
>> connection with database drops ? is there cache?
>>
>> BR,
>>
>> Junix
>> 
> 
> The transport table is a critical table used by pretty much every
> part of postfix (by way of the trivial_rewrite service).  If the
> mysql database is unavailable, no mail will flow.  If the lookups
> are slow, all postfix performance will suffer.
> 
> While it is certainly possible to successfully use mysql with
> transport, it will require some care and feeding -- especially for a
> high-volume server

it is not a problem if you have TWO mysqld-hosts with
replication because all of this lookups are read-only
and you can easily configure postfix to use both servers

hosts = unix:/var/lib/mysql/mysql.sock inet:ip-of-mysql-slave




signature.asc
Description: OpenPGP digital signature

Re: Transport maps in MySQL

[Noel Jones]

On 3/7/2013 1:37 PM, Alfredo Saldanha wrote:
> Hi people,
> 
> Simple question:
> 
> Is safe use mysql to get the transport maps information? if the
> connection with database drops ? is there cache?
> 
> BR,
> 
> Junix
> 

The transport table is a critical table used by pretty much every
part of postfix (by way of the trivial_rewrite service).  If the
mysql database is unavailable, no mail will flow.  If the lookups
are slow, all postfix performance will suffer.

While it is certainly possible to successfully use mysql with
transport, it will require some care and feeding -- especially for a
high-volume server.

Transport tables don't usually change frequently, and it's better to
keep that information in a local hash: or cdb: table for both
performance and availability.  If you want to keep everything in
mysql, consider creating a process to periodically dump the data to
a local hash: or cdb: table.



  -- Noel Jones

Re: Transport Maps and TCP Table -> How to realize that postfix queries for recipient AND sender ?

[post...@netorbit.it]

On 15/08/2012 22:14, Noel Jones wrote:

On 8/15/2012 1:28 PM, Harakiri wrote:

Is there an alternative way to have a custom TCP service answer to postfix 
requests to where a mail should be relayed too - when postfix supplies all the 
transport information (sender,recipient, sending IP) ? Postfix already has nice 
table lookup and policy services - i dont see a reason why something like this 
couldnt be part of postfix lookup mechanism.

[...]

Maybe if you explain why you need this highly unusual routing an
alternate solution can be found.


Hi,
sorry for sneaking in the thread. I was looking for something similar too.
For example in my case I use the transport maps via TCP lookup to 
retrieve in round robin fashion (given by a script listening the GET 
) between available outgoing "transport" lines.


I'd like to expand the simple round robin to something which would e.g 
take in account the size of the outgoing message in order to choose the 
best outgoing transport.
Big messages could be given the best upload bandwidth transport, which 
smaller ones can be distributed  to any.


Thanks

Angelo

Re: Transport Maps and TCP Table -> How to realize that postfix queries for recipient AND sender ?

[Noel Jones]

On 8/15/2012 1:28 PM, Harakiri wrote:
> 
> Is there an alternative way to have a custom TCP service answer to postfix 
> requests to where a mail should be relayed too - when postfix supplies all 
> the transport information (sender,recipient, sending IP) ? Postfix already 
> has nice table lookup and policy services - i dont see a reason why something 
> like this couldnt be part of postfix lookup mechanism.
> 

recipient transport decisions are documented here:
http://www.postfix.org/transport.5.html

There are additionally some sender-dependent mechanisms:
http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps

You'll notice that none of these mechanisms use more than one key.
If your highly unusual mail routing depends on multiple keys,
postfix may not be the best MTA choice for you.

Maybe if you explain why you need this highly unusual routing an
alternate solution can be found.


  -- Noel Jones

Re: Transport Maps and TCP Table -> How to realize that postfix queries for recipient AND sender ?

[Harakiri]

--- On Wed, 8/15/12, Noel Jones  wrote:

> From: Noel Jones 
> Subject: Re: Transport Maps and TCP Table -> How to realize that postfix 
> queries for recipient AND sender ?
> To: postfix-users@postfix.org
> Date: Wednesday, August 15, 2012, 12:26 PM
> On 8/15/2012 10:53 AM, Harakiri
> wrote:
> > Ive implemented a TCP table which will tell postfix
> which destination IP should be used for internal relay.
> > 
> > A TCP Table lookup only works with GET
> 
> 
> Correct.  The lookup key for transport_maps is the
> recipient address
> regardless of table type.
> 
> 
> > - is it somehow possible to have all the information
> provided similar to the check_policy_service ?
> 
> No. The use-case for transport_maps and
> smtpd_*_restrictions
> check_policy_service is very different.

Is there an alternative way to have a custom TCP service answer to postfix 
requests to where a mail should be relayed too - when postfix supplies all the 
transport information (sender,recipient, sending IP) ? Postfix already has nice 
table lookup and policy services - i dont see a reason why something like this 
couldnt be part of postfix lookup mechanism.

Re: Transport Maps and TCP Table -> How to realize that postfix queries for recipient AND sender ?

[Noel Jones]

On 8/15/2012 10:53 AM, Harakiri wrote:
> Ive implemented a TCP table which will tell postfix which destination IP 
> should be used for internal relay.
> 
> A TCP Table lookup only works with GET 

Correct.  The lookup key for transport_maps is the recipient address
regardless of table type.


> - is it somehow possible to have all the information provided similar to the 
> check_policy_service ?

No. The use-case for transport_maps and smtpd_*_restrictions
check_policy_service is very different.




  -- Noel Jones

Re: Transport Maps

[post...@netorbit.it]

On 22/06/2012 11:31, Ralf Hildebrandt wrote:

* post...@netorbit.it :

Hi,

Postfix 2.7.1 box.
done some extra test, with same setup and encountered different
behavior between

1) transport_maps = hash:/etc/postfix/transport, tcp:[127.0.0.1]:

and

2) transport_maps = hash:/etc/postfix/transport  alone

when trying to send an email to the netorbit.it domain, which is mapped to

netorbitsmtp:fax.netorbit.it(which, btw, is a wrong address by 
choice)

It's not mappend, since "netorbit" doesn't match "netorbit.it"
It's just a typo, since I didn't do a copy & paste while writing the 
post here but rewritten by hand.

Actually is netorbit.it  : and happens exactly as described.



--
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com/links/en/frams.html

Re: Transport Maps

[Ralf Hildebrandt]

* post...@netorbit.it :
> Hi,
> 
> Postfix 2.7.1 box.
> done some extra test, with same setup and encountered different
> behavior between
> 
> 1) transport_maps = hash:/etc/postfix/transport, tcp:[127.0.0.1]:
> 
> and
> 
> 2) transport_maps = hash:/etc/postfix/transport  alone
> 
> when trying to send an email to the netorbit.it domain, which is mapped to
> 
> netorbitsmtp:fax.netorbit.it(which, btw, is a wrong address 
> by choice)

It's not mappend, since "netorbit" doesn't match "netorbit.it"

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Transport Maps

[post...@netorbit.it]

Hi,

Postfix 2.7.1 box.
done some extra test, with same setup and encountered different behavior 
between


1) transport_maps = hash:/etc/postfix/transport, tcp:[127.0.0.1]:

and

2) transport_maps = hash:/etc/postfix/transport  alone

when trying to send an email to the netorbit.it domain, which is mapped to

netorbitsmtp:fax.netorbit.it(which, btw, is a wrong 
address by choice)



Well, when sending email to post...@netorbit.it with:

*Setup 1)*
destination email address post...@netorbit.it *doesn't match the hash 
table*, query is forwarded to the tcp table.

The latter always answer with a random transport.

*Setup 2) *
email to post...@netorbit.it doesn't get a direct match, *but actually 
matches the netorbit.it domain*, since I see in logs attempts to forward 
email to the 'wrong-by-choice' mail relay "fax.netorbit.it".


(O'course I made sure the hash table was compiled by postmap and before 
every attempt I've restarted Postfix)





-- 
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com/links/en/frams.html

Re: Transport Maps

[post...@netorbit.it]

On 21/06/2012 16:25, Wietse Venema wrote:

post...@netorbit.it:

Hi,

just a quick question regarding transport_maps.

I've read documentation on
http://www.postfix.org/postconf.5.html#transport_maps, but cannot
understand what actually happens during postfix lookups, when
transport_maps is being specified as:

transport_maps = type:A, type:B

No. Table B is queried only if the query of table A produces "not found".

This is how all *_maps features work in Postfix.

Hi Wietse and All,

sorry to bother, but getting weird results and need to understand where 
I'm doing wrong.

By the way Running Postfix 2.7.1 on a box external to netorbit.it

On hash table I've an entry which reports:

netorbit.itsmtp:power.netorbit.it

Documentation reports:



*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/
  Deliver   mail  for/user+extension@domain/   through
  /transport/  to/nexthop/.

   /user@domain transport/:/nexthop/
  Deliver mail for/user@domain/  through/transport/   to
  /nexthop/.

   /domain transport/:/nexthop/
  Deliver  mail  for/domain/  through/transport/  to/nex-/
  /thop/.

   /.domain transport/:/nexthop/
  Deliver mail for any subdomain  of/domain/   through
  /transport/   to/nexthop/.  This applies only when the
  string*transport_maps  
*  is not  listed  in  the*par 
 -*
  *ent_domain_matches_subdomains  
*
configuration  set-
  ting.  Otherwise, a domain name matches itself  and
  its subdomains.

   ***  /transport/:/nexthop/
  The  special pattern***  represents any address (i.e.
  it functions  as  the  wild-card  pattern,  and  is
  unique to Postfix transport tables).



So far I've understood that postmap hash:file creates out DB files, right?

So when sending an email via such box, for example to 
post...@netorbit.it, I'd expect :


1) Check on "A" table (the hash one) for match post...@netorbit.it, 
which is absent

2) Check on "A" table with netorbit.it, which matches
.
. if not
.
N) Check on "B" table (the TCP one) for post...@netorbit.it
  Since the TCP map is a sort of catch-all, would reply with one of 
the default transports rotate1:, etc.


Thanks for your help.

Angelo
 




-- 
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com/links/en/frams.html

Re: Transport Maps

[post...@netorbit.it]

On 21/06/2012 16:25, Wietse Venema wrote:


transport_maps is being specified as:

transport_maps = type:A, type:B

Would postfix query first table A and if not getting a match, moves to
query table B ?
Yes. Table B is queried only if the query of table A produces "not found".


If the transport given by table A defers the email (eg by connection
timeout), would postfix use the results from table B?

No. Table B is queried only if the query of table A produces "not found".

This is how all *_maps features work in Postfix.

Wietse

Hi Wietse,

it just what I was expecting.
Since apparently I'm noticing a different behavior, I need to 
investigate more deeply and understand where my error lies.


Hope I don't need to disturb you again.

Have a nice day.
Angelo







--
This mail was scanned by BitDefender
For more information please visit http://www.bitdefender.com/links/en/frams.html

Re: Transport Maps

[Wietse Venema]

post...@netorbit.it:
> Hi,
> 
> just a quick question regarding transport_maps.
> 
> I've read documentation on 
> http://www.postfix.org/postconf.5.html#transport_maps, but cannot 
> understand what actually happens during postfix lookups, when 
> transport_maps is being specified as:
> 
> transport_maps = type:A, type:B
> 
> Would postfix query first table A and if not getting a match, moves to 
> query table B ?

Yes. Table B is queried only if the query of table A produces "not found".

> If the transport given by table A defers the email (eg by connection 
> timeout), would postfix use the results from table B?

No. Table B is queried only if the query of table A produces "not found".

This is how all *_maps features work in Postfix.

Wietse

Re: Transport maps with LDAP.

[Victor Duchovni]

On Mon, Jan 10, 2011 at 06:35:23PM -0200, Lauro Costa G. Borges wrote:

>>> Mail arrives to b...@domain1.org (and b...@domain1.org has an alias to
>>> bla...@domain2.org).
>>
>> What do you mean by "has an alias"?
>
>I'll try to explain with an example:
>
>
> I have these 2 domains:
>
>  region1.company.com
>
>  company.com
>
>Suppose every email to sa...@region1.company.com should also go to
> sa...@company.com, then sa...@region1.company.com sends a copy to
> sa...@company.com.

This still does not explain what "has an alias" means. What actual
*mechanisms* and *settings* are used to implement such an "alias"?

The transport table is not an aliasing mechanism. Rewriting mechanisms
are explained in:

http://www.postfix.org/ADDRESS_REWRITING_README.html

>>> I would like the result to the query to be the domain I searched, AND 
>>> the other domains, since, in the case I have an alias, domain2.org also
>>> needs to be listed as a domain a relay for.
>>
>> You are confused. Transport lookups are single valued. The lookup result
>> in relay_domains is entirely ignored, ony the existence of the lookup
>> key in the table is signficant.
>
>Ok, but what happens is this:
>
>  A new email arrives to sa...@region1.company.com, when it enters the
> mail system, 2 messages are put in the queue, right?

No, only one, a single message stores multiple recipient records.

> One for
> sa...@region1.company.com, and another to sa...@company.com.

Only if you have used virtual(5) to rewrite the input address to
a pair of output addresses.


> But the
> transport map lookup is executed only for "region1.company.com", so
> the mail to "sa...@company.com" does not have a transport, I guess.

No. Each recipient address in a message is subjected to a separate
(1-to-1) transport lookup.

>> This is completely wrong. First, you have to explain what you mean by
>> an "alias", where you want the mail to be delivered, what actually
>> happens (detailed unmangled logs) and show your configuration.
>>
>> http://www.postfix.org/DEBUG_README.html#mail
>
> ldap-transport.cf:
>
>   version = 3
>   server_host = ldap://ldap.company.com:389
>   search_base=ou=mail,ou=services,dc=company,dc=com
>   scope = sub
>   result_attribute=associatedDomain
>   query_filter=(&(objectclass=domainRelatedObject)(associatedDomain=%s))
>   result_format=%s relay:[150.170.6.15]

This table definition is grossly wrong. The VALUE of an LDAP transport
lookup MUST be JUST the "transport:nexthop" pair, associadted with the
lookup table. If you don't have any LDAP attributes that store the
transport:nexthop string, then you use a *fixed* result_format with
no "%s" part.

> Jan 10 17:40:49 mx postfix/qmgr[14897]: warning: connect to transport 
> private/company.com relay: No such file or directory

Indeed, your transport table is incorrectly defined.

-- 
Viktor.

Re: Transport maps with LDAP.

[Lauro Costa G. Borges]

Citando Victor Duchovni :


Make sure you have a robust, low-latency LDAP infrastructure. The
trivial-rewrite service will query LDAP to determine the address class of
each domain, and qmgr(8) uses trivial-rewrite to resolve every recipient,
so LDAP becomes performance critical.


Suppose I relay for both domain1.org and domain2.org.

Mail arrives to b...@domain1.org (and b...@domain1.org has an alias to
bla...@domain2.org).


What do you mean by "has an alias"?


   I'll try to explain with an example:


I have these 2 domains:

 region1.company.com

 company.com

   Suppose every email to sa...@region1.company.com should also go to
sa...@company.com, then sa...@region1.company.com sends a copy to
sa...@company.com.





 I would like the result to the query to be the domain I searched, AND the
other domains, since, in the case I have an alias, domain2.org also needs
to be listed as a domain a relay for.


You are confused. Transport lookups are single valued. The lookup result
in relay_domains is entirely ignored, ony the existence of the lookup
key in the table is signficant.


   Ok, but what happens is this:

   A new email arrives to sa...@region1.company.com, when it enters the
mail system, 2 messages are put in the queue, right? One for
sa...@region1.company.com, and another to sa...@company.com. But the
transport map lookup is executed only for "region1.company.com", so
the mail to "sa...@company.com" does not have a transport, I guess.




If you want to relay for a domain, make sure that a lookup for that
domain returns a result when queried against the table that implements
relay_domains.


   This is working ok, to every domain I relay for. The only problem  
is when aliases are used.





I think when Postfix notices it also has to deliver to
bla...@domain2.org, it does NOT make another search, and the only transport
it knows about at that moment, is "domain1.org relay:[1.2.3.10]". It seems
Postfix doesn't know about the transport to domain2.org


This is completely wrong. First, you have to explain what you mean by
an "alias", where you want the mail to be delivered, what actually
happens (detailed unmangled logs) and show your configuration.

http://www.postfix.org/DEBUG_README.html#mail



   ldap-transport.cf

   version = 3
server_host = ldap://ldap.company.com:389
search_base=ou=mail,ou=services,dc=company,dc=com
result_attribute=associatedDomain
result_format=%s relay:[150.170.6.15]  #COMMENT (THIS IS the IMAP  
machine's ip)

query_filter=(&(objectclass=domainRelatedObject)(associatedDomain=%s))
scope = sub

- ldap-users.cf

version = 3
server_host = ldap://ldap.company.com:389
search_base=ou=%d,ou=mail,ou=services,dc=company,dc=com
result_attribute=rfc822MailMember
query_filter=(& (cn=%u)(objectclass=nisMailAlias)(AccountActive=TRUE) )
scope = sub

- ldap-domains.cf

version = 3
server_host = ldap://ldap.company.com:389
search_base=ou=mail,ou=services,dc=company,dc=com
result_attribute=associatedDomain
query_filter=(&(objectclass=domainRelatedObject)(associatedDomain=%u))
scope = sub


- main.cf

append_dot_mydomain = no
readme_directory = no
transport_maps = ldap:/etc/postfix/ldap-transport.cf
myhostname = mx.company.com
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-users.cf
local_recipient_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-users.cf
virtual_alias_maps = ldap:/etc/postfix/ldap-users.cf
virtual_alias_domains = hash:/etc/postfix/virtual
virtual_maps = ldap:/etc/postfix/ldap-users.cf
relay_recipient_maps = ldap:/etc/postfix/ldap-users.cf
mydestination = $myhostname, localhost.$mydomain,
ldap:/etc/postfix/ldap-domains.cf
relay_domains = ldap:/etc/postfix/ldap-domains.cf
smtpd_recipient_restrictions =  permit_mynetworks,
check_policy_service inet:127.0.0.1:10023,
reject_unauth_destination
relayhost =
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 150.170.6.0/24
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox =
smtpd_sasl_auth_enable = no
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd
smtpd_sasl_authenticated_header = no
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
broken_sasl_auth_clients = no
smtpd_sender_restrictions =
mailbox_command =
smtp_use_tls = no
smtpd_tls_received_header = no
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_auth_only = no
tls_random_source = dev:/dev/urandom
content_filter=smtp-amavis:[127.0.0.1]:10024
message_size_limit = 3000


--- LOGS


 lauro1...@gmail.com sent a message to sa...@region1.company.com.

 All mail to sa...@region1.company.com should also be sent to  
sa...@company.com (which I relay for), and externalem...@yahoo.com,  
which I do not relay for. Message to externalem...@yahoo.com is sent  
with success, but to sa...@company.com not!


Jan 10 17:40:48 mx amavis[1030]: (01030-02) Passed CLEAN,  
[150.170.6.10] [150.1

Re: Transport maps with LDAP.

[Victor Duchovni]

On Mon, Dec 20, 2010 at 04:17:08PM -0200, Lauro Costa G. Borges wrote:

> I'm using Postfix 2.7.0.

Good, this is a reasonably recent release. You may want to consider
updating to 2.7.2:

20100515

   Bugfix (introduced Postfix 2.6): the Postfix SMTP client
   XFORWARD implementation did not skip "unknown" SMTP client
   attributes, causing a syntax error when sending a PORT
   attribute. Reported by Victor Duchovni. File: smtp/smtp_proto.c.

20100526

   Cleanup: a unit-test driver (for stand-alone tests) was not
   updated after an internal API change. Vesa-Matti J Kari
   File: milter/milter.c.

20100529

   Portability: OpenSSL 1.0.0 changes the priority of anonymous
   cyphers. Victor Duchovni. Files: postconf.proto,
   global/mail_params.h, tls/tls_certkey.c, tls/tls_client.c,
   tls/tls_dh.c, tls/tls_server.c.

   Portability: Mac OS 10.6.3 requires 
   instead of . Files: makedefs, util/sys_defs.h,
   dns/dns.h.

20100531

   Robustness: skip LDAP queries with non-ASCII search strings.
   The LDAP library requires well-formed UTF-8.  Victor Duchovni.
   File: global/dict_ldap.c.

20100601

   Safety: Postfix processes log a warning when a matchlist
   has a #comment at the end of a line (for example mynetworks
   or relay_domains).  File: util/match_list.c.

   Portability: Berkeley DB 5.x has the same API as Berkeley
   DB 4.1 and later. File: util/dict_db.c.

20100610

   Bugfix (introduced Postfix 2.2): Postfix no longer appends
   the system default CA certificates to the lists specified
   with *_tls_CAfile or with *_tls_CApath.  This prevents
   third-party certificates from getting mail relay permission
   with the permit_tls_all_clientcerts feature.  Unfortunately
   this may cause compatibility problems with configurations
   that rely on certificate verification for other purposes.
   To get the old behavior, specify "tls_append_default_CA =
   yes".  Files: tls/tls_certkey.c, tls/tls_misc.c,
   global/mail_params.h.  proto/postconf.proto, mantools/postlink.

20100714

   Compatibility with Postfix < 2.3: fix 20061207 was incomplete
   (undoing the change to bounce instead of defer after
   pipe-to-command delivery fails with a signal). Fix by Thomas
   Arnett. File: global/pipe_command.c.

20100727

   Bugfix: the milter_header_checks parser provided only the
   actions that change the message flow (reject, filter,
   discard, redirect) but disabled the non-flow actions (warn,
   replace, prepend, ignore, dunno, ok).  File:
   cleanup/cleanup_milter.c.

20100827

   Performance: fix for poor smtpd_proxy_filter TCP performance
   over loopback (127.0.0.1) connections. Problem reported by
   Mark Martinec.  Files: smtpd/smtpd_proxy.c.

20101023

   Cleanup: don't apply reject_rhsbl_helo to non-domain forms
   such as network addresses.  This would cause false positives
   with dbl.spamhaus.org.  File: smtpd/smtpd_check.c.

20101117

   Bugfix: the "421" reply after Milter error was overruled
   by Postfix 1.1 code that replied with "503" for RFC 2821
   compliance. We now make an exception for "final" replies,
   as permitted by RFC. Solution by Victor Duchovni. File:
   smtpd/smtpd.c.

> I use LDAP do manage/list domains that I relay for.

Make sure you have a robust, low-latency LDAP infrastructure. The
trivial-rewrite service will query LDAP to determine the address class of
each domain, and qmgr(8) uses trivial-rewrite to resolve every recipient,
so LDAP becomes performance critical.

> Suppose I relay for both domain1.org and domain2.org.
>
> Mail arrives to b...@domain1.org (and b...@domain1.org has an alias to 
> bla...@domain2.org).

What do you mean by "has an alias"?

>  I would like the result to the query to be the domain I searched, AND the 
> other domains, since, in the case I have an alias, domain2.org also needs 
> to be listed as a domain a relay for.

You are confused. Transport lookups are single valued. The lookup result
in relay_domains is entirely ignored, ony the existence of the lookup
key in the table is signficant.

If you want to relay for a domain, make sure that a lookup for that
domain returns a result when queried against the table that implements
relay_domains.

> I think when Postfix notices it also has to deliver to 
> bla...@domain2.org, it does NOT make another search, and the only transport 
> it knows about at that moment, is "domain1.org relay:[1.2.3.10]". It seems 
> Postfix doesn't know about the transport to domain2.org

This is completely wrong. First, you have to explain what you mean by
an "al

Re: Transport maps for a specfic user attached to a virtual domain

[mouss]

 Le 09/10/2010 13:32, Olivier BONHOMME a écrit :

Le 08/10/2010 21:30, Victor Duchovni a écrit :

On Fri, Oct 08, 2010 at 05:38:21PM +0200, Olivier BONHOMME wrote:

I am writing here because I have an issue trying to use 
transport_maps with

a domain which is declared as VIRTUAL.


You fail to distinguish between virtual_alias_domains and
virtual_mailbox_domains. Which is it?


Sorry : it is virtual_mailbox_domain.



Now i would want this step : Redirect a specific account f...@domain.com
from the MDA to another SMTP server but this account is not declared 
on the

MDA.


You can rewrite an account in a final (local, or virtual mailbox) domain
to another domain via virtual_alias_maps. Postfix will then accept mail
for the domain, and forward to the alternate mailbox.


So I have to create a dummy account to do that in order for the 
virtual agent to accept the mail to be delivered ? 


virtual_alias_maps is enough. chose for yuorself:

[without per user transports]
use a virtual_alias like
j...@example.com   j...@host9.example.com
(and either an explicit transport entry to route mail for 
host9.example.com to the correct host, or rely on DNS). Then use 
smtp_generic_maps to rewrite the address back to its original form 
(remove the "host9." part).


[with per user transports]
use a virtual alias like
j...@example.comj...@example.com
and a transport entry like
j...@example.com  relay:[10.1.2.3]




But in that case, can I declare a transport map in order to tell 
another smtp transport for this account in order to avoid a local 
delivery ?


Oui, as far as the transport entry applies to the adress after all 
virtual aliases are resolved.


[snip]

Re: Transport maps for a specfic user attached to a virtual domain

[Olivier BONHOMME]

Le 08/10/2010 21:30, Victor Duchovni a écrit :

On Fri, Oct 08, 2010 at 05:38:21PM +0200, Olivier BONHOMME wrote:


I am writing here because I have an issue trying to use transport_maps with
a domain which is declared as VIRTUAL.


You fail to distinguish between virtual_alias_domains and
virtual_mailbox_domains. Which is it?


Sorry : it is virtual_mailbox_domain.



Now i would want this step : Redirect a specific account f...@domain.com
from the MDA to another SMTP server but this account is not declared on the
MDA.


You can rewrite an account in a final (local, or virtual mailbox) domain
to another domain via virtual_alias_maps. Postfix will then accept mail
for the domain, and forward to the alternate mailbox.


So I have to create a dummy account to do that in order for the virtual 
agent to accept the mail to be delivered ? But in that case, can I 
declare a transport map in order to tell another smtp transport for this 
account in order to avoid a local delivery ?



I wonder if it was possible to do this with the transport maps feature or
not. I tried to declare a transport_maps with "f...@domain.com
smtp:" but postfix rejected me the mail telling me this
account is not a virtual mailbox (which seems to be logical).

The main objective is to redirect a specific address which is a mailing
list addres to the mailing list server without using a subdomain.


To retain the address of the mailbox use "smtp_generic_maps" to undo
the rewrite, as described in an earlier thread today about LDAP on
MX hosts.



I am going to look at this setting.

Regards,
Olivier BONHOMME

Re: Transport maps for a specfic user attached to a virtual domain

[Victor Duchovni]

On Fri, Oct 08, 2010 at 05:38:21PM +0200, Olivier BONHOMME wrote:

> I am writing here because I have an issue trying to use transport_maps with 
> a domain which is declared as VIRTUAL.

You fail to distinguish between virtual_alias_domains and
virtual_mailbox_domains. Which is it?

> Now i would want this step : Redirect a specific account f...@domain.com 
> from the MDA to another SMTP server but this account is not declared on the 
> MDA.

You can rewrite an account in a final (local, or virtual mailbox) domain
to another domain via virtual_alias_maps. Postfix will then accept mail
for the domain, and forward to the alternate mailbox.

> I wonder if it was possible to do this with the transport maps feature or 
> not. I tried to declare a transport_maps with "f...@domain.com 
> smtp:" but postfix rejected me the mail telling me this 
> account is not a virtual mailbox (which seems to be logical).
>
> The main objective is to redirect a specific address which is a mailing 
> list addres to the mailing list server without using a subdomain.

To retain the address of the mailbox use "smtp_generic_maps" to undo
the rewrite, as described in an earlier thread today about LDAP on
MX hosts.

-- 
Viktor.

Re: transport maps

[Osmany]

On Tue, 2009-12-08 at 00:43 -0500, Sahil Tandon wrote:
> On Mon, 07 Dec 2009, osm...@oc.quimefa.cu wrote:
> 
> >   Hi I am trying to make postfix to relay all mail except for the ones
> >   going to a specific domain. For example I want to be able to make
> >   postfix relay all mail except for domain .ca I was wondering if
> >   something like this is possible or if there is anything like this:
> >   transport_maps.cf *.* 10.25.x.x !test !test.cu 10.25.x.x I don't
> >   know if this is actually functional in postfix. in this case I would
> >   like to have a transport for all mail except the ones with the
> >   destination domain.ca. In other words I don't know if I have to use
> >   domain_transport or transport_maps but I would like to specify an
> >   exception in postfix transports. If anybody can help me on this, I
> >   would really appreciate it. thanks in advance.
> 
> Your question is unclear to me, but I *guess* you are looking for
> sometihng like:
> 
> * transport:foo.bar.org
> domain.ca :
> 
> If that does not meet your needs, ask your question again using clear
> examples and more detail.  Also be sure to read:
> http://www.postfix.org/transport.5.html
> 
Yes, that is exactly what I want to do. so how should I put this in
transport_maps. is there an order to the transports. I'm guessing I
should put it like this:

domain.ca   :
*   transport:10.25.x.x

so that it first reads the mapping for the domain.ca messages and if
that doesn't match then goes to the next transport.

Re: transport maps

[Sahil Tandon]

On Mon, 07 Dec 2009, osm...@oc.quimefa.cu wrote:

>   Hi I am trying to make postfix to relay all mail except for the ones
>   going to a specific domain. For example I want to be able to make
>   postfix relay all mail except for domain .ca I was wondering if
>   something like this is possible or if there is anything like this:
>   transport_maps.cf *.* 10.25.x.x !test !test.cu 10.25.x.x I don't
>   know if this is actually functional in postfix. in this case I would
>   like to have a transport for all mail except the ones with the
>   destination domain.ca. In other words I don't know if I have to use
>   domain_transport or transport_maps but I would like to specify an
>   exception in postfix transports. If anybody can help me on this, I
>   would really appreciate it. thanks in advance.

Your question is unclear to me, but I *guess* you are looking for
sometihng like:

*   transport:foo.bar.org
domain.ca   :

If that does not meet your needs, ask your question again using clear
examples and more detail.  Also be sure to read:
http://www.postfix.org/transport.5.html

-- 
Sahil Tandon 

RE: transport maps using "from" address field filtering

[Etienne Simard]

Thanks for the hint Noel.

The problem I found with sender_dependent_relayhost_maps is that

"This information is overruled with relay_transport, default_transport
and with the transport(5) table."

so if you already have a transport map for that particular domain, it
won't work. 

I will investigate the SASL/sender_relay thing.


Etienne 
-Original Message-
From: Noel Jones [mailto:njo...@megan.vbhcs.org] 
Sent: July 24, 2009 12:19 PM
To: Kenneth Marshall
Cc: Etienne Simard; postfix-users@postfix.org
Subject: Re: transport maps using "from" address field filtering

Kenneth Marshall wrote:
> On Fri, Jul 24, 2009 at 11:50:19AM -0400, Etienne Simard wrote:
>> Hi,
>>
>> I must have been searching at the wrong place or using the wrong 
>> keywords as I have been trying to find how to correctly transport to 
>> a particular smtp relay or have postfix do a MX query based on the
"from"
>> address field. I did look at the postfix doc, in se's and the 
>> postfix-users archives withtout any luck. The transport maps do a 
>> great job of doing it based on the "to" address field or domain but I

>> am still looking to find how to do it with a "from" field. I hope 
>> someone can point me to the right doc.
>>
>>
>> Etienne
>>
> 
> Hi Etienne,
> 
> We have been looking at a similar type of functionality but are using 
> the client IP address instead. The two options we looked at both set 
> the envelope recipient address using "+xxx" to encode the sender 
> information which could then be used by a prce/regex transport map to 
> send the message to the correct place. Either a policyd or a 
> header_checks content filter would work. We are going to use the 
> policyd to avoid processing a large data stream. Let me know what you 
> end up doing and if you find any other options.
> 
> Regards,
> Ken
> 

Look at
http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps

and maybe also
http://www.postfix.org/SOHO_README.html#client_sasl_sender

   -- Noel Jones

Re: transport maps using "from" address field filtering

[Wietse Venema]

Etienne Simard:
> Hi,
> 
> I must have been searching at the wrong place or using the wrong
> keywords as I have been trying to find how to correctly transport to a
> particular smtp relay or have postfix do a MX query based on the "from"
> address field. I did look at the postfix doc, in se's and the

For this, the transport map is not the right way to go, since it
would also send mail TO a local user out via SMTP.

See http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps

Wietse

> postfix-users archives withtout any luck. The transport maps do a great
> job of doing it based on the "to" address field or domain but I am still
> looking to find how to do it with a "from" field. I hope someone can
> point me to the right doc.
> 
> 
> Etienne
> 
> 

Re: transport maps using "from" address field filtering

[Noel Jones]

Kenneth Marshall wrote:

On Fri, Jul 24, 2009 at 11:50:19AM -0400, Etienne Simard wrote:

Hi,

I must have been searching at the wrong place or using the wrong
keywords as I have been trying to find how to correctly transport to a
particular smtp relay or have postfix do a MX query based on the "from"
address field. I did look at the postfix doc, in se's and the
postfix-users archives withtout any luck. The transport maps do a great
job of doing it based on the "to" address field or domain but I am still
looking to find how to do it with a "from" field. I hope someone can
point me to the right doc.


Etienne



Hi Etienne,

We have been looking at a similar type of functionality but are
using the client IP address instead. The two options we looked
at both set the envelope recipient address using "+xxx" to
encode the sender information which could then be used by a
prce/regex transport map to send the message to the correct
place. Either a policyd or a header_checks content filter would
work. We are going to use the policyd to avoid processing a
large data stream. Let me know what you end up doing and if
you find any other options.

Regards,
Ken



Look at
http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps

and maybe also
http://www.postfix.org/SOHO_README.html#client_sasl_sender

  -- Noel Jones

Re: transport maps using "from" address field filtering

[Kenneth Marshall]

On Fri, Jul 24, 2009 at 11:50:19AM -0400, Etienne Simard wrote:
> Hi,
> 
> I must have been searching at the wrong place or using the wrong
> keywords as I have been trying to find how to correctly transport to a
> particular smtp relay or have postfix do a MX query based on the "from"
> address field. I did look at the postfix doc, in se's and the
> postfix-users archives withtout any luck. The transport maps do a great
> job of doing it based on the "to" address field or domain but I am still
> looking to find how to do it with a "from" field. I hope someone can
> point me to the right doc.
> 
> 
> Etienne
> 

Hi Etienne,

We have been looking at a similar type of functionality but are
using the client IP address instead. The two options we looked
at both set the envelope recipient address using "+xxx" to
encode the sender information which could then be used by a
prce/regex transport map to send the message to the correct
place. Either a policyd or a header_checks content filter would
work. We are going to use the policyd to avoid processing a
large data stream. Let me know what you end up doing and if
you find any other options.

Regards,
Ken

Re: Transport Maps

[Clunk Werclick]

On Tue, 2009-07-21 at 12:21 -0400, Linux Addict wrote:
> I tried digging, I get the MX servers on the ANSWER section. I manage
> DNS as well, so I know its resolving correctly.

Just one thing Sir and a shot in the water. Restart Postfix (not
reload). I was having a problem where it kept looking up against the
wrong name server. There seems to be some caching of name servers and
results.

After many hours it gave me such joy for a simplest fix.

-- 
---
C Werclick .Lot
Technical incompetent
Loyal Order Of The Teapot.

This e-mail and its attachments is intended only to be used as an e-mail
and an attachment. Any use of it for other purposes other than as an
e-mail and an attachment will not be covered by any warranty that may or
may not form part of this e-mail and attachment. 

Re: Transport Maps

[Linux Addict]

On Tue, Jul 21, 2009 at 12:37 PM, Linux Addict wrote:

>
>
> On Tue, Jul 21, 2009 at 12:24 PM, Jaroslaw Grzabel  wrote:
>
>> Linux Addict wrote:
>>
>>> I tried digging, I get the MX servers on the ANSWER section. I manage DNS
>>> as well, so I know its resolving correctly.
>>>
>> What is in the log files then when you're trying to relay your messages ?
>>
>> Regards,
>> Jarek
>>
>
> Good Question.  It is using the MX records of  example.com, but we need
> postfix to use the MX records of smtp.example.com
>
>
>
Thanks all. I just worked around by adding internal CNAME pointing to 2 MX
servers. I will come back later and check

Re: Transport Maps

[Linux Addict]

On Tue, Jul 21, 2009 at 12:24 PM, Jaroslaw Grzabel  wrote:

> Linux Addict wrote:
>
>> I tried digging, I get the MX servers on the ANSWER section. I manage DNS
>> as well, so I know its resolving correctly.
>>
> What is in the log files then when you're trying to relay your messages ?
>
> Regards,
> Jarek
>

Good Question.  It is using the MX records of  example.com, but we need
postfix to use the MX records of smtp.example.com

Re: Transport Maps

[Jaroslaw Grzabel]

Linux Addict wrote:
I tried digging, I get the MX servers on the ANSWER section. I manage 
DNS as well, so I know its resolving correctly.

What is in the log files then when you're trying to relay your messages ?

Regards,
Jarek

Re: Transport Maps

[Linux Addict]

I tried digging, I get the MX servers on the ANSWER section. I manage DNS as
well, so I know its resolving correctly.

On Tue, Jul 21, 2009 at 12:20 PM, Jaroslaw Grzabel  wrote:

> Linux Addict wrote:
>
>>
>> Simon, I already tried that. Its not doing MX lookup I guess.
>>
>>  Maybe it works but you're using your local DNS which doesn't know MX
> record for that remote domain you want to relay your messages through. Try
> locally run dig domainname.com MX and see the result. If it's empty it
> means that it's something wrong with that domain name and there is nothing
> to do with postfix in this case because postfix will not cast a spell for
> you and charm MX record.
>
> syntax as:
> domainname.com smtp:server.domain.com
> should work for you
>
> Regards,
> Jarek
>
> P.S. Sorry I posted that to your priv as well... reply to the list please.
>

Re: Transport Maps

[Jaroslaw Grzabel]

Linux Addict wrote:


Simon, I already tried that. Its not doing MX lookup I guess.

Maybe it works but you're using your local DNS which doesn't know MX 
record for that remote domain you want to relay your messages through. 
Try locally run dig domainname.com MX and see the result. If it's empty 
it means that it's something wrong with that domain name and there is 
nothing to do with postfix in this case because postfix will not cast a 
spell for you and charm MX record.


syntax as:
domainname.com smtp:server.domain.com
should work for you

Regards,
Jarek

P.S. Sorry I posted that to your priv as well... reply to the list please.

Re: Transport Maps

[Clunk Werclick]

On Tue, 2009-07-21 at 17:10 +0100, Clunk Werclick wrote:
> On Tue, 2009-07-21 at 12:05 -0400, Linux Addict wrote:
> > 
> > 
> > On Tue, Jul 21, 2009 at 12:00 PM, Ralf Hildebrandt
> >  wrote:
> > * Ralf Hildebrandt :
> > 
> > > > In simple, When I send a mail to @example.com,  postfix
> > must send the mail
> > > > to the MX records of smtp.example.com.
> > 
> > 
> > > example.com  smtp.example.com
> > 
> > 
> > OK, not too sure if Postfix will perform an MX lookup for the
> > RHS
> > (smtp.example.com in this example). Please try
> > 
> > 
> > --
> > Ralf Hildebrandt
> >  Geschäftsbereich IT | Abteilung Netzwerk
> >  Charité - Universitätsmedizin Berlin
> >  Campus Benjamin Franklin
> >  Hindenburgdamm 30 | D-12203 Berlin
> >  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
> >  ralf.hildebra...@charite.de | http://www.charite.de
> > 
> > 
> > 
> > I just tried, Its NOT  using MX records of smtp.example.com. I can
> > manipulate it thru DNS, but will more comfortable if we can do it
> > through Postfix.
> > 
> > 
> > 
> What about plain old:
> 
> smtp:
> 
> and nothing else. I was trying to day to do the opposite but it kept
> looking up the mx for the destination domain when I did not have a
> transport map. 
Don't listen to me - I am an idiot. I have now read your request fully
and I am garbage spouting. Sorry.
-- 
---
C Werclick .Lot
Technical incompetent
Loyal Order Of The Teapot.

This e-mail and its attachments is intended only to be used as an e-mail
and an attachment. Any use of it for other purposes other than as an
e-mail and an attachment will not be covered by any warranty that may or
may not form part of this e-mail and attachment. 

Re: Transport Maps

[Linux Addict]

On Tue, Jul 21, 2009 at 12:03 PM, Simon Waters  wrote:

> On Tuesday 21 July 2009 16:53:52 Linux Addict wrote:
> >
> > I tried using transport maps,  "example.com  :[smtp1.example.com]"
> > and " example.com   smtp:[smtp1.example.com], but of them didn't use
> > smtp.example.com.
>
> Not clear what you mean here.
>
> Documentation of "transport" (man transport) suggests you don't want the
> "[]"
> if you want MX lookup.
>
> So I think you want:
>
> example.com smtp:smtp.example.com


Simon, I already tried that. Its not doing MX lookup I guess.

Re: Transport Maps

[Clunk Werclick]

On Tue, 2009-07-21 at 12:05 -0400, Linux Addict wrote:
> 
> 
> On Tue, Jul 21, 2009 at 12:00 PM, Ralf Hildebrandt
>  wrote:
> * Ralf Hildebrandt :
> 
> > > In simple, When I send a mail to @example.com,  postfix
> must send the mail
> > > to the MX records of smtp.example.com.
> 
> 
> > example.com  smtp.example.com
> 
> 
> OK, not too sure if Postfix will perform an MX lookup for the
> RHS
> (smtp.example.com in this example). Please try
> 
> 
> --
> Ralf Hildebrandt
>  Geschäftsbereich IT | Abteilung Netzwerk
>  Charité - Universitätsmedizin Berlin
>  Campus Benjamin Franklin
>  Hindenburgdamm 30 | D-12203 Berlin
>  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
>  ralf.hildebra...@charite.de | http://www.charite.de
> 
> 
> 
> I just tried, Its NOT  using MX records of smtp.example.com. I can
> manipulate it thru DNS, but will more comfortable if we can do it
> through Postfix.
> 
> 
> 
What about plain old:

smtp:

and nothing else. I was trying to day to do the opposite but it kept
looking up the mx for the destination domain when I did not have a
transport map. 

-- 
---
C Werclick .Lot
Technical incompetent
Loyal Order Of The Teapot.

This e-mail and its attachments is intended only to be used as an e-mail
and an attachment. Any use of it for other purposes other than as an
e-mail and an attachment will not be covered by any warranty that may or
may not form part of this e-mail and attachment. 

Re: Transport Maps

[Linux Addict]

On Tue, Jul 21, 2009 at 12:00 PM, Ralf Hildebrandt <
ralf.hildebra...@charite.de> wrote:

> * Ralf Hildebrandt :
>
> > > In simple, When I send a mail to @example.com,  postfix must send the
> mail
> > > to the MX records of smtp.example.com.
>
> > example.com  smtp.example.com
>
> OK, not too sure if Postfix will perform an MX lookup for the RHS
> (smtp.example.com in this example). Please try
>
> --
> Ralf Hildebrandt
>  Geschäftsbereich IT | Abteilung Netzwerk
>  Charité - Universitätsmedizin Berlin
>  Campus Benjamin Franklin
>  Hindenburgdamm 30 | D-12203 Berlin
>  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
>  ralf.hildebra...@charite.de | http://www.charite.de
>
>
I just tried, Its NOT  using MX records of smtp.example.com. I can
manipulate it thru DNS, but will more comfortable if we can do it through
Postfix.

Re: Transport Maps

[Simon Waters]

On Tuesday 21 July 2009 16:53:52 Linux Addict wrote:
> 
> I tried using transport maps,  "example.com  :[smtp1.example.com]"  
> and " example.com   smtp:[smtp1.example.com], but of them didn't use
> smtp.example.com.

Not clear what you mean here.

Documentation of "transport" (man transport) suggests you don't want the "[]" 
if you want MX lookup.

So I think you want:

example.com smtp:smtp.example.com

Re: Transport Maps

[Ralf Hildebrandt]

* Ralf Hildebrandt :

> > In simple, When I send a mail to @example.com,  postfix must send the mail
> > to the MX records of smtp.example.com.

> example.com  smtp.example.com

OK, not too sure if Postfix will perform an MX lookup for the RHS
(smtp.example.com in this example). Please try

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: Transport Maps

[Ralf Hildebrandt]

* Linux Addict :
> I have a postfix MTA server running. I was asked to setup relay mail to a
> specific domain thru MX record.
> Domain - Example.com
> An A record smtp.example.com
> MX Records smtp.example.com - smtp1.example.com and smtp2.example.com.
> 
> In simple, When I send a mail to @example.com,  postfix must send the mail
> to the MX records of smtp.example.com.
> 
> I tried using transport maps,  "example.com  :[smtp1.example.com]"   and
>  " example.com   smtp:[smtp1.example.com], but of them didn't use
> smtp.example.com.

example.comsmtp.example.com

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: transport maps override

[Sahil Tandon]

On Wed, 20 May 2009, none none wrote:

> We are running postfix 2.3.3. on a Redhat ES 5.1
> We are receiving mail for two domains:
> a) domain.com
> b) customers.domain.com
> 
> Recently a company that we cooperate with, asked us to 
> forward all the e-mails sent to them (for "security" reasons) 
> from domain.com to an 
> alternative SMTP (othersmtp.company.com) that is 
> other than the company's primary MX.

So company.com wants emails from sen...@domain.com -> any...@company.com to
be routed to othersmtp.company.com, but mail from all other domains should
go to the primary MX.

> We implemented this, by modifying the /etc/postfix/transport file, 
> and it worked like a charm.

You did not provide a specific example from your transport file, but
presumably, you modified it so *all* mail destined for any...@company.com is
routed to othersmtp.company.com.  But your requirements are to route mail to
othersmtp.company.com *only* when sen...@domain.com -> any...@company.com.

> The problem is that we would like to override the above rule for the domain
> customers.domain.com. So when someone from customers.domain.com sends
> e-mail to company.com that mail is sent to the company's primary MX and not
> via othersmtp.company.com.

By default, Postfix will try to send all mail to company.com via its primary
MX, so the "override" is needed *only* when mail is going to company.com
from a sender in domain.com.  You can run a second instance of Postfix that
routes all mail for company.com to othersmtp.company.com.  On the initial
(your current) instance of Postfix, use sender_dependent_relayhost_maps to
route all mail from send...@domain.com to the second instance.  There, mail
for company.com will be forced towards othersmtp.company.com, while mail to
other recipients will be routed normally.

You may want to consider and mitigate any unintended consequences, and I
realize this seems like overkill for what you want to do, but I cannot think
of another way to do it.

-- 
Sahil Tandon 

Re: Transport Maps Ignored After Upgrade

[/dev/rob0]

On Mon May 11 2009 14:45:14 Eric Cunningham wrote:
> This may be of use in my situation.  Can you point me to the docs
> that explain how to configure wildcard subdomains?

postconf.5.html#parent_domain_matches_subdomains ... one way
pcre_table.5.html ... another way
regexp_table.5.html ... another (similar) way

The first one also shows how to accomplish subdomain matching in hash: 
maps.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

Noel Jones wrote:

Eric Cunningham wrote:
I want e...@sanguine.whoi.edu to continue delivery to my imap 
account.  In fact, that happened perfectly in my previous postfix 
configuration.  


... it worked previously due to a bug in permit_mx_backup. That bug has 
been corrected.


Ahh...finally, someone has clued me in as to -why- this behavior 
changed.  Thank -you- Noel!



That's not unreasonable, but let's now extend this example to another 
250 hosts that are in a similar situation.  I must now specifically 
find, list and maintain all of 250 of those in some postfix config file 


Correct.  You can configure wildcard subdomains to be delivered all to 
one location if that's appropriate for your configuration.


This may be of use in my situation.  Can you point me to the docs that 
explain how to configure wildcard subdomains?


Thanks,

-Eric

Re: Transport Maps Ignored After Upgrade

[Noel Jones]

Eric Cunningham wrote:
I want e...@sanguine.whoi.edu to continue 
delivery to my imap account.  In fact, that happened perfectly in my 
previous postfix configuration.  


... it worked previously due to a bug in permit_mx_backup. 
That bug has been corrected.


Since upgrading postfix, in order for 
that to continue working, I'm now hearing that I must specifically list 
sanguine.whoi.edu "somewhere" in my postfix configs.  


Yes.

That's not 
unreasonable, but let's now extend this example to another 250 hosts 
that are in a similar situation.  I must now specifically find, list and 
maintain all of 250 of those in some postfix config file 


Correct.  You can configure wildcard subdomains to be 
delivered all to one location if that's appropriate for your 
configuration.


and that 
there's no other way this will work as before?  That, to me, seems 
rather unreasonable.  Doesn't postfix have the capability to look up MX 
records for that purpose?


Postfix can behave as an automatic backup/secondary MX using 
permit_mx_backup and protected by permit_mx_backup_networks, 
but this specifically excludes domains that list you as the 
primary MX, unless those domains are already configured in one 
of the postfix address classes.


http://www.postfix.org/postconf.5.html#permit_mx_backup
http://www.postfix.org/postconf.5.html#permit_mx_backup_networks


  -- Noel Jones

Re: Transport Maps Ignored After Upgrade

[Wietse Venema]

Eric Cunningham:
> that to continue working, I'm now hearing that I must specifically list 
> sanguine.whoi.edu "somewhere" in my postfix configs.  That's not 
> unreasonable, but let's now extend this example to another 250 hosts 
> that are in a similar situation.  I must now specifically find, list and 
> maintain all of 250 of those in some postfix config file and that 
> there's no other way this will work as before?  That, to me, seems 
> rather unreasonable.  Doesn't postfix have the capability to look up MX 
> records for that purpose?

I, the guy who built Postfix, already mentioned that Postfix does
not accept mail just because some MX record points to it. That
would be extremely vulnerable to mis-use.

Ignore my postings at your own peril.

Wietse

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

Noel Jones wrote:

Apparently, sanguine.whoi.edu not listed in any of the postfix address classes. 
 Which address class do you expect this to be?  Then you'll know where the 
domain must be listed.

This is one document you need to understand:
http://www.postfix.org/ADDRESS_CLASS_README.html 



/dev/rob0 wrote:

Correct, sanguine.whoi.edu isn't specifically listed in any of my
address class definitions.  I'm using it for testing the MX relays,
of which I have many.


Yet, DNS points to you:
sanguine.whoi.edu.  86400   IN  MX  10 obtest.whoi.edu.
obtest.whoi.edu.86400   IN  A   128.128.64.226

You either need to accept that mail (as a relay domain, perhaps) or 
change the MX to point to a host that will.


sanguine.whoi.edu is simply a host that is no longer active on my 
network.  At one point, I received email at that host via 
e...@sanguine.whoi.edu.  Now that that's no longer an option, I set up 
an MX record so that mail destined for sanguine.whoi.edu is relayed to 
my postfix smtp server and assigned e...@sanguine.whoi.edu as an alias 
for my address in ldap.  I want e...@sanguine.whoi.edu to continue 
delivery to my imap account.  In fact, that happened perfectly in my 
previous postfix configuration.  Since upgrading postfix, in order for 
that to continue working, I'm now hearing that I must specifically list 
sanguine.whoi.edu "somewhere" in my postfix configs.  That's not 
unreasonable, but let's now extend this example to another 250 hosts 
that are in a similar situation.  I must now specifically find, list and 
maintain all of 250 of those in some postfix config file and that 
there's no other way this will work as before?  That, to me, seems 
rather unreasonable.  Doesn't postfix have the capability to look up MX 
records for that purpose?

Re: Transport Maps Ignored After Upgrade

[/dev/rob0]

On Mon May 11 2009 12:08:02 Magnus Bäck wrote:
> On Monday, May 11, 2009 at 18:59 CEST,
>  /dev/rob0  wrote:
>
> [...]
>
> > BTW, I always use complete paths for lookups. I think "ldap:vldap"
> > defaults to "ldap:$config_directory/vldap", but it never hurts to
> > be specific, so you know what you're getting.
>
> ldap:vldap is the legacy configuration method where you'd define
> variables like
>
>vldap_server_host = ...
>vldap_search_base = ...
>
> in main.cf. Nothing wrong with that, but that use is deprecated.
>
> [...]

Thanks for the correction / explanation. I guess those settings in  
main.cf wouldn't show in "postconf -n".

On Mon May 11 2009 12:22:20 Eric Cunningham wrote:
> > ...
> >
> >> virtual_alias_domains = $virtual_alias_maps
> >> virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap
> >
> > These are all your address class definitions. We can't see into
> > your virtual_alias_maps to know what domains might be listed there.
> > You can show us "postmap -q sanguine.whoi.edu
> > hash:/etc/postfix/virtual" and "postmap -q sanguine.whoi.edu
> > ldap:vldap".
>
> Both of those postmap commands returned nothing.

As expected.

> >> May 11 12:25:34 obtest postfix/smtpd[4878]: NOQUEUE: reject: RCPT
> >> from web62403.mail.re1.yahoo.com[69.147.75.80]: 554 5.7.1
> >> : Relay access denied;
> >> from= to=
> >> proto=SMTP helo=
> >
> > So, sanguine.whoi.edu is apparently not in any of your address
> > class definitions. It doesn't matter what's in transport_maps for
> > this. And it's HIGHLY recommended that you do NOT use
> > transport_maps as a dual-use lookup as an address class definition,
> > because that could cause you to accept mail that's not yours.
>
> Correct, sanguine.whoi.edu isn't specifically listed in any of my
> address class definitions.  I'm using it for testing the MX relays,
> of which I have many.

Yet, DNS points to you:
sanguine.whoi.edu.  86400   IN  MX  10 obtest.whoi.edu.
obtest.whoi.edu.86400   IN  A   128.128.64.226

You either need to accept that mail (as a relay domain, perhaps) or 
change the MX to point to a host that will.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Transport Maps Ignored After Upgrade

[Noel Jones]

Eric Cunningham wrote:


May 11 12:24:19 obtest postfix/postfix-script[4849]: warning: 
/var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ


Fix the above error.  Probably not directly related to your 
problem, but might cause unexpected behavior.  The fix is 
probably just:


# cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf


May 11 12:25:34 obtest postfix/smtpd[4878]: NOQUEUE: reject: RCPT from 
web62403.mail.re1.yahoo.com[69.147.75.80]: 554 5.7.1 : Relay access 
denied; from= to= proto=SMTP 
helo=


Apparently, sanguine.whoi.edu not listed in any of the postfix 
address classes.  Which address class do you expect this to 
be?  Then you'll know where the domain must be listed.


This is one document you need to understand:
http://www.postfix.org/ADDRESS_CLASS_README.html

  -- Noel Jones

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

...

virtual_alias_domains = $virtual_alias_maps
virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap


These are all your address class definitions. We can't see into your 
virtual_alias_maps to know what domains might be listed there. You can 
show us "postmap -q sanguine.whoi.edu hash:/etc/postfix/virtual" and

"postmap -q sanguine.whoi.edu ldap:vldap".


Both of those postmap commands returned nothing.




BTW, I always use complete paths for lookups. I think "ldap:vldap" 
defaults to "ldap:$config_directory/vldap", but it never hurts to be 
specific, so you know what you're getting.



May 11 12:25:34 obtest postfix/smtpd[4878]: NOQUEUE: reject: RCPT
from web62403.mail.re1.yahoo.com[69.147.75.80]: 554 5.7.1
: Relay access denied;
from= to=
proto=SMTP helo=


So, sanguine.whoi.edu is apparently not in any of your address class 
definitions. It doesn't matter what's in transport_maps for this. And 
it's HIGHLY recommended that you do NOT use transport_maps as a 
dual-use lookup as an address class definition, because that could 
cause you to accept mail that's not yours.


Correct, sanguine.whoi.edu isn't specifically listed in any of my 
address class definitions.  I'm using it for testing the MX relays, of 
which I have many.

Re: Transport Maps Ignored After Upgrade

[Magnus Bäck]

On Monday, May 11, 2009 at 18:59 CEST,
 /dev/rob0  wrote:

[...]

> BTW, I always use complete paths for lookups. I think "ldap:vldap"
> defaults to "ldap:$config_directory/vldap", but it never hurts to
> be specific, so you know what you're getting.

ldap:vldap is the legacy configuration method where you'd define
variables like

   vldap_server_host = ...
   vldap_search_base = ...

in main.cf. Nothing wrong with that, but that use is deprecated.

[...]

-- 
Magnus Bäck
mag...@dsek.lth.se

Re: Transport Maps Ignored After Upgrade

[/dev/rob0]

On Mon May 11 2009 11:33:37 Eric Cunningham wrote:
> I guess I'm still missing something so here's my 'postfix -n' output
> and logfile showing the rejection.

> >>> for postfix to accept mail for a domain (from anywhere), the
> >>> domain needs to be found in one (and only one of):
> >>> - mydestination  (this is for mail delivered to a unix account)
> >>> - relay_domains  (this is for mail passed to another MTA)
> >>> - virtual_mailbox_domains  (this is for mail delivered to a
> >>> "virtual" user)
> >>> - virtual_alias_domains (this is for mail rewritten to another
> >>> address in another domain)
> >
> > as you can see, there is no *_recipient_maps here. if you get
> > "relay access denied", then the domain is not listed in one of the
> > above mentioned classes.
> >
> > if this sin't clear, please show rejection logs (unaltered,
> > unedited) as well as output of 'postconf -n' (because it probably
> > changed since your last post).

> mydestination = $myhostname, obtest.$mydomain, outbox.$mydomain, 
>   mail.$mydomain, localhost.$mydomain, localhost.localdomain,
>   localhost,  beachcomberscompanion.net,  whoi.net,  
>   oceansites.org, interridge.org
> myhostname = obtest.whoi.edu 
($mydomain is at the default, which should be "whoi.edu")
> relay_domains = $mydomain,  oceanus.whoi.edu,  
>   atlantis.whoi.edu   knorr.whoi.edu, bosun.whoi.edu,
>   striker.whoi.edu,   striker2.whoi.edu,  sssg1.whoi.edu
...
> virtual_alias_domains = $virtual_alias_maps
> virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap

These are all your address class definitions. We can't see into your 
virtual_alias_maps to know what domains might be listed there. You can 
show us "postmap -q sanguine.whoi.edu hash:/etc/postfix/virtual" and
"postmap -q sanguine.whoi.edu ldap:vldap".

BTW, I always use complete paths for lookups. I think "ldap:vldap" 
defaults to "ldap:$config_directory/vldap", but it never hurts to be 
specific, so you know what you're getting.

> May 11 12:25:34 obtest postfix/smtpd[4878]: NOQUEUE: reject: RCPT
> from web62403.mail.re1.yahoo.com[69.147.75.80]: 554 5.7.1
> : Relay access denied;
> from= to=
> proto=SMTP helo=

So, sanguine.whoi.edu is apparently not in any of your address class 
definitions. It doesn't matter what's in transport_maps for this. And 
it's HIGHLY recommended that you do NOT use transport_maps as a 
dual-use lookup as an address class definition, because that could 
cause you to accept mail that's not yours.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

I guess I'm still missing something so here's my 'postfix -n' output and 
logfile showing the rejection.


-Eric


for postfix to accept mail for a domain (from anywhere), the domain
needs to be found in one (and only one of):
- mydestination  (this is for mail delivered to a unix account)
- relay_domains  (this is for mail passed to another MTA)
- virtual_mailbox_domains  (this is for mail delivered to a "virtual"
user)
- virtual_alias_domains (this is for mail rewritten to another address
in another domain)


as you can see, there is no *_recipient_maps here. if you get "relay
access denied", then the domain is not listed in one of the above
mentioned classes.

if this sin't clear, please show rejection logs (unaltered, unedited) as
well as output of 'postconf -n' (because it probably changed since your
last post).


alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases, ldap:ldap
anvil_rate_time_unit = 60s
append_dot_mydomain = yes
body_checks = pcre:/etc/postfix/access/body_access
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] 
blocked using $rbl_domain${rbl_reason?; $rbl_reason}.  Contact 
 if this is in error.
header_checks = pcre:/etc/postfix/access/header_access
html_directory = /usr/share/doc/postfix/html
mailbox_size_limit = 0
message_size_limit = 104857600
mydestination = $myhostname, obtest.$mydomain, outbox.$mydomain,
mail.$mydomain, localhost.$mydomain, localhost.localdomain, localhost,  
beachcomberscompanion.net,  whoi.net,   oceansites.org, interridge.org
myhostname = obtest.whoi.edu
mynetworks = 128.128.0.0/16, 127.0.0.0/8, 199.92.168.150, 172.16.8.0/24
myorigin = $mydomain
parent_domain_matches_subdomains = 
permit_mx_backup_networks = $mynetworks
rbl_reply_maps = hash:/etc/postfix/access/dnsbl_replies
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydomain,  oceanus.whoi.edu,   atlantis.whoi.edu   
knorr.whoi.edu, bosun.whoi.edu, striker.whoi.edu,   striker2.whoi.edu,  
sssg1.whoi.edu
relayhost = 
relocated_maps = hash:/etc/postfix/relocated
setgid_group = postdrop
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_connection_rate_limit = 60
smtpd_client_message_rate_limit = 250
smtpd_client_new_tls_session_rate_limit = 60
smtpd_client_recipient_rate_limit = 300
smtpd_client_restrictions = check_client_access 
hash:/etc/postfix/access/connect_client_access
smtpd_error_sleep_time = 5s
smtpd_etrn_restrictions = permit_mynetworks, reject
smtpd_hard_error_limit = 20
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,
check_recipient_access pcre:/etc/postfix/access/final_recipient_access,
reject_unauth_pipelining,check_helo_access 
pcre:/etc/postfix/access/final_helo_access,check_client_access 
hash:/etc/postfix/access/final_client_access,check_sender_access 
pcre:/etc/postfix/access/final_sender_access,permit_mynetworks,  
permit_auth_destination,permit_mx_backup,
reject_unknown_sender_domain,reject_unauth_destination,
check_helo_access pcre:/etc/postfix/access/suspect_helo,
reject_rbl_client autospam.whoi.edu,reject_rhsbl_sender 
dsn.rfc-ignorant.org,   reject_rbl_client zen.spamhaus.org,
reject_rbl_client dnsbl.ahbl.org,reject_rbl_client 
http.dnsbl.sorbs.net,reject_rbl_client socks.dnsbl.sorbs.net,
reject_rbl_client misc.dnsbl.sorbs.net,reject_rbl_client 
web.dnsbl.sorbs.net,reject_rbl_client dul.dnsbl.sorbs.net,
reject_rbl_client list.dsbl.org,reject_rbl_client bl.spamcop.net,   
 reject_rbl_client cbl.abuseat.org,reject_rbl_client 
combined.njabl.org,reject_rbl_client bhnc.njabl.org
smtpd_restriction_classes = require_reverse_dns
smtpd_sasl_local_domain = 
smtpd_sasl_security_options = noanonymous
smtpd_soft_error_limit = 10
smtpd_tls_CAfile = /etc/postfix/tls/DigiCertCA.crt
smtpd_tls_cert_file = /etc/postfix/tls/star_whoi_edu.crt
smtpd_tls_key_file = /etc/postfix/tls/private.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_domains = $virtual_alias_maps
virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap
May 11 12:24:19 obtest postfix/postfix-script[4849]: warning: /var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ
May 11 12:24:19 obtest postfix/postfix-script[4871]: starting the Postfix mail system
May 11 12:24:19 obtest postfix/master[4872]: daemon started -- version 2.5.5, configuration /etc/postfix
May 11 12:25:34 obtest postfix/smtpd[4878]: connect from web62403.mail.re1.yahoo.com[69.147.75.80]
M

Re: Transport Maps Ignored After Upgrade

[mouss]

Eric Cunningham a écrit :
> Thanks mouss.   I removed $mynetworks from relay_domains and added the
> domains found in the transport map to relay_domains (while also keeping
> them in the transport map).  Relaying to those specific domains now works.
> 
> However, MX'd machines still suffer "relay access denied."  I introduced
> "relay_recipient_maps =" (both empty and with a file spec) to main.cf
> and with the file specified, tried adding each of the following as an
> entry to /etc/postfix/relay_recipients:
> 
> @whoi.edux
> @mxd-host.whoi.edux
> e...@mxd-host.whoi.edux
> 
> None of those entry attempts had an effect on the relay problem.  In
> fact, the mere introduction of relay_recipient_maps re-broke the
> just-fixed relaying.  What config parameters and possible values should
> I be looking at to try and resolve MX relay failures?  It isn't an
> option for me to specifically list all the MX hosts as there are
> hundreds and that list is not always static.  I'm certain Postfix must
> be capable of performing MX lookups and directing the emails accordingly.
> 

stop random experimentation. I said this:

>>
>> for postfix to accept mail for a domain (from anywhere), the domain
>> needs to be found in one (and only one of):
>> - mydestination  (this is for mail delivered to a unix account)
>> - relay_domains  (this is for mail passed to another MTA)
>> - virtual_mailbox_domains  (this is for mail delivered to a "virtual"
>> user)
>> - virtual_alias_domains (this is for mail rewritten to another address
>> in another domain)

as you can see, there is no *_recipient_maps here. if you get "relay
access denied", then the domain is not listed in one of the above
mentioned classes.

if this sin't clear, please show rejection logs (unaltered, unedited) as
well as output of 'postconf -n' (because it probably changed since your
last post).

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

Thanks mouss.   I removed $mynetworks from relay_domains and added the 
domains found in the transport map to relay_domains (while also keeping 
them in the transport map).  Relaying to those specific domains now works.


However, MX'd machines still suffer "relay access denied."  I introduced 
"relay_recipient_maps =" (both empty and with a file spec) to main.cf 
and with the file specified, tried adding each of the following as an 
entry to /etc/postfix/relay_recipients:


@whoi.edu   x
@mxd-host.whoi.edu  x
e...@mxd-host.whoi.edu  x

None of those entry attempts had an effect on the relay problem.  In 
fact, the mere introduction of relay_recipient_maps re-broke the 
just-fixed relaying.  What config parameters and possible values should 
I be looking at to try and resolve MX relay failures?  It isn't an 
option for me to specifically list all the MX hosts as there are 
hundreds and that list is not always static.  I'm certain Postfix must 
be capable of performing MX lookups and directing the emails accordingly.


-Eric


mouss wrote:

Eric Cunningham a écrit :

Thanks Victor.  Ok, so I:

- removed .$mydomain from $mydestination
- have set relay_domains = $mydestination, $mynetworks


do not do that. mydestination is for domains that should be delivered
locally. mynetworks have nothing to do with reception domains.



- have set parent_domain_matches_subdomains to it's default
- have added permit_mx_backup to smtpd_recipient_restrictions
- set permit_mx_backup_networks = $mynetworks

but I'm still unable to have email accepted for MX'ed hosts or those
hosts listed in my transport file due to "Relay access denied." 


you must understand that transport_maps is for routing. this doesn't
make mail acceptable.

for postfix to accept mail for a domain (from anywhere), the domain
needs to be found in one (and only one of):
- mydestination  (this is for mail delivered to a unix account)
- relay_domains  (this is for mail passed to another MTA)
- virtual_mailbox_domains  (this is for mail delivered to a "virtual" user)
- virtual_alias_domains (this is for mail rewritten to another address
in another domain)

Re: Transport Maps Ignored After Upgrade

[mouss]

Eric Cunningham a écrit :
> Thanks Victor.  Ok, so I:
> 
> - removed .$mydomain from $mydestination
> - have set relay_domains = $mydestination, $mynetworks

do not do that. mydestination is for domains that should be delivered
locally. mynetworks have nothing to do with reception domains.


> - have set parent_domain_matches_subdomains to it's default
> - have added permit_mx_backup to smtpd_recipient_restrictions
> - set permit_mx_backup_networks = $mynetworks
> 
> but I'm still unable to have email accepted for MX'ed hosts or those
> hosts listed in my transport file due to "Relay access denied." 

you must understand that transport_maps is for routing. this doesn't
make mail acceptable.

for postfix to accept mail for a domain (from anywhere), the domain
needs to be found in one (and only one of):
- mydestination  (this is for mail delivered to a unix account)
- relay_domains  (this is for mail passed to another MTA)
- virtual_mailbox_domains  (this is for mail delivered to a "virtual" user)
- virtual_alias_domains (this is for mail rewritten to another address
in another domain)



> Which,
> of these, or any other parameters, should I focus on to correct the
> denial?  I've attached a fresh postconf -n for a more detailed & updated
> picture.
> 
>[snip]

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

Thanks Victor.  Ok, so I:

- removed .$mydomain from $mydestination
- have set relay_domains = $mydestination, $mynetworks
- have set parent_domain_matches_subdomains to it's default
- have added permit_mx_backup to smtpd_recipient_restrictions
- set permit_mx_backup_networks = $mynetworks

but I'm still unable to have email accepted for MX'ed hosts or those 
hosts listed in my transport file due to "Relay access denied."  Which, 
of these, or any other parameters, should I focus on to correct the 
denial?  I've attached a fresh postconf -n for a more detailed & updated 
picture.


Regards,
-Eric

Victor Duchovni wrote:

On Fri, May 01, 2009 at 01:54:03PM -0400, Eric Cunningham wrote:

I think I've found a/the fix for re-enabling the original behavior of my 
transport maps and MX relaying.  I added .$mydomain to mydestination in 
main.cf.  This is in addition to $mydomain which was already in 
mydestination.


$mydomain vs. .$mydomain is subtle but apparently important.


Postfix will never search for ".example.com" domains in the
$mydestination list, so this change has no effect. Perhaps in making
this change you also triggered other changes that solved the problem.

Now, in fact, if you don't set "relay_domains" explicitly, as a matter
of regrettable backwards compatibility requirements, the value of
$relay_domains defaults to to "$mydestination" and in the context of
"$relay_domains", ".example.com" keys do come into play given an
appropriate setting of parent_domain_matches_subdomains.

The right solution is to set relay_domains explicitly and correctly,
rather than rely on side-effects from $mydestination.

Secondly, it appears that you have changed the default value of
parent_domain_matches_subdomains. You should review this parameter
and make sure you understand its impact.

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases, ldap:ldap
anvil_rate_time_unit = 60s
append_dot_mydomain = yes
body_checks = pcre:/etc/postfix/access/body_access
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] 
blocked using $rbl_domain${rbl_reason?; $rbl_reason}.  Contact 
 if this is in error.
header_checks = pcre:/etc/postfix/access/header_access
html_directory = /usr/share/doc/postfix/html
mailbox_size_limit = 0
message_size_limit = 104857600
mydestination = $myhostname, $mydomain, postal1.$mydomain, outbox.$mydomain,
mail.$mydomain, localhost.$mydomain, localhost.localdomain, localhost,  
beachcomberscompanion.net,  whoi.net,   oceansites.org, interridge.org
myhostname = postal1.whoi.edu
mynetworks = 128.128.0.0/16, 127.0.0.0/8, 199.92.168.150, 172.16.8.0/24
myorigin = $mydomain
parent_domain_matches_subdomains = 
permit_mx_backup_networks = $mynetworks
rbl_reply_maps = hash:/etc/postfix/access/dnsbl_replies
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination, $mynetworks
relayhost = 
relocated_maps = hash:/etc/postfix/relocated
setgid_group = postdrop
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_connection_rate_limit = 60
smtpd_client_message_rate_limit = 250
smtpd_client_new_tls_session_rate_limit = 60
smtpd_client_recipient_rate_limit = 300
smtpd_client_restrictions = check_client_access 
hash:/etc/postfix/access/connect_client_access
smtpd_error_sleep_time = 5s
smtpd_etrn_restrictions = permit_mynetworks, reject
smtpd_hard_error_limit = 20
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,
check_recipient_access pcre:/etc/postfix/access/final_recipient_access,
reject_unauth_pipelining,check_helo_access 
pcre:/etc/postfix/access/final_helo_access,check_client_access 
hash:/etc/postfix/access/final_client_access,check_sender_access 
pcre:/etc/postfix/access/final_sender_access,permit_mynetworks,  
permit_auth_destination,permit_mx_backup,
reject_unknown_sender_domain,reject_unauth_destination,
check_helo_access pcre:/etc/postfix/access/suspect_helo,
reject_rbl_client autospam.whoi.edu,reject_rhsbl_sender 
dsn.rfc-ignorant.org,   reject_rbl_client zen.spamhaus.org,
reject_rbl_client dnsbl.ahbl.org,reject_rbl_client 
http.dnsbl.sorbs.net,reject_rbl_client socks.dnsbl.sorbs.net,
reject_rbl_client misc.dnsbl.sorbs.net,reject_rbl_client 
web.dnsbl.sorbs.net,reject_rbl_client dul.dnsbl.sorbs.net,
reject_rbl_client list.dsbl.org,reject_rbl_client bl.spamcop.net,   
 reject_rbl_client cbl.abuseat.org,reject_rbl_client 
combined.njabl.org,reject_rbl_client bhnc.njabl.org
smtpd_restriction_classes = require_reverse_dns
smtpd_sasl_local_domain = 
smtpd_sasl_security_options = noanonymous
smtpd_soft_error_limit = 

Re: Transport Maps Ignored After Upgrade

[Victor Duchovni]

On Fri, May 01, 2009 at 01:54:03PM -0400, Eric Cunningham wrote:

> I think I've found a/the fix for re-enabling the original behavior of my 
> transport maps and MX relaying.  I added .$mydomain to mydestination in 
> main.cf.  This is in addition to $mydomain which was already in 
> mydestination.
>
> $mydomain vs. .$mydomain is subtle but apparently important.

Postfix will never search for ".example.com" domains in the
$mydestination list, so this change has no effect. Perhaps in making
this change you also triggered other changes that solved the problem.

Now, in fact, if you don't set "relay_domains" explicitly, as a matter
of regrettable backwards compatibility requirements, the value of
$relay_domains defaults to to "$mydestination" and in the context of
"$relay_domains", ".example.com" keys do come into play given an
appropriate setting of parent_domain_matches_subdomains.

The right solution is to set relay_domains explicitly and correctly,
rather than rely on side-effects from $mydestination.

Secondly, it appears that you have changed the default value of
parent_domain_matches_subdomains. You should review this parameter
and make sure you understand its impact.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

I think I've found a/the fix for re-enabling the original behavior of my 
transport maps and MX relaying.  I added .$mydomain to mydestination in 
main.cf.  This is in addition to $mydomain which was already in 
mydestination.


$mydomain vs. .$mydomain is subtle but apparently important.

Re: Transport Maps Ignored After Upgrade

[Wietse Venema]

Eric Cunningham:
> > transport_maps simply routes accepted messages by overriding DNS.
> 
> That's what I want to continue to do, as had occurred happily before the 
> postfix upgrade.
> 
> > To accept mail, the envelope recipient *must* be in mydestination,
> > relay_domains, virtual_alias_domains or virtual_mailbox_domains.
> > All may be a type:table input for lookups.
> > 
> > You should have *one* domain in *one* address class.
> > 
> > See http://www.postfix.org/ADDRESS_CLASS_README.html for details
> 
> That's all well and good, but I shouldn't need to list all the MX'ed 
> machines in any of those.

Yes, you do. If you don't list a domain in some class, then Postfix
will reject its mail with Relay access denied.

Wietse

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

transport_maps simply routes accepted messages by overriding DNS.


That's what I want to continue to do, as had occurred happily before the 
postfix upgrade.



To accept mail, the envelope recipient *must* be in mydestination,
relay_domains, virtual_alias_domains or virtual_mailbox_domains.
All may be a type:table input for lookups.

You should have *one* domain in *one* address class.

See http://www.postfix.org/ADDRESS_CLASS_README.html for details


That's all well and good, but I shouldn't need to list all the MX'ed 
machines in any of those.


-Eric

Re: Transport Maps Ignored After Upgrade

[Wietse Venema]

Eric Cunningham:
[ Charset ISO-8859-1 unsupported, converting... ]
> > Why don't you simply restore the old working main.cf and master.cf
> > files, and then execute as root:
> > 
> > # postfix upgrade-configuration
> > 
> > This is easier that trying to figure out how to rebuild the old
> > configuration from scratch.
> > 
> > PS If the recipient domains are not local, then they must be listed
> > in main.cf:relay_domain. This has always been required since before
> > Postfix was released in 11 years ago.
> > 
> > Wietse
> > 
> 
> 
> Tnank you, Wietse.  I tried restoring the working main.cf & master.cf 
> and ran postfix upgrade-configuration but the result is still the same- 
> relay access denied.  All of the recipient domains -are- local.

Your logging shows that recipients are delivered via SMTP to
a different system. Therefore they are NOT LOCAL.

Wietse

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

Why don't you simply restore the old working main.cf and master.cf
files, and then execute as root:

# postfix upgrade-configuration

This is easier that trying to figure out how to rebuild the old
configuration from scratch.

PS If the recipient domains are not local, then they must be listed
in main.cf:relay_domain. This has always been required since before
Postfix was released in 11 years ago.

Wietse




Tnank you, Wietse.  I tried restoring the working main.cf & master.cf 
and ran postfix upgrade-configuration but the result is still the same- 
relay access denied.  All of the recipient domains -are- local.


-Eric

Re: Transport Maps Ignored After Upgrade

[Wietse Venema]

Eric Cunningham:
> I just upgraded to postfix 2.5.5 from 2.3.  Now, it seems my previously 
> working transport maps are ignored as are hosts that are MX'ed to the 
> machine running postfix.  In both cases, email are rejected with "Relay 
> access denied."

Why don't you simply restore the old working main.cf and master.cf
files, and then execute as root:

# postfix upgrade-configuration

This is easier that trying to figure out how to rebuild the old
configuration from scratch.

PS If the recipient domains are not local, then they must be listed
in main.cf:relay_domain. This has always been required since before
Postfix was released in 11 years ago.

Wietse

Re: Transport Maps Ignored After Upgrade

[Brian Evans - Postfix List]

Eric Cunningham wrote:
> I just upgraded to postfix 2.5.5 from 2.3.  Now, it seems my
> previously working transport maps are ignored as are hosts that are
> MX'ed to the machine running postfix.  In both cases, email are
> rejected with "Relay access denied."
> Sorry, thank you for the clarification, Brian.  'postconf -n' output
> is now attached.  I've already run 'postmap transport' and 'postfix
> reload' but that didn't help.
>
> I did find a quasi-workaround to this by adding the subdomains from
> transport to relay_domains but that will be clumsy at best as my site
> has perhaps hundreds of MX records, that if not all used, should at
> least be in effect.
transport_maps simply routes accepted messages by overriding DNS.

To accept mail, the envelope recipient *must* be in mydestination,
relay_domains, virtual_alias_domains or virtual_mailbox_domains.
All may be a type:table input for lookups.

You should have *one* domain in *one* address class.

See http://www.postfix.org/ADDRESS_CLASS_README.html for details

Re: Transport Maps Ignored After Upgrade

[Eric Cunningham]

Sorry, thank you for the clarification, Brian.  'postconf -n' output is 
now attached.  I've already run 'postmap transport' and 'postfix reload' 
but that didn't help.


I did find a quasi-workaround to this by adding the subdomains from 
transport to relay_domains but that will be clumsy at best as my site 
has perhaps hundreds of MX records, that if not all used, should at 
least be in effect.


-Eric


'postconf -d' shows the defaults of how Postfix ships with no main.cf
You should look at 'postconf -n' and report here if still confused.
Full logs will help us too for a transaction.

In addition, you may need to redo postmap on transport if it was a full
system upgrade and the back-end db version changed.

Brian

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases, ldap:ldap
anvil_rate_time_unit = 60s
append_dot_mydomain = yes
body_checks = pcre:/etc/postfix/access/body_access
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] 
blocked using $rbl_domain${rbl_reason?; $rbl_reason}.  Contact 
 if this is in error.
header_checks = pcre:/etc/postfix/access/header_access
html_directory = /usr/share/doc/postfix/html
mailbox_size_limit = 0
message_size_limit = 104857600
mydestination = $myhostname, $mydomain, postal2.$mydomain, outbox.$mydomain,
mail.$mydomain, localhost.localdomain, localhost,   
beachcomberscompanion.net,  whoi.net,   oceansites.org, interridge.org
myhostname = postal2.whoi.edu
mynetworks = 128.128.0.0/16, 127.0.0.0/8, 199.92.168.150, 172.16.8.0/24
myorigin = $mydomain
rbl_reply_maps = hash:/etc/postfix/access/dnsbl_replies
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination, $mynetworks,oceanus.whoi.edu,   
atlantis.whoi.edu,  knorr.whoi.edu, bosun.whoi.edu, 
striker2.whoi.edu,  striker.whoi.edu,   sssg1.whoi.edu  gb6.whoi.edu
relayhost = 
relocated_maps = hash:/etc/postfix/relocated
setgid_group = postdrop
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_connection_rate_limit = 60
smtpd_client_message_rate_limit = 250
smtpd_client_new_tls_session_rate_limit = 60
smtpd_client_recipient_rate_limit = 300
smtpd_client_restrictions = check_client_access 
hash:/etc/postfix/access/connect_client_access
smtpd_error_sleep_time = 5s
smtpd_etrn_restrictions = permit_mynetworks, reject
smtpd_hard_error_limit = 20
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,
check_recipient_access pcre:/etc/postfix/access/final_recipient_access,
reject_unauth_pipelining,check_helo_access 
pcre:/etc/postfix/access/final_helo_access,check_client_access 
hash:/etc/postfix/access/final_client_access,check_sender_access 
pcre:/etc/postfix/access/final_sender_access,permit_mynetworks,
reject_unknown_sender_domain,reject_unauth_destination,
check_helo_access pcre:/etc/postfix/access/suspect_helo,
reject_rbl_client autospam.whoi.edu,reject_rhsbl_sender 
dsn.rfc-ignorant.org,  reject_rbl_client zen.spamhaus.org,
reject_rbl_client dnsbl.ahbl.org,reject_rbl_client 
http.dnsbl.sorbs.net,reject_rbl_client socks.dnsbl.sorbs.net,
reject_rbl_client misc.dnsbl.sorbs.net,reject_rbl_client 
web.dnsbl.sorbs.net,reject_rbl_client dul.dnsbl.sorbs.net,
reject_rbl_client list.dsbl.org,reject_rbl_client bl.spamcop.net,   
 reject_rbl_client cbl.abuseat.org,reject_rbl_client 
combined.njabl.org,reject_rbl_client bhnc.njabl.org
smtpd_restriction_classes = require_reverse_dns
smtpd_sasl_local_domain = 
smtpd_sasl_security_options = noanonymous
smtpd_soft_error_limit = 10
smtpd_tls_CAfile = /etc/postfix/tls/DigiCertCA.crt
smtpd_tls_cert_file = /etc/postfix/tls/star_whoi_edu.crt
smtpd_tls_key_file = /etc/postfix/tls/private.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_domains = $virtual_alias_maps
virtual_alias_maps = hash:/etc/postfix/virtual, ldap:vldap

Re: Transport Maps Ignored After Upgrade

[Brian Evans - Postfix List]

Eric Cunningham wrote:
> I just upgraded to postfix 2.5.5 from 2.3.  Now, it seems my
> previously working transport maps are ignored as are hosts that are
> MX'ed to the machine running postfix.  In both cases, email are
> rejected with "Relay access denied."
>
> I note in the attached 'postconf -d' output that transport_maps is not
> defined although I do have a transport file:
>
> # ls -l /etc/postfix/transport*
> -rw-r--r-- 1 root root 10429 2009-04-27 12:21 /etc/postfix/transport
> -rw-r--r-- 1 root root 12288 2009-04-29 14:49 /etc/postfix/transport.db
'postconf -d' shows the defaults of how Postfix ships with no main.cf
You should look at 'postconf -n' and report here if still confused.
Full logs will help us too for a transaction.

In addition, you may need to redo postmap on transport if it was a full
system upgrade and the back-end db version changed.

Brian