[5294] in Release_7.7_team
sendmail in the background and messages outgoing refuses
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Fri Aug 12 06:48:52 2005
Date: Fri, 12 Aug 2005 06:48:26 -0400 (EDT)
Message-Id: <200508121048.j7CAmQuQ015722@the-other-woman.mit.edu>
To: release-team@MIT.EDU
From: Jonathon Weiss <jweiss@MIT.EDU>
X-Spam-Score: 1.108
X-Spam-Level: * (1.108)
X-Spam-Flag: NO
A while ago we noticed that when ougoing refused a message because it
was too large, the bounce was also refused for the same reason, and
because we've set sendmail to run in the backgroun the users MUA
doesn't get notified of the problem either. An inspection of the
dialups shows that this sort of failure can occur for a couple of
other reasons. Messages with viruses in them will experience this
failure. This sometimes occurs when someone forwards a message either
to a friend, or to ask some one if it is, in fact, a virus. Messages
with executable attachments also experience this behavior. I believe
that "executable" actually means "has a bad extension in its
filaname", but I'm not 100% sure of that. I'm not sure if this
changes our feeling that it is more important to have control returned
to the user quickly than it is to give MUAs a chance to notice these
problems and report them to the user, but it's certainly worth noting.
So far the only option I've found for mitigating this problem is the
-R option to sendmail. As documented on pp 841,842 in the second
edition of the Bat Book, adding '-R hdrs' to sendmail's arguments
should cause bounces to drop the body of the message. This should
cause the bounce to get through in all of the three cases mentioned
above. The problem is, of course, that this applies even if the
message makes it through outgoing and bounces form the destination
SMTP server because the address was typoed or something.
I'm unlikely to form an opnion on what TRT is before I go on vacation,
or possibly ever, so someone else should make the decision.
--
Jonathon
