Re: Re: [Mailman-Developers] MTA interface for MM 2.1
I won't let any automatic process touch my master virtual file. The current setup (as of 2.1a3) works just fine; it takes control of one specific file which I bless. I then make postfix include it in alias processing. It's simple and works.
How are you then letting Postfix know what domain you are adding the list to?
If it only does half the job of creating the list, it isn't fulfilling its function of automatically creating the list without needing the sysadmin to do it for you, or having to edit the files yourself.
Also remember you don't have to have an automated process touch your master virtual mapping file. Do the same thing Barry did for the aliases file - use an _additional_ file, and tell Postfix where it is, and to use it in addition to the master file.
Bob
"bob" == <bob@nleaudio.com> writes:
bob> Also remember you don't have to have an automated process
bob> touch your master virtual mapping file. Do the same thing
bob> Barry did for the aliases file - use an _additional_ file,
bob> and tell Postfix where it is, and to use it in addition to
bob> the master file.I figured out how to support Postfix-style virtual domains[1] in a similar manner to the main aliases file, but I'm too tired to finish implementing it tonight.
Bob's right, if you're using Postfix-style virtual domains, we need to write into another file, and it doesn't need to be your main virtual file. In fact, it'll be called $prefix/data/virtual-mailman and you'll need to add something like that path to your virtual_maps variable (and /not/ run postmap on it! We'll take care of that for you).
If you're not using virtual domains, or you're using Sendmail-style virtual domains, we don't need to do anything extra. There will be an mm_cfg variable POSTFIX_STYLE_VIRTUAL_DOMAINS, defaulting to 0, which you'll set to 1 if you're doing Postfix-style virtual domains.
to-sleep-perchance-to-dream-of-mtas-ly y'rs, -Barry
"BAW" == Barry A Warsaw <barry@zope.com> writes:
BAW> I figured out how to support Postfix-style virtual domains[1]
BAW> in a similar manner to the main aliases file, but I'm too
BAW> tired to finish implementing it tonight.I'm about to check this stuff in, but it's a little kludgy. I may not entirely understand Postfix-style virtual domains, so let me ask this:
Let's say I have two domains, er, dom1.com and dom2.com, and MX for both of these point to the same IP. It seems to me that I have to have at least one of them in the mydestinations variable in main.cf.
So let's say I put dom1.com in mydestinations, and I want dom2.com to be a Postfix-virtual domain, so I set up a virtual_maps file with some common addresses like postmaster@dom2.com. To work with Mailman, I'll also add /usr/local/mailman/data/virtual-dom2.com virtual_maps. The .db file will contain the BerkeleyDB mappings equivalent to the plaintext file .../data/virtual-dom2.com containing stuff like:
-------------------- snip snip -------------------- # This file is generated by Mailman, and is kept in sync with the binary hash # file virtual-mailman.db. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you # know what you're doing, and can keep the two files properly in sync. If you # screw it up, you're on your own.
dom2.com IGNORE # For breaking bounce loops to the site list owners mailman-loop@dom2.com: mailman-loop
# STANZA START: testlist # CREATED: Fri Nov 23 18:39:34 2001 testlist@dom2.com: testlist testlist-admin@dom2.com: testlist-admin testlist-bounces@dom2.com: testlist-bounces testlist-join@dom2.com: testlist-join testlist-leave@dom2.com: testlist-leave testlist-owner@dom2.com: testlist-owner testlist-request@dom2.com: testlist-request # STANZA END: testlist -------------------- snip snip --------------------
For convenience, I'll create a pair of these for every domain for which there are lists (i.e. for every unique mlist.host_name). Now the kludges:
If dom1.com is set in mydestinations, then you /should not/ add data/virtual-dom1.com to virtual_maps, even though bin/genaliases will create a file for it. It's too complicated to prevent the writing of data/virtual-dom1.com, so just ignore it.
It seems like there's no way to prevent sending a message to list-in-dom2@dom1.com working exactly the same as list-in-dom2@dom2.com. This is because list-in-dom2 must have an entry both in the aliases file and the virtual file (with the virtual file entries pointing to the aliases entries), and the alias entries always work for mydestination domains. Maybe other Postfix experts can help with this, but to me, it's not worth worrying about.
Anyway, changes coming to Defaults.py.in, Mailman/MTA/Postfix.py and bin/genaliases. Comments are welcome!
-Barry
- (Barry A. Warsaw)
| >>>>> "BAW" == Barry A Warsaw <barry@zope.com> writes: | | BAW> I figured out how to support Postfix-style virtual domains[1] | BAW> in a similar manner to the main aliases file, but I'm too | BAW> tired to finish implementing it tonight. | | I'm about to check this stuff in, but it's a little kludgy. I may not | entirely understand Postfix-style virtual domains, so let me ask this: | | Let's say I have two domains, er, dom1.com and dom2.com, and MX for | both of these point to the same IP. It seems to me that I have to | have at least one of them in the mydestinations variable in main.cf.
No, you don't have to have any of them in mydestination in main.cf:
# The mydestination parameter specifies the list of domains that this # machine considers itself the final destination for. That does not # include domains that are hosted on this machine. Those domains are # specified elsewhere (see sample-virtual.cf, and sample-transport.cf).
| It seems like there's no way to prevent sending a message to | list-in-dom2@dom1.com working exactly the same as | list-in-dom2@dom2.com. This is because list-in-dom2 must have an | entry both in the aliases file and the virtual file (with the virtual | file entries pointing to the aliases entries), and the alias entries | always work for mydestination domains. Maybe other Postfix experts | can help with this, but to me, it's not worth worrying about.
I've usually hacked around this by doing something like
-------------------- snip snip -------------------- dom2.com IGNORE # For breaking bounce loops to the site list owners mailman-loop@dom2.com: mailman-loop
# STANZA START: testlist # CREATED: Fri Nov 23 18:39:34 2001 testlist@dom2.com: com-dom2-testlist testlist-admin@dom2.com: com-dom2-testlist-admin testlist-bounces@dom2.com: com-dom2-testlist-bounces testlist-join@dom2.com: com-dom2-testlist-join testlist-leave@dom2.com: com-dom2-testlist-leave testlist-owner@dom2.com: com-dom2-testlist-owner testlist-request@dom2.com: com-dom2-testlist-request # STANZA END: testlist -------------------- snip snip --------------------
So that all aliases in the dom2.com domain is on the form com-dom2-$ADDRESS.
afaik (and see), this is one of the better ways of avoiding name clashes.
--
Tollef Fog Heen Axiom #1: You Can't Win
Last night I checked in some stuff to hopefully improve the virtual domain support for Postfix. It'd be great if some of you could give it a looksee.
FWIW, I think I've solved the dom1, dom2 namespace collision problem, by as suggested, omitting both dom1 and dom2 from $mydestination. However, I still have host.dom1.ain in $mydestination (i.e. $myhostname) because otherwise, there's no way to receive any mail. AFAICT, there's no way to avoid having all the dom1.ain and dom2.ain names show up in host.dom1.ain. Oh well, that doesn't bother me.
-Barry
participants (3)
-
barry＠zope.com -
bob＠nleaudio.com -
Tollef Fog Heen