ldap help needed.

[Marko Weber | ZBF]

hello list,

on debian 7.5 i installed postfix 2.9.6 with postfix-ldap package.

in the main.cf:

...


  ldap_transport_result_filter = smtp:%s.24t.loc:25

virtual_mailbox_maps =
ldap:ldap_users

## wichtig!! ldap:ldap_users muss hier mit aufgefuehrt werden, sonst 
werden alle Mails

## an den catch_all Eintrag geschickt

virtual_alias_maps =
ldap:ldap_aliases
ldap:ldap_groups
ldap:ldap_users
hash:/etc/postfix/lookups/hash/catchall_1
hash:/etc/postfix/lookups/hash/catchall_2

transport_maps =
ldap:ldap_transport
...
...
...


on restart of postfix i get:

[] Stopping Postfix Mail Transport Agent: postfix/usr/sbin/postconf: 
warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25

. ok
[] Starting Postfix Mail Transport Agent: postfixpostconf: warning: 
/etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25
/usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: 
ldap_transport_result_filter=smtp:%s.24t.loc:25



on console an fired up # postmap -q m.we...@hiddendomain.de 
ldap:ldap_transport - i get:


smtp:zara3.24t.loc:25 ( the right one zaraf server where mail should go 
to)


why does it work on console, but not on restart postfix?

thank you

marko

Re: ldap help needed.

[Wietse Venema]

> [] Stopping Postfix Mail Transport Agent: postfix/usr/sbin/postconf: 
> warning: /etc/postfix/main.cf: unused parameter: 
> ldap_transport_result_filter=smtp:%s.24t.loc:25

Apparently, postconf 2.9-2.12 error checking for "legacy DBMS
support" is incomplete. You will get correct result with
the preferred database configuration method:

/etc/postfix/main.cf:
transport_maps = ldap:/path/to/file

/path/to/file:
result_filter=smtp:%s.24t.loc:25

(this will also allow you to store LDAP passwords in a file that
is not world-readable).

The problem with "legacy support" is that it will eventually
start to rot.

Wietse

Re: ldap help needed.

[Wietse Venema]

Wietse Venema:
> > [] Stopping Postfix Mail Transport Agent: postfix/usr/sbin/postconf: 
> > warning: /etc/postfix/main.cf: unused parameter: 
> > ldap_transport_result_filter=smtp:%s.24t.loc:25
> 
> Apparently, postconf 2.9-2.12 error checking for "legacy DBMS
> support" is incomplete. You will get correct result with

Actually, "result_filter" is deprecated since Postfix 2.2. You're
supposed to use "result_format" instead.

Then. postconf will not report this warning.

You have been relying on two levels of backwards-compatibility
support. That's too much, even for Postfix.

Wietse
 
> the preferred database configuration method:
> 
> /etc/postfix/main.cf:
> transport_maps = ldap:/path/to/file
> 
> /path/to/file:
> result_filter=smtp:%s.24t.loc:25
> 
> (this will also allow you to store LDAP passwords in a file that
> is not world-readable).
> 
> The problem with "legacy support" is that it will eventually
> start to rot.
> 
>   Wietse
> 

Re: ldap help needed.

[Viktor Dukhovni]

On Tue, Jun 17, 2014 at 09:11:15AM -0400, Wietse Venema wrote:

> > [] Stopping Postfix Mail Transport Agent: postfix/usr/sbin/postconf: 
> > warning: /etc/postfix/main.cf: unused parameter: 
> > ldap_transport_result_filter=smtp:%s.24t.loc:25
> 
> Apparently, postconf 2.9-2.12 error checking for "legacy DBMS
> support" is incomplete. You will get correct result with
> the preferred database configuration method:
> 
> /etc/postfix/main.cf:
> transport_maps = ldap:/path/to/file
> 
> /path/to/file:
> result_filter=smtp:%s.24t.loc:25

Also note that the non-legacy name "result_format" does not generate
any warnings.

-- 
Viktor.

Regarding smtpd_recipient_limit

[Joy]

Dear All,
  I  want to restrict users to not send more than 5
recipient in TO/CC/BCC to external recipient so i have implemented one
relay server to restrict the same. I configured my relay server with
following line in main.cf

  smtpd_recipient_limit = 5

I reloaded the server but so far no success while all is running well mail
is being delivered through relay server to external recipient.

Please let me know what is going wrong.

Re: Regarding smtpd_recipient_limit

[Noel Jones]

