Errors-to: owner-drums@CS.UTK.EDU
Message-ID: <IjwjqZm00WBwMqyat=@andrew.cmu.edu>
Date: Thu, 29 Jun 1995 15:23:17 -0400 (EDT)
From: John Gardiner Myers <jgm+@CMU.EDU>
To: drums@CS.UTK.EDU
Subject: Fwd: potential mail loss
References: <cimcyPy00WBwMmk348@andrew.cmu.edu>
Beak: Is

An old message which is relevant to this list.

---------- Forwarded message begins here ----------

X-Andrew-Authenticated-As: 2971;andrew.cmu.edu;John Gardiner Myers
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411
          via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411;
          Wed, 16 Nov 1994 18:02:51 -0500 (EST)
Message-ID: <cimcyPy00WBwMmk348@andrew.cmu.edu>
Date: Wed, 16 Nov 1994 18:02:51 -0500 (EST)
From: John Gardiner Myers <jgm+@CMU.EDU>
To: mailext@cs.wisc.edu
Subject: potential mail loss
Beak: Is

There is a common situation where a straightforward interpretation of
RFC 1123 section 5.3.3 will in a common situation lead to mail being
silently dropped on the floor.

RFC 1123 section 5.3.3 states that if the reverse path "is null
("<>"), the receiver-SMTP MUST NOT send a notification."  The most
straightforward interpretation of this is that if a message with a
null reverse path is not deliverable, to drop it on the floor.  I know
of at least one mail delivery agent that has been implemented this
way.

Consider the case where mail arrives on a system with invalid
addresses in both the forward and reverse paths.  For example:

	MAIL FROM:<mangled-address@A.DO.MAIN>
	RCPT TO:<nonexistent@B.DO.MAIN>

Host B.DO.MAIN will generate a notification that local-part
"nonexistent" is not deliverable.  Per 1123 section 5.3.3, it must use
a null reverse path on the notification:

	MAIL FROM:<>
	RCPT TO:<mangled-address@A.DO.MAIN>

The message then travels to A.DO.MAIN and is not deliverable there.
If A.DO.MAIN uses the straightforward interpretation of 5.3.3, then
the mail is silently dropped on the floor.

This particular situation is not a rare occurence.  Our site is
intentionally configured to violate 5.3.3 and put the address of a
dead-letter box on nondelivery notifications.  We see about three of
these per day.  Often, the messages are of an importance that dropping
them on the floor would be unacceptable to our users.

On the other hand, instances of the error-reporting loops that the
ignored rule is trying to prevent are extremely rare and limited in
damage.  I have only ever seen one of these in my career, that was
because some external site generated two bounces for each incoming
message, sending one back to us with a nonfunctional address in
the forward path.

The interpretation of 1123 that sendmail 8 uses is as follows: when
generating a notification and the reverse path is null, deliver the
notification to a local dead-letter mailbox.  This gives the message a
chance to be brought to the attention of a human.  Unless this
interpretation is codified and widely implemented, however, it will
not be safe to generate error notifications with null reverse paths.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up