[17282] in Athena Bugs

home help back first fref pref prev next nref lref last post

Re: Jonathon Weiss: forwading broken on athena workstations

daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Mon Oct 18 15:09:43 1999

Message-Id: <199910181909.PAA50296@deliverator.mit.edu>
From: Jonathon Weiss <jweiss@MIT.EDU>
To: Tom Coppeto <tom@MIT.EDU>
cc: Jonathon Weiss <jweiss@MIT.EDU>, postmaster@MIT.EDU, network@MIT.EDU,
        bugs@MIT.EDU
In-reply-to: Your message of "Mon, 18 Oct 1999 10:10:25 EDT."
             <199910181405.KAA22621@melbourne-city-street.MIT.EDU> 
Date: Mon, 18 Oct 1999 15:09:29 -0400

> There's little consistency between your two messages. I hope I've captured
> the core of the complaints.

Oops, it wasn't quite as clear as I thought it was.  Greg's mail did a
pretty good job of summarizing problems.

1) Bounces generated on athena workstations are currently getting
lost, because the envelope from is null (as required by RFC 1123).  We
are putting out a patch release *tonight* (sorry for saying it was
Tuesday night originally) that will make athena workstations send
bounces from MAILER-DAEMON@FQDN.

2) When user@foo.com sends mail to ghudson@small-gods.mit.edu and
small-gods is forwarding ghudson's mail to ghudson@hotmail.com, that
mail will bounce, when small-gods tries to forward is, since foo.com
is not in the mit.edu domain.

3) when an athena machine that does not have an mit.edu aname (eg,
WHOI athena workstations, machines on mediaone/RCN, etc.) send mail
from a local user (eg. root, MAILER-DAEMON (yes, this includes all of
the bounces from these machines) it will bounce because
root@machine.whoi.edu is not in the mit.edu domain.

> We're looking into the mailer-daemon problem and one of the solutions may
> be to update the clients to use a non-null sender. Normally, industry
> practice is not to allow off campus machines to use campus mailers (which
> we do) and this unfortunately conflicts with these types of messages. It
> sounds like if there's a release in the works, then we should talk to
> release enginering. The right fix for this is still unclear.

You should definitely talk to me and or Greg about this this
afternoon, I'll try to find you shortly.

> For mailers running non-mit.edu domains, we don't support this. We've been
> fairly consistent that while we don't police this activity, we will not go
> out of our way to make this work. I think this is such a case. Mailers
> representing sub-domains of mit.edu, such as lcs or media, do direct delivery.

I'm not sure which problem you're referring to here, my best guess is
that it's #2 above.  If that is the case, we really need to talk.  If
it is postmaster's official position that machines like this should be
doing their own delivery, then we need to figure out how to get them
into that state, and how to stop them from losing until we can fix
their problem until we can make this change.  It sounds like we also
really need to talk about this issue.

	Jonathon

home help back first fref pref prev next nref lref last post