On 6/17/2014 11:06 AM, Joy wrote:
> Dear All,
>   I  want to restrict users to not send more than 5
> recipient in TO/CC/BCC to external recipient so i have implemented
> one relay server to restrict the same. I configured my relay server
> with following line in main.cf 
> 
>   smtpd_recipient_limit = 5
> 
> I reloaded the server but so far no success while all is running
> well mail is being delivered through relay server to external
> recipient. 
> 
> Please let me know what is going wrong.

The smtpd_recipient_limit isn't intended for that purpose.  You'll
need some sort of policy server to do what you ask.  Or maybe some
milter has that ability.
http://www.postfix.org/SMTPD_POLICY_README.html


  -- Noel Jones

Re: SMTP starttls / DANE TLS

[Per Thorsheim]

Den 16.06.2014 17:18, skrev Viktor Dukhovni:
> On Mon, Jun 16, 2014 at 10:12:03AM +0200, Per Thorsheim wrote:
>
>> https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/
>> "In WG Last Call"
>>
>> Any estimate on when this might become final Viktor?
> With any luck, around July IETF.  The WG chairs are trying to
> coordinate progress on both the SMTP and the SRV drafts.  I used
> the pause in the original last call to make various improvements.
>
Sounds good, look forward to see it finalised. Blogged this today:
https://starttls.info/blog/from-zero-to-hero-in-no-time/

ACLU, EFF and many others are now actively promoting starttls
deployment, as you may have seen from the past few weeks with lots of
services announcing support and implementing it quickly. Next step, if
I'm not completly wrong, is to get TLDs to use DNSSEC if they haven't
got it already, then deploy it for your own domains, and then hopefully
your DANE TLS proposal.

I really hope that will catch on and be deployed faster than we've
waited for RFC3207.

Br,
Per

Re: SMTP starttls / DANE TLS

[Viktor Dukhovni]

On Tue, Jun 17, 2014 at 08:39:38PM +0200, Per Thorsheim wrote:

> Sounds good, look forward to see it finalised. Blogged this today:
> https://starttls.info/blog/from-zero-to-hero-in-no-time/
> 
> ACLU, EFF and many others are now actively promoting starttls
> deployment, as you may have seen from the past few weeks with lots of
> services announcing support and implementing it quickly. Next step, if
> I'm not completly wrong, is to get TLDs to use DNSSEC if they haven't
> got it already, then deploy it for your own domains, and then hopefully
> your DANE TLS proposal.
> 
> I really hope that will catch on and be deployed faster than we've
> waited for RFC3207.

Thanks for fighting the good fight.  In the mean-time, any chance
you could stop fix the misleading TLS support scores starttls.info
issues to soundly configured MTAs?

* For SMTP, self-signed certificates are as good as CA issued
  certificates.  The hostname in the certificate is irrelevant.

* For SMTP servers support for anon-DH cipher-suites is a feature,
  not a bug.

* For opportunistic TLS, even the weakest ciphers are fine,
  provided strong ones are preferred when offered.

Almost every score-lowering observation leading to 43.5% D for
dukhovni.org is wrong.

-- 
Viktor.

Re: SMTP starttls / DANE TLS

[Per Thorsheim]

Den 17.06.2014 20:59, skrev Viktor Dukhovni:
> Thanks for fighting the good fight.  In the mean-time, any chance
> you could stop fix the misleading TLS support scores starttls.info
> issues to soundly configured MTAs?
>
> * For SMTP, self-signed certificates are as good as CA issued
>   certificates.  The hostname in the certificate is irrelevant.
>
> * For SMTP servers support for anon-DH cipher-suites is a feature,
>   not a bug.
>
> * For opportunistic TLS, even the weakest ciphers are fine,
>   provided strong ones are preferred when offered.
>
> Almost every score-lowering observation leading to 43.5% D for
> dukhovni.org is wrong.
>
I talked to Einar today, my friend who made the service on my request.
We agreed to simplify the scoring, at first down to "passed" as long as
we see starttls support with minimum SSLv3 and no export 40/56bit.

We'll recommend supporting TLSv1.1/2 and using a cert from a TTP, and
probably display the preferred cipher suite from the server, if any.
Will probably not let this affect scoring in any direction, and inform
about your proposal, and recommend DNSSEC deployment in the meantime.

Br,
Per

Re: SMTP starttls / DANE TLS

[Viktor Dukhovni]

On Tue, Jun 17, 2014 at 09:09:31PM +0200, Per Thorsheim wrote:

