MAILDROP_README and other custom transports (was: Patch (diff -u) for MAILDROP_README postfix-2.0.16-20031231)

From: Matthias Andree (no email)
Date: Sun Feb 01 2004 - 16:46:31 EST


On Sun, 01 Feb 2004, Tony Earnshaw wrote:

> +By using the standard combination of master.cf/transport as given above,
> +NO standard Postfix LDAP lookups are done before passing the message to the
> +Postfix transport.

Should this be "maildrop transport" instead?

> This in itself takes care of immediate delivery; however, it's
> +most likely that LDAP lookups have to be done - for example on system and other
> +aliases - before enabling delivery to users' mailboxes.

Before this gets out of hand, let's recollect and consolidate some
things (some I'm not 100% sure about):

1. when using a custom master.cf transport for a domain via
   transport_maps, does it matter if I use (mydestination,
   local_recipient_maps) or (relay_domains, relay_recipient_maps)?

   Either seems to work fine, I'd personally choose the one that fits
   the contractual status best. I. e. if I deliver my own domain to
   maildrop, I'd list it in mydestination, if I deliver somebody else's
   domain to maildrop, I'd list it in relay_*.

2. when using any of the *_recipient_maps, we'll have to do the LDAP
   lookups regardless, lest we accept mail for unknown recipients that
   we bounce later to the wrong person when the sender is forged. (I'd
   wish that local_recipient_maps can only be empty if luser_relay is
   set or (possibly intrinsically) when a catchall recipient is present).

3. when using a local(8) transport with mailbox_command, the
   (mydestination, local_recipient_maps) is the natural (if not the
   only) choice.

So this effectively means that the only real decision the user has to
make is if he wants his maildrop recipients subjected to alias_maps and
.forward redirection/expansion.

The setup flow plan (and what should be the essence of a
MAILDROP_README) would then be (realizing it isn't really
maildrop specific):

Choose if you need /etc/aliases and ~USER/.forward expansion

   if yes -> put maildrop as mailbox_command
             put the domain into mydestination
             put the recipient maps into local_recipient_maps
             (convenient if user owns mailbox)

   ALTERNATIVE:
   if yes -> put maildrop as mailbox_transport
             put the domain into mydestination
             put the recipient maps into local_recipient_maps
             create a maildrop transport in master.cf
             (convenient for virtual users)

   if no -> put the domain into relay_domains
             put the domain into transport
             put the recipient maps into relay_recipient_maps
             create a maildrop transport in master.cf

The current maildrop examples for master.cf can be taken from the
current readme.

Comments solicited.

-- 
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95







Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD