[2039] in Moira
Re: access service for outgoing mailers
daemon@ATHENA.MIT.EDU (Tom Coppeto)
Mon Oct 20 18:10:03 2003
In-Reply-To: <200310201925.h9KJPOZq019959@the-other-woman.mit.edu>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <25E8B5EE-034A-11D8-B7C2-0003930A99BA@mit.edu>
Content-Transfer-Encoding: 7bit
Cc: moiradev@mit.edu, Mark Silis <mark@mit.edu>
From: Tom Coppeto <tom@MIT.EDU>
Date: Mon, 20 Oct 2003 18:10:00 -0400
To: Jonathon Weiss <jweiss@mit.edu>
> When selecting users, you have 'WHERE status != 3' I think you want to
> exclude status 0 too (which is users who have not yet selected a
> username, and the placeholder in moira is '#<uid>'.) Statuses 4, 8,
> and 9 are also questionable to me, but I'm not 100% sure it is safe to
> exclude these, so I'd leave them in, unless Garry says otherwise.
It is ok if the result set is larger than it needs to be. We're trying
to rule out large chunks of the alphabet, a few thousand extra entries
won't make a difference. So don't worry too much about a particular
status and let's keep it simple.
> And finally, a policy request. If I understand correctly, after this
> change is deployed outgoing will no longer relay for foo@bar.mit.edu
> for any values of foo and bar. If I've misunderstood, please let me
> know, but assuming I haven't... I know that athena machines still
> assume this works in a few cases. If the machine is mkserv mail or
> has a hostname that is not in the mit.edu domain, it will DTRT on its
> own, but if it is not (and not explicitly configured) it may send mail
> form user@machine.mit.edu in certain cases. The most common case I
> can think of is a private machine where someone has re-pointed the
> root@machine.mit.edu alias somewhere, and a cron job generates mail.
> Another possibility is that if for some reason the machine generates a
> mail bounce, it will come from mailer-daemon@machine.mit.edu. Would
> it be possible, at the very least, to relay mail from these two
> classes of address? Including daemon@machine.mit.edu might also be
> wise, but is probably less important than the first two. I believe
> that these exceptions will become unnecessary after athena machines
> start using authentication when sending mail, and I believe we're
> hoping to include that in an IAP patch release (though there will
> obviously be some stragglers who don't take the patch right away.) If
> necessary, release-team can certainly talk about whether it is
> practical to get that change out sooner than later, but I'm not going
> to make an estimate on the outcome of any such discussion right now.
> (FWIW, I think the IAP date was partially chosen based on last
> summer's expectation that the mailhubs would require auth sometime
> next summer, and it look slike the world may have chnaged since then.)
>
This paragraph is hardly readable.
The two classes you refer to are user@machine.mit.edu and
mailer-daemon@machine.mit.edu. Both appear to be addresses of the same
form. Wildcarding the user portion of whatever someone typed in an
alias file is not very useful, at least as far as this exercise is
concerned.
If someone has a local alias file, or is producing mail from
mailer-daemon, isn't it the case they are likely running sendmail in
daemon mode and as such performing direct delivery?
What does this leave in terms of cases?