> Den 17.06.2014 20:59, skrev Viktor Dukhovni:
>
> > Thanks for fighting the good fight.  In the mean-time, any chance
> > you could stop fix the misleading TLS support scores starttls.info
> > issues to soundly configured MTAs?
>
> I talked to Einar today, my friend who made the service on my request.
> We agreed to simplify the scoring, at first down to "passed" as long as
> we see starttls support with minimum SSLv3 and no export 40/56bit.

That's still too rigid for opportunistic TLS, Postfix servers
currently and for the forseeable future explicitly default to
support export and low grade ciphers, because again, these are
strictly better than cleartext.  What reason is there to disable
them?

Pass, means implements STARTTLS, brownie points for PFS support.
The rest is at best misleading to down-right counter-productive.

> We'll recommend supporting TLSv1.1/2 and using a cert from a TTP, and
> probably display the preferred cipher suite from the server, if any.

If you want people to throw cash away, just publish appropriate
charities for people to donate money to.  Throwing the money away
on certificates nobody checks seems silly.

> Will probably not let this affect scoring in any direction, and inform
> about your proposal, and recommend DNSSEC deployment in the meantime.

Please make substantially more radical changes, that take into account
that opportunistic TLS in SMTP is very different from TLS in HTTPS.

-- 
Viktor.

smtpd access checks without checking virtual_alias_maps - howto ?

[uffe]

Hi,

I'm trying to configure postfix to perform smtpd access checks -
specifically recipient check/restrictions - but without having it consult
its virtual_alias_maps.

I'm heavily depending on catchall constructions in virtual_aliases for
further "virtual routing" 
The catchall constructs in my virtual_alias_maps seem to break all recipient
checks/restriction for me.

Can anyone come up with a way (configurtion) for smtpd to check for valid
recipients in a map - and keep it away from looking into virtual_alias_maps
while performing recipient validation ?

BTW I really miss a doc/drawing - explaining the order of smtpd access
checks in respect to virtual_alias_maps lookups - any pointers ?

Thanks in advance 

/Uffe




--
View this message in context: 
http://postfix.1071664.n5.nabble.com/smtpd-access-checks-without-checking-virtual-alias-maps-howto-tp68634.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: smtpd access checks without checking virtual_alias_maps - howto ?

[Noel Jones]

On 6/17/2014 3:48 PM, uffe wrote:
> Hi,
> 
> I'm trying to configure postfix to perform smtpd access checks -
> specifically recipient check/restrictions - but without having it consult
> its virtual_alias_maps.
> 
> I'm heavily depending on catchall constructions in virtual_aliases for
> further "virtual routing" 
> The catchall constructs in my virtual_alias_maps seem to break all recipient
> checks/restriction for me.

Yes, this is a known limitation of catchalls, and a very good reason
to avoid them.

> 
> Can anyone come up with a way (configurtion) for smtpd to check for valid
> recipients in a map - and keep it away from looking into virtual_alias_maps
> while performing recipient validation ?

You can use a check_recipient_access map and then reject any local
recipient not listed in the map.  But if you already have a map,
seems like you could eliminate the troublesome catchall without
resorting to oddball hacks.

Something like:
main.cf:
## do this in sender checks to not become an open relay
smtpd_sender_restrictions =
  check_recipient_access hash:/etc/postfix/valid_recipients
  check_recipient_access regexp:/etc/postfix/reject_all_local.regexp

# valid_recipients
## list all valid recipients here
us...@example.com  OK
us...@example.com  OK
...

# reject_all_local.regexp
## valid recipients already permitted, so only invalid are left.
/@example\.com$/  REJECT unknown recipient


If there aren't too many valid recipients, you can do the whole
thing in a single regexp file with the last entry as the default
REJECT, but the syntax and scaling is easier with indexed tables.


> 
> BTW I really miss a doc/drawing - explaining the order of smtpd access
> checks in respect to virtual_alias_maps lookups - any pointers ?

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




  -- Noel Jones

Re: smtpd access checks without checking virtual_alias_maps - howto ?

[Viktor Dukhovni]

On Tue, Jun 17, 2014 at 01:48:49PM -0700, uffe wrote:

> I'm trying to configure postfix to perform smtpd access checks -
> specifically recipient check/restrictions - but without having it consult
> its virtual_alias_maps.

Sorry, that's not possible.  The SMTP server will use whatever
virtual(5) aliases it is configured with to validate input recipients.

> Can anyone come up with a way (configurtion) for smtpd to check for valid
> recipients in a map - and keep it away from looking into virtual_alias_maps
> while performing recipient validation ?

Define virtual alias maps for smtpd(8) to look at a different set of
tables than cleanup(8).


