[2041] in Moira
Re: access service for outgoing mailers
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Mon Oct 20 18:45:05 2003
Message-Id: <200310202245.h9KMj2t0022211@the-other-woman.mit.edu>
From: Jonathon Weiss <jweiss@MIT.EDU>
To: Tom Coppeto <tom@MIT.EDU>
cc: Jonathon Weiss <jweiss@MIT.EDU>, moiradev@MIT.EDU,
Mark Silis <mark@MIT.EDU>
In-reply-to: Your message of "Mon, 20 Oct 2003 18:10:00 EDT."
<25E8B5EE-034A-11D8-B7C2-0003930A99BA@mit.edu>
Date: Mon, 20 Oct 2003 18:45:02 -0400
> > 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.
No problem, I was thinking mostly abotu the case of a string of
numbers like the uid, but I guess preceded by a pund sign it isn't too
likely to be guessed as a from address.
> > 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.
Sorry this was unclear, I was trying to get a useful reply back
quickly because of the time constraints, and may ahve over-done it.
I'll try to clarify the relevant points.
> 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.
The two addresses I was asking about were actually
root@machine.mit.edu and mailer-daemon@machine.mit.edu. I was not
intending to request that the user portion of either of these
addresses be wildcarded (I agree that that defeats the purpose), only
the domain name components before mit.edu. I don;t think we need to
wildcard whatever is in the aliases file, merely the likely source of
the mail.
To try to clarify the cron case, if a cron job produces output (at
least on an solaris machine) cron will generate mail to the user. At
least for cron jobs run as root, that mail will come from
root@machine.mit.edu and go to root@machine.mit.edu. On normal athena
machines mail to root@machine.mit.edu will be bitbucketed by a stub
aliases file, but on at least some private workstations the owner has
updated that to point to say, their mit account. Since the
workstation is not a mail server, but merely running some cron job, it
is not configured to do direct delivery.
Unfortunately, as mark asks, I don;t know the full scope of how many
machines this will affect. I suspect it will be a small number of
machines, but I'm not sure how to predict which of a much larger set
of machines will be in the small group. Perhaps a quick look through
outgoing's mail logs for {root,mailer-daemon}@machine.mit.edu whould
shed some light on the problem?
> 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?
All athena workstations have aliases files, however, they are stub
files in the deafult case. It is, however, possible to edit this file
and change things like the destination of mail to root@localhost when
the mail is generated on the local host, without running a sendmail
daemon, or accepting mail off of the network in any way.
Note that I'm worried about the mailer-daemon case, because it's the
best chance to notice failures generated by imposing the restrictions
discussed here. I don't know who likely this is to be a problem, but
it would be frusterating to block our only way of detecting some of
these problems. Perhaps we can leave this exception in place for only
a short time to see if things turn up?
Jonathon
