Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA15641; Sun, 4 Aug 1996 12:32:54 -0400 Received: by CS.UTK.EDU (bulk_mailer v1.6); Sun, 4 Aug 1996 12:32:35 -0400 Received: from koobera.math.uic.edu (qmailr@KOOBERA.MATH.UIC.EDU [128.248.178.247]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA15616; Sun, 4 Aug 1996 12:32:32 -0400 Received: (qmail-queue invoked by uid 666); 4 Aug 1996 16:36:29 -0000 Date: 4 Aug 1996 16:36:29 -0000 Message-ID: <19960804163629.7759.qmail@koobera.math.uic.edu> From: djb@koobera.math.uic.edu (D. J. Bernstein) To: drums@cs.utk.edu Subject: Re: MX loop example > the specs > control implementations, they cannot require any host owner to > act in any particular way. That's _exactly_ what they require. RFC 1123 is HOST REQUIREMENTS. Third paragraph: ``This RFC enumerates standard protocols that a host connected to the Internet must use.'' > 5.3.3 says that "OK" after DATA means the host has accepted > responsibilty for delivering or relaying the message. It doesn't > say where the message should be delivered, just that it should be. The semantics of MAIL, RCPT, and DATA are that the mail is delivered _to the recipients listed in RCPT commands_. RFC 821: ``RCPT ... is used to identify an individual recipient of the mail data ... All characters are to be delivered to the recipient's mailbox.'' Stop trying to weasel out of your responsibility. > One is that the owners of whitehouse.gov set it their DNS to direct > mail to my system, in which case they have just given me that > authority In reality, when people set up secondary MXes, they do _not_ think that they're giving the secondaries permission to throw away mail. I agree that the current standards don't adequately explain the meaning of MX records. This is something DRUMS should fix. > The other is that some random system(s) have decided they should > unilaterally send mail to my system to deliver for no good reason > at all. In that case the sender (or their system maintainer) has > donated their mail to me. In that case you are shirking your required responsibility under RFC 1123, section 5.3.3. > I don't understand why anyone would be in any way worried about > any of this. Because your irresponsible attitude produces an unreliable mail system, where failures lead to lost mail rather than bounces. ---Dan