> BTW I really miss a doc/drawing - explaining the order of smtpd access
> checks in respect to virtual_alias_maps lookups - any pointers ?

http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_recipient
http://www.postfix.org/postconf.5.html#reject_unlisted_recipient

-- 
Viktor.

Re: smtpd access checks without checking virtual_alias_maps - howto ?

[Uffe Jakobsen]

On 2014-06-17 23:18, Noel Jones wrote:

On 6/17/2014 3:48 PM, uffe wrote:

Hi,

I'm trying to configure postfix to perform smtpd access checks -
specifically recipient check/restrictions - but without having it consult
its virtual_alias_maps.

I'm heavily depending on catchall constructions in virtual_aliases for
further "virtual routing"
The catchall constructs in my virtual_alias_maps seem to break all recipient
checks/restriction for me.


Yes, this is a known limitation of catchalls, and a very good reason
to avoid them.


damn it would be nice with another (new) set of virtual_route_aliases 
that would not be considered before the email was accepted by smtpd.






Can anyone come up with a way (configurtion) for smtpd to check for valid
recipients in a map - and keep it away from looking into virtual_alias_maps
while performing recipient validation ?


You can use a check_recipient_access map and then reject any local
recipient not listed in the map.  But if you already have a map,
seems like you could eliminate the troublesome catchall without
resorting to oddball hacks.

Something like:
main.cf:
## do this in sender checks to not become an open relay
smtpd_sender_restrictions =
   check_recipient_access hash:/etc/postfix/valid_recipients
   check_recipient_access regexp:/etc/postfix/reject_all_local.regexp

# valid_recipients
## list all valid recipients here
us...@example.com  OK
us...@example.com  OK
...

# reject_all_local.regexp
## valid recipients already permitted, so only invalid are left.
/@example\.com$/  REJECT unknown recipient


If there aren't too many valid recipients, you can do the whole
thing in a single regexp file with the last entry as the default
REJECT, but the syntax and scaling is easier with indexed tables.




Ok will need to do some testing - unfortunately my setup is not straight 
forward simple - lots of domains etc.


Thanks

/Uffe

Re: smtpd access checks without checking virtual_alias_maps - howto ?

[Uffe Jakobsen]

On 2014-06-17 23:21, Viktor Dukhovni wrote:

On Tue, Jun 17, 2014 at 01:48:49PM -0700, uffe wrote:


I'm trying to configure postfix to perform smtpd access checks -
specifically recipient check/restrictions - but without having it consult
its virtual_alias_maps.


Sorry, that's not possible.  The SMTP server will use whatever
virtual(5) aliases it is configured with to validate input recipients.



damn, qmail could do this stuff out-of-the-box.

To me it would make sense to have virtual_routing_alias_maps that would 
be evaluated after smtpd checks.



Can anyone come up with a way (configurtion) for smtpd to check for valid
recipients in a map - and keep it away from looking into virtual_alias_maps
while performing recipient validation ?


Define virtual alias maps for smtpd(8) to look at a different set of
tables than cleanup(8).



By this I guess you mean compiling a home made postfix with the above 
changes ?



Thanks for your feedback

/Uffe

Re: smtpd access checks without checking virtual_alias_maps - howto ?

[Viktor Dukhovni]

On Wed, Jun 18, 2014 at 12:00:03AM +0200, Uffe Jakobsen wrote:

> >Sorry, that's not possible.  The SMTP server will use whatever
> >virtual(5) aliases it is configured with to validate input recipients.
> 
> damn, qmail could do this stuff out-of-the-box.
> 
> To me it would make sense to have virtual_routing_alias_maps that would be
> evaluated after smtpd checks.

No, see below.

> >>Can anyone come up with a way (configurtion) for smtpd to check for valid
> >>recipients in a map - and keep it away from looking into virtual_alias_maps
> >>while performing recipient validation ?
> >
> >Define virtual alias maps for smtpd(8) to look at a different set of
> >tables than cleanup(8).
> 
> By this I guess you mean compiling a home made postfix with the above
> changes ?

No, I mean a master.cf override:

main.cf:
smtpd_valias_maps = ...

master.cf:
smtp inet ... smtpd
-o virtual_alias_maps=$smtpd_valias_maps

Actual rewriting is done by cleanup(8).  At this time, the Postfix
SMTP server (aka smtpd(8)) *only* uses virtual_alias_maps for
recipient validation, not for rewriting.  Note this may change in
some future release.

-- 
Viktor.

Re: smtpd access checks without checking virtual_alias_maps - howto ?

[Uffe Jakobsen]

On 2014-06-18 00:08, Viktor Dukhovni wrote:

On Wed, Jun 18, 2014 at 12:00:03AM +0200, Uffe Jakobsen wrote:


Can anyone come up with a way (configurtion) for smtpd to check for valid
recipients in a map - and keep it away from looking into virtual_alias_maps
while performing recipient validation ?


Define virtual alias maps for smtpd(8) to look at a different set of
tables than cleanup(8).


By this I guess you mean compiling a home made postfix with the above
changes ?


No, I mean a master.cf override:

 main.cf:
smtpd_valias_maps = ...

 master.cf:
smtp inet ... smtpd
-o virtual_alias_maps=$smtpd_valias_maps

Actual rewriting is done by cleanup(8).  At this time, the Postfix
SMTP server (aka smtpd(8)) *only* uses virtual_alias_maps for
recipient validation, not for rewriting.  Note this may change in
some future release.



Aha I see - what fantastic suggestion !!!

I just implemented a setup similar to your suggestion - and now postfix 
 works just the way that I was looking for.


Viktor - you just saved my day - and I just learned a little more about 
postfix :-)


Thanks :-)

/Uffe

Multiple Targets on transport map

[Joey J]

We have 2 gateway servers in multiple locations so that we have redundancy
and of course corresponding mx records pointing to both.
This handles if GW1 fails, go to GW2

Now once at a GW the transport map handles the routing of the messages for
domain.com as shown:
domain.com   smtp:[1.2.3.4]

However, lets say that server is at a location/building which has 2
internet connections, (primary) using 1.2.3.4 and (secondary) using
8.9.10.11
and the primary connection fails.

My servers will queue the mail since it can't communicate with 1.2.3.4.

What I would like to do is have our server try to deliver to 1.2.3.4 but if
that fails try to deliver to 8.9.10.11 much in the same way as MX records
function.

I'm not seeing a way to accomplish this, any suggestions, or examples?


-- 
Thanks!
Joey

Re: Multiple Targets on transport map

[Noel Jones]

On 6/17/2014 8:30 PM, Joey J wrote:
> We have 2 gateway servers in multiple locations so that we have
> redundancy and of course corresponding mx records pointing to both.
> This handles if GW1 fails, go to GW2
> 
> Now once at a GW the transport map handles the routing of the
> messages for domain.com  as shown:
> domain.com    smtp:[1.2.3.4]
> 
> However, lets say that server is at a location/building which has 2
> internet connections, (primary) using 1.2.3.4 and (secondary) using
> 8.9.10.11
> and the primary connection fails.
> 
> My servers will queue the mail since it can't communicate with 1.2.3.4.
> 
> What I would like to do is have our server try to deliver to 1.2.3.4
> but if that fails try to deliver to 8.9.10.11 much in the same way
> as MX records function.
> 
> I'm not seeing a way to accomplish this, any suggestions, or examples?
> 
> 
> -- 
> Thanks!
> Joey
> 


Transport maps are intended as static routing to override standard
MX records, not as a replacement for MX records. As such, postfix
has no support for multiple transport targets nor "weighted"
transport tables.

Solutions would include localized or split horizon MX records, or
use a network routing protocol that will cause the kernel IP stack
to select the preferred route.



  -- Noel Jones

Re: Multiple Targets on transport map

[Jose Borges Ferreira]

On Wed, Jun 18, 2014 at 2:30 AM, Joey J  wrote:
> We have 2 gateway servers in multiple locations so that we have redundancy
> and of course corresponding mx records pointing to both.
> This handles if GW1 fails, go to GW2
>
> Now once at a GW the transport map handles the routing of the messages for
> domain.com as shown:
> domain.com   smtp:[1.2.3.4]
>
> However, lets say that server is at a location/building which has 2 internet
> connections, (primary) using 1.2.3.4 and (secondary) using 8.9.10.11
> and the primary connection fails.
>
> My servers will queue the mail since it can't communicate with 1.2.3.4.
>
> What I would like to do is have our server try to deliver to 1.2.3.4 but if
> that fails try to deliver to 8.9.10.11 much in the same way as MX records
> function.
>
> I'm not seeing a way to accomplish this, any suggestions, or examples?
>
>
If you wanto to deliver do 1.2.3.4 and , if fails, then try 8.9.10.11
then you can create a dns entry with those IP an MX

ex:
some_entry.local  IN MX 10 1.2.3.4
some_entry.local  IN MX 20 8.9.10.11

then setup transport_maps to:

domain.com   smtp:some_entry.local

Hope it helps.

other method is using smtp_fallback_relay

José Borges Ferreira