[1583] in Moira
Re: some suggested mailhub.gen changes
daemon@ATHENA.MIT.EDU (Mark V. Silis)
Wed Jun 14 11:03:00 2000
Message-Id: <200006141502.LAA00687@chicago.mit.edu>
To: "Tom Coppeto" <tom@MIT.EDU>
Cc: zacheiss@MIT.EDU, moiradev@MIT.EDU, postmaster@MIT.EDU
In-Reply-To: Your message of "Wed, 14 Jun 2000 07:44:47 EDT."
<NDBBKHCHPJDKBDPHJLDAAEEODAAA.tom@mit.edu>
Date: Wed, 14 Jun 2000 11:02:51 EDT
From: "Mark V. Silis" <mark@MIT.EDU>
Yup the moira patch should be just fine, so I would say updating nmailhub.gen to
use the patches should be ok. I don't think we should update the mailhub service to use
these changes, since:
1. It really doesn't need it.
2. I don't know what effect those changes will have on it, and its much harder to test
because of the age of the software.
3. Those machines are on their way out anyway, and I see no need to try and antagonize them
since they're so darn touchy.
I know garry has already prevented the creation and renaming of owner-lists in the current
moirad, it gives a nice error message even:
Mark% blanche marks-test -R owner-network
/usr/athena/bin/blanche: That name is reserved while updating list.
Garry it should be ok now to go ahead and commit those changes for mailhub.gen, but I think
only nmailhub.gen should be updated on the moira server, lets leave mailhub.gen as it is.
The number of existing owner-lists is 31, I can go ahead and get those converted over to
list-request, after notifying their owners, shouldn't take long. Converting back to gcs's sendmail
should be the easiest part of it, of course its last ;-)
-- Mark
|> It sounds like:
|>
|> 1. we can go ahead with this moira patch
|> 2. moira should prevent creation or renaming of owner-lists
|> 3. existing owner-lists that were not automatically generated need to be
|> identified and changed
|> 4. when the above 3 are complete, we can go ahead with a normal sendmail
|>
|> does this sum it up? 1 & 2 are in garry's court. who will volunteer to do 3?
|>
|> - Tom
|>
|>
|>
|> -----Original Message-----
|> From: Mark V. Silis [mailto:mark@MIT.EDU]
|> Sent: Wednesday, June 14, 2000 12:47 AM
|> To: tom@MIT.EDU; mark@MIT.EDU
|> Cc: zacheiss@MIT.EDU; moiradev@MIT.EDU; postmaster@MIT.EDU
|> Subject: Re: some suggested mailhub.gen changes
|>
|>
|>
|> I went ahead and did some testing with this configuration, having
|> my mit.edu MX record pointed at the test mailer with the non-pathched
|> sendmail,
|> and garry's new aliases file. This does in fact correct the problem. Here's
|> why: When you send to a list that has a fully expanded owner list, sendmail
|> doesn't do a look up on the list and end up setting the return-path to the
|> same thing again. What it actually ends up setting it to is <> since
|> owner-<listname> has no owner, and that ends any possible mailing loop.
|> Here is an example, network is a self owned list with an entry for which
|> the mailers cannot deliver. Someone sends mail to network, mail bounces to
|> the Return-Path: <owner-network@mit.edu>, which of course will bounce again
|> since that list is simply comprised of the members of network, but this
|> time we have Return-Path: <> which can never loop back! As long as the
|> Return-Path is always set to owner-<listname> and not simply the expansion
|> of
|> owner-<listname> ie (owner-network vs. network) looping bugs will be
|> avoided.
|> And garry's patch does in fact enforce this behaviour by setting
|> owner-<listname> to be a full expansion of the list membership.
|>
|> So I would say as long as we can prevent people from creating
|> owner-<listname>
|> lists, and maybe cleanup the ones out there there to be sure, that this is a
|> safe solution.
|>
|> -- Mark
|>
