Thanks for the reply. I'd prefer taking it back to the list to
generate some TMDA-Postfix traffic, so I'm cc'ing it back there.
Hope you don't mind.
# [EMAIL PROTECTED] / 2003-01-23 19:35:46 -0600:
> Roman Neuhauser <[EMAIL PROTECTED]> writes:
>
> > My first, and simplest, question is this: does anyone on the list use
> > TMDA to protect Postfix-handled virtual domains?
>
> This is a good question. Nobody has ever spoken up to say they do, in
> my cloudy recollection. Perhaps your mail will get someone to speak
> up.
>
> I don't run Postfix here, so I am curious if you can point me to a
> good online explanation of virtual domains under Postfix.
Hmm, this part of Postfix seems to have been evolving quite a lot,
so I'm afraid most of the web howtos will be outdated. I can whip
up something if http://www.postfix.org/docs.html isn't enough.
> I'm working on some qmail virtual domain issues and would like to
> understand what would be necessary to integrate Postfix virtual
> domains.
Huh, I'm no Postfix expert myself...
Postfix has two main configuration files: main.cf and mastar.cf.
Virtual mailbox domains with TMDA in Postfix-2.0.2 (as I said, this
has been changing pretty dramatically) should work roughly this way:
main.cf:
virtual_mailbox_domains = virtual1.dom, virtual2.dom
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailboxes
virtual_mailbox_base = /var/mail/courier
virtual_transport = tmda
virtual_destination_recipient_limit = 1
/etc/postfix/virtual_mailboxes:
[EMAIL PROTECTED] virtual1.dom/foo/
[EMAIL PROTECTED] virtual2.dom/bar/
> ls -Fl /var/mail/courier
drwx------ 2 courier courier virtual1.dom/
drwx------ 2 courier courier virtual2.dom/
the $virtual_mailbox_{base,maps} parameters are used by the
virtual(8) delivery agent, $virtual_mailbox_maps is also used by
smtpd which only matches the recipient address against the left side
(I can't find where I read this, so no quote, but Postfix needs to
be able to bounce the message, right?).
AFAICT, configuration variables of Postfix are not exactly available
to external programs, which means we either have to:
a) move the virtual configuration completely outside of Postfix
this could probably be achieved by using the maildrop transport
for virtual mailboxes instead of tmda, and invoke TMDA from the
maildrop filters
b) get Postfix to spit it out
the only way I know of without looking at the source is using
the postconf command:
> postconf virtual_mailbox_base virtual_mailbox_maps
virtual_mailbox_base = /var/db/courier
virtual_mailbox_maps = hash:/usr/local/etc/postfix/virtual_mailbox
> postconf -h virtual_mailbox_base
/var/db/courier
unfortunately, postconf doesn't return the actual configuration
of the running Postfix, it reads main.cf, which means trouble if
it's been edited, but Postfix hasn't been restarted yet.
TMDA would still have to get the mailbox or Maildir from the map
in this scenario.
I'll ask about other means of communication with Postfix on the
postfix list.
Now the custom virtual_transport: we'll define a transport called
"tmda" realized through the pipe delivery agent. "transport" roughly
equals "named/known/defined way of delivering email" in Postfix
speak.
master.cf:
# service type private unpriv chroot wakeup maxproc command + args
# defaults (yes) (yes) (yes) (never) (100)
# ==========================================================================
tmda unix - n n - - pipe
user=courier argv=/usr/local/bin/tmda-filter ${recipient} ${sender}
(if tmda-filter wanted the recipient in $1 and sender in $2)
this is the maildrop transport definition taken from default
master.cf in Postfix-2.0.2:
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
there are a few issues with transport definitions that need to be
taken into account:
Date: Tue, 8 Oct 2002 01:36:34 -0400 (EDT)
From: <[EMAIL PROTECTED]>
Message-ID: <Pine.GSO.4.33.0210080128030.7353-100000@sasas1>
Sender: [EMAIL PROTECTED]
"The pipe delivery agent does not understand shell argument quoting.
It splits argv on white-space regardless of any quotes."
Date: Tue, 8 Oct 2002 16:26:20 -0400 (EDT)
From: <[EMAIL PROTECTED]>
Message-ID: <Pine.GSO.4.33.0210081621090.7353-100000@sasas1>
Sender: [EMAIL PROTECTED]
"The pipe delivery agent uses a small private dictionary of macros
for command argument expansion. This dictionary is AFAIK independent
of main.cf. Also the expansion is non-recursive (to guard against
'$' chars) in email addresses."
virtual_mailbox_domains
Specifies the list of domains that should be delivered to the
$virtual_transport delivery agent (default: virtual). As of
version 1.2, Postfix is smart enough that you don't have to
list every virtual domain in a Postfix transport map.
virtual_mailbox_maps
Recipients are looked up in this map to determine the path to
their mailbox. If the returned path ends in a slash ("/"),
maildir-style delivery is carried out, otherwise the path is
assumed to specify a mailbox file. The virtual_mailbox_base
directory is unconditionally prepended to this path. If the
recipient is not found the mail is bounced.
virtual_mailbox_base
Specifies a path that is prepended to all mailbox paths. This
is a safety measure to ensure an that out of control map doesn't
litter the filesystem with mailboxes (or worse). While it could
be set to "/", this isn't recommended.
virtual_gid_maps
Recipients are looked up in this map to determine the GID (group
privileges) to be used when writing to the target mailbox.
virtual_uid_maps
Recipients are looked up in this map to determine the UID (owner
privileges) to be used when writing to the target mailbox.
virtual_destination_recipient_limit
Some external commands cannot handle more than one recipient per
delivery request. Examples of such transports are pagers, fax
machines, and so on.
Sources:
http://www.postfix.org/virtual.8.html
http://www.postfix.org/pipe.8.html
plus VIRTUAL_README, default main.cf, default master.cf from 2.0.2;
I can't find these files on the Postfix web site.
> As I'm sure you're well aware, there is a lot of cruddy, useless
> documentation out there and it's hard to find the gems when you're
> starting with no background.
I hope I haven't just added to the pile of crud. :)
> > Since the email addresses have no $HOMEs, they can't have ~/.tmda/
> > either; I would be perfectly fine with a system- or domain-wide
> > configuration file (I'm probably blind, but I couldn't find in the docs
> > whether this is supported at all, had to look in the source).
>
> Most of the TMDA programs, particularly tmda-filter and tmda-sendmail,
> read /etc/tmdarc first, before attempting to read the user's
> ~/.tmda/config. The user-specific config file is not required, BTW.
good to know (and /etc/tmdarc already noticed), but the config file
is not the only thing: there's quite a bit of env. var. use in TMDA
AFAICT. but nothing's unresolvable.
> In the case of the VMailMgr virtual domain manager for qmail, I used
> the actual maildir (which is named by the left side of the user's
> email address -- e.g., neuhauser in your case) as the "home" directory
> and look for /home/example.dom/users/<user_maildir>/.tmda/config.
> Works like a champ. The only question I have is what does Courier do
> with it. I think that, because the directory is *not* a maildir, it
> just ignores it.
courier's not limited to virtual accounts, so even with those
there's a notion of $HOME:
userdb:
[EMAIL PROTECTED] home=/path/to/a/dir/|mail=/another/dir/|...
> > and there's also the problem of invoking it from Postfix... Custom
> > transport? Quite a few questions, as you can see.
>
> And I'm sorry I can't answer the Postfix-specific ones. There are
> Postfix users, though, so hopefully someone will answer some of these
> questions for you.
I think I've answered most of the questions regarding the Postfix
side of the problem myself. :)
Looks like all that is needed is a way of letting TMDA know the
stuff it needs to know: envelope recipient, env. sender, $HOME, and
stuff.
> As an aside, I enjoyed your discussion with Terry Lambert about DNS
> on, was it -stable or -hackers? It's amusing to me how someone who is
> obviously incredibly bright can be so mired in BIND-think as not to
> realize how simple DNS really can be. I thought you made a strong
> argument.
Thanks for the compliment. :)
I was left with the impression that Terry may be incredibly bright,
but also has an incredible ego that forces him to cloud simple
problems with wrong solutions explained in extremely complicated
ways using way too many words to further confuse the other party so
that he *looks* incredibly bright. When caught in the act, he'll
try to change the playground.
I think he was glad someone else diverted the talk to the missing
MFT header thing because that allowed him to let the thread die.
--
FreeBSD 4.7-STABLE
1:14PM up 15 days, 18:21, 22 users, load averages: 0.00, 0.00, 0.00
